> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# The Permission Hierarchy

> Explains GitHub's hierarchical permission model, showing how enterprise, organization, teams, nested teams, outside collaborators, and custom roles set and inherit access limits.

Permissions on GitHub follow a cascading (hierarchical) model: policies set at higher levels create ceilings that lower-level scopes cannot exceed. This guide walks the permission flow from the enterprise level down through organizations, teams (including nested teams), outside collaborators, and custom roles — showing who can set or tighten policies and how permissions inherit across the hierarchy.

The core principle is simple: higher levels set the ceiling; lower levels operate within that ceiling. A useful analogy is an organization chart combined with building access controls — the CEO (enterprise owner) can lock down the whole building, and department leads manage access only within those constraints.

* Keywords: GitHub permissions, permission hierarchy, enterprise policies, organization permissions, team maintainers, custom roles

At the very top sits the enterprise level. The enterprise owner functions like a CEO: they define company-wide policies that apply across all organizations and repositories under that enterprise. If the enterprise policy disallows publishing code publicly, that restriction cannot be overridden by any organization, team, or repository beneath it.

![A slide titled "The Enterprise Level" showing a hierarchical org-chart: an Enterprise node (with a CEO icon) branching down to Organization nodes and Repository boxes. The top also shows a building illustration with labels "An org chart" and "Building access."](https://mintcdn.com/kodekloud-c4ac6d9a/Ae2SeWV4btujbkSt/images/GitHub-Administration-Certification/Governance-and-Roles/The-Permission-Hierarchy/enterprise-org-chart-building-access.jpg?fit=max\&auto=format\&n=Ae2SeWV4btujbkSt\&q=85\&s=5b5917b0e099368155ff7034a0aef128)

## Organization level

One level down is the organization. An organization owner is comparable to a vice president of engineering: they control access and policies for their organization but must operate within enterprise limits. An organization can tighten settings (for example, require stricter SSO or lock repository visibility) but cannot make permissions more permissive than the enterprise allows.

![A presentation slide titled "The Organization Level" with a sidebar menu highlighting "Organization." On the right it shows a "VP of engineering" role that "runs the department's access" within the CEO's rules, plus a permission slider from more restrictive to more permissive.](https://mintcdn.com/kodekloud-c4ac6d9a/Ae2SeWV4btujbkSt/images/GitHub-Administration-Certification/Governance-and-Roles/The-Permission-Hierarchy/organization-level-vp-engineering-permission-slider.jpg?fit=max\&auto=format\&n=Ae2SeWV4btujbkSt\&q=85\&s=ce0c3244f43f479bb89ebad23e6e8fb2)

## Teams

Teams are the primary mechanism to grant access at scale. There are two common team roles to know:

* Team members: receive the permissions granted to the team (e.g., read, triage, write).
* Team maintainers: manage the team itself — rename it, add/remove members, and change team-level settings.

Using teams makes it easier to manage repository access for groups instead of individual accounts.

![A slide titled "The Team Level" showing a boxed "payments-team" with four member icons pointing to three repos: payment-api, payment-web, and payment-docs. The left menu highlights "Team," and icons at the bottom label "Team member" and "Team maintainer."](https://mintcdn.com/kodekloud-c4ac6d9a/Ae2SeWV4btujbkSt/images/GitHub-Administration-Certification/Governance-and-Roles/The-Permission-Hierarchy/team-level-payments-team-repos-members.jpg?fit=max\&auto=format\&n=Ae2SeWV4btujbkSt\&q=85\&s=8323f5bf2b1095e9c861e2ece09fce93)

## Nested teams and inheritance

Teams can be nested. A child team inherits the repository permissions of its parent team; membership is managed separately. For example, if a parent team has access to the “engineering floor,” a child payments-team will also have that repository access unless an admin explicitly changes its permissions.

* Inheritance principle: child team permissions = parent team repository permissions + any additional adjustments applied to the child
* Membership is independent: adding a member to a child team does not automatically add them to the parent team

![A slide titled "Nested Teams Inherit" showing a simple org chart: "Engineering floor" at the top, a parent team labeled "backend-engineering," and a child team labeled "payments-team" beneath it.](https://mintcdn.com/kodekloud-c4ac6d9a/Ae2SeWV4btujbkSt/images/GitHub-Administration-Certification/Governance-and-Roles/The-Permission-Hierarchy/nested-teams-inherit-org-chart.jpg?fit=max\&auto=format\&n=Ae2SeWV4btujbkSt\&q=85\&s=56687eb02de1687b15f7667118fd6e10)

## Outside collaborators

Outside collaborators are a distinct class of users — usually contractors, vendors, or temporary contributors — who receive repository-level access without being added to the organization’s membership. They are intentionally excluded from the company directory and do not inherit team permissions.

* Typical use cases: vendor integrations, short-term contractors, external auditors
* Scope: limited explicitly to the repositories they need

![A diagram titled "Outside Collaborators" showing an external user with a temporary guest badge who is restricted to specific repositories (e.g., "vendor-integration") rather than the organization's full hierarchy (Enterprise → Organization → Team → Nested team). A company directory list appears on the right.](https://mintcdn.com/kodekloud-c4ac6d9a/Ae2SeWV4btujbkSt/images/GitHub-Administration-Certification/Governance-and-Roles/The-Permission-Hierarchy/outside-collaborators-guest-restricted-repos-directory.jpg?fit=max\&auto=format\&n=Ae2SeWV4btujbkSt\&q=85\&s=32c8aec48040df2846316cadfc3a8ddf)

## Custom roles

When built-in roles are too coarse, custom roles let administrators grant only the precise permissions required for a job. Instead of promoting someone to a full admin so they can approve deployments, create a custom role (for example, “Deployment approver”) that includes only that single permission.

* Benefit: least privilege — reduce blast radius by granting minimal required permissions
* Use cases: deployment approval, release manager, compliance reviewer

![A slide titled "Custom Roles" showing a comparison between a full admin (with many permissions listed) and a slim custom role for "Deployment approval." In the center a user icon is shown with a green button "Approve deployments," illustrating that the user only needs that single permission.](https://mintcdn.com/kodekloud-c4ac6d9a/Ae2SeWV4btujbkSt/images/GitHub-Administration-Certification/Governance-and-Roles/The-Permission-Hierarchy/custom-role-approve-deployments.jpg?fit=max\&auto=format\&n=Ae2SeWV4btujbkSt\&q=85\&s=8f7564adc3a5fe80fcb3d79c31daaaf2)

## Quick reference table

| Resource level | Who controls it | Can lower levels override? | Typical examples |
| -: | - | :-: | - |
| Enterprise | Enterprise owner / SAML/SCIM admins | No — acts as an immutable ceiling | Organization-wide visibility, global SSO policy |
| Organization | Org owners | No, but can tighten within enterprise limits | Repository visibility, required SSO, org membership |
| Team / Nested Teams | Team maintainers / Org owners | Inherited from parent; can be narrowed at child level | Repo access for engineering teams |
| Outside collaborators | Repo admins | N/A — explicit repo-level access only | External vendors, contractors |
| Custom roles | Org or enterprise admins (depending on scope) | N/A — tailored permission set | Deployment approver, release manager |

Higher-level policies act as immutable ceilings. Use organization and team settings to tighten access where needed, and use custom roles to enforce least privilege for sensitive tasks.

## Links and references

* [GitHub Permissions and Roles (official docs)](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories)
* [Managing teams in an organization](https://docs.github.com/en/organizations/organizing-members-into-teams)
* [About outside collaborators](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/adding-outside-collaborators-to-repositories-in-your-organization)
* [Creating and managing custom roles](https://docs.github.com/en/enterprise-cloud@latest/admin/roles)

> [card] [Watch Video](https://learn.kodekloud.com/user/courses/github-administration-certification/module/e4b7bd78-3fb5-4c1c-94d8-e528b0b60484/lesson/17874aea-925a-43bc-b270-e56133650584)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.