13.2 Organization Settings, Teams, and Roles

Why GH-900 tests organization admin after repository roles

Domain 6 closes with recognize how to manage organization settings, teams, and roles. Section 12.2 already ranked repository roles (Read → Triage → Write → Maintain → Admin). This section is the organization control plane: who is an owner, how teams nest, and which switches live under Settings → Member privileges. GH-900 will hand you a messy org (“finance needs invoices, security needs alerts, contractors need one repo, InnerSource needs a parent team”) and expect you to pick settings and org roles, not another repository permission.

Recap: predefined organization roles

A permission is one action. A role is a bundle of permissions. At invite time you add someone as an owner, billing manager, or member. After they join, owners can attach additional predefined or custom roles (moderator, security manager, CI/CD, GitHub App manager). Custom organization roles that grant a slice of admin (for example “view the audit log”) without full ownership are a GitHub Enterprise Cloud feature.

Outside collaborators are not an org role you invite as “member.” They have repository access without membership, do not sit on teams, and do not inherit base permissions. Keep that distinction from D6.2; D6.5 still uses it when 2FA policy removes outside collaborators who lack 2FA while members keep their seats and only lose resource access.

GitHub recommends that at least two people in each organization have the owner role. A single owner who is unreachable can make the org’s projects inaccessible. Owners can change other people’s roles; an owner cannot change their own role, so you appoint a second owner before the first goes on leave.

Teams: nested groups of members, not contractors

Teams are groups of organization members that mirror company structure, carry cascading repository access, and can be @mentioned. Outside collaborators cannot be on a team. Organization owners and team maintainers grant a team Read, Write, or Admin (or the other repository roles) on org repositories. Members request reviews from a team that has at least read access on the repository. Teams also appear as owners in a CODEOWNERS file.

Team visibility:

• Visible teams can be viewed and @mentioned by every organization member.
• Secret teams are visible only to team members and organization owners. Useful for a client-delivery group. If someone mentions a secret team, the name still appears in the mention text. Secret teams cannot be nested—no parent, no children.

People outside the organization cannot view any teams.

Nested teams let you encode hierarchy. A parent can have many child teams; each child has one parent. Each nested team is still its own URL and directory. Child teams inherit the parent’s repository access permissions, which is how you avoid granting Write fifty times. Members of child teams also receive notifications when the parent is @mentioned. @mentioning a team at the bottom of the tree notifies only that team. You mention the team’s handle; you do not type the full path. Child-team members show on the parent’s Members tab as inherited members; they are not direct members of the parent.

GitHub’s example: Employees → Engineering → Application Engineering → Identity. Grant Engineering Write on a repository and Application Engineering and Identity receive Write too. Mention Identity and only Identity is notified.

Before you nest existing teams, audit repository access. Put safe, broad permissions on parents and add more sensitive, narrower grants as you move down. GitHub’s documented prep sequence is: remove members from existing teams, adjust each team’s repo access and assign a parent, create new teams, then add people directly.

Team maintainers are members of the team who can administer that team without being org owners. They can rename the team, change description and visibility, set a profile picture, add and remove members, assign other maintainers, remove the team’s repository access, manage code review assignment, manage scheduled reminders, and request a child team or a parent-team change. They cannot delete the organization or rewrite Member privileges. Promote a maintainer only after the person is already on the team.

GitHub Enterprise Cloud can synchronize teams with identity-provider groups so membership follows the IdP. Team Discussions are retired; use GitHub Discussions at the organization or repository level instead.

Member privileges, the audit log, and SAML

The Member privileges page is the D6.5 settings map

Organization owners open Settings → Member privileges (under Access) to set org-wide defaults. GH-900 does not ask you to click every checkbox; it asks you to know which policy lives here versus which lives on a repository.

Two-factor authentication (2FA) requirement. Owners can require 2FA for members, billing managers, and outside collaborators. The owner’s own account must already have 2FA before the org requirement can be enabled. Members and billing managers without 2FA cannot access organization resources until they enable it, but they keep membership and consume seats. Outside collaborators without 2FA are removed, lose repository access, and lose forks of the organization’s private repositories. Owners can further allow only secure 2FA methods (passkeys, security keys, authenticator apps, GitHub Mobile—not SMS). This is org policy on top of GitHub.com’s contributing-user 2FA mandate from Chapter 12.

Base permissions (the setting many stems still call default repository permission) apply to all members on any organization repository. They do not apply to outside collaborators. GitHub’s default is Read on the organization’s public repositories. Owners can set a floor such as No permission, Read, Write, or Admin. A higher per-repository or team grant overrides the base. Changing the base affects new and existing members; private fork permissions are not automatically updated. Internal repositories still have a minimum of read, even if the base is none—because internal visibility is enterprise-wide read.

Repository creation. Owners choose whether members (and GitHub Apps) may create repositories and which visibilities they may pick (for example public and private, or public only). Organization owners can always create any type of repository. Restricting members to private-only creation is a GitHub Enterprise Cloud option. This setting limits visibilities at create time; it does not by itself stop someone from changing an existing repository’s visibility—that is a separate restrict visibility changes policy, which owners can set to owners only.

Repository forking. Owners allow or prevent forking of private repositories. By default, new organizations disallow forking of private repositories. If the org allows it, a repository admin can still disable forking on a single private repo. On Enterprise Cloud, internal-repo forking can be directed into other organizations where the user may create repositories; enterprise owners can enforce a forking policy across organizations.

Other Member privileges GH-900 may name in passing: who may create teams, default branch name for new repos, default labels, and whether members may publish GitHub Pages. If the stem is “stop employees from making a public repo on day one,” start with repository creation plus visibility-change restrictions—not with branch protection.

Audit log: owners, 180 days, richer on higher plans

The audit log lets organization owners (only) review actions that affect the organization: who did what, to which repository, when, and from which country. GitHub retains org audit-log events for the last 180 days. The UI defaults to about three months; older events need a created date range. You cannot free-text search the log; you filter with qualifiers such as actor:, action: (for example action:team.create or action:protected_branch), repo:org/name, and operation: (create, modify, remove, and similar). Owners can export CSV or JSON, with size/time limits, so you narrow the query first.

Treat “audit log” as a higher-plan administration story on GH-900: the in-product log is an owner tool, while GitHub Enterprise Cloud adds the audit log API (GraphQL and REST) and, at enterprise scope, audit log streaming and related compliance controls (for example IP allow lists). Webhooks can be a better “tell me when X happens” alternative than polling the log.

SAML SSO is Enterprise Cloud, not Free or Team

Security Assertion Markup Language (SAML) single sign-on (SSO) requires GitHub Enterprise Cloud. It does not replace GitHub.com sign-in unless you use Enterprise Managed Users. Members still sign into personal GitHub.com accounts; when they hit protected org resources, GitHub redirects them to the identity provider (IdP). After the IdP authenticates, it sends them back. GitHub links the org, the GitHub user, and the IdP identity. SSO is not required for outside collaborators. Some public-repository reads (overview, file view, fork, clone) can skip IdP authentication; issues, pull requests, and similar still need it. API and Git over HTTPS/SSH need a personal access token or SSH key authorized for SSO. SAML for an organization can be disabled, enabled but not enforced, or enabled and enforced. Enterprise owners can instead enforce SAML for all organizations in the enterprise. GitHub tests IdPs such as Microsoft Entra ID, Okta, AD FS, OneLogin, PingOne, and Shibboleth. SCIM provisioning is a related Enterprise Cloud topic; EMUs use a different SCIM path (Chapter 12.3).

If a member creates a repository during an active SAML session, GitHub’s default visibility for that new repo is private; otherwise the default is public. That is a small but testable interaction between SSO and visibility.

Exam traps for D6.5

• Two owners, not one. Continuity is a documented recommendation, not a courtesy.
• Org role ≠ repo role. Billing manager does not become Admin on every repo. Security manager is read-all-repos plus security settings, not ownership.
• Teams are members only. Contractors stay outside collaborators; they cannot nest into Engineering.
• Children inherit parent repo access. Secret teams cannot nest.
• Team maintainer ≠ owner. Maintainers run the team; they do not own the org.
• 2FA org policy: members keep seats; outside collaborators are removed.
• Base permissions ignore outside collaborators. Internal repos still read at enterprise scope.
• New orgs default to no private forks. Allowing forks is an explicit Member privileges change.
• SAML = Enterprise Cloud. It is not a Free-org toggle. Members still have GitHub.com passwords unless they are EMUs.
• Audit log = owners, 180 days of org events; API and streaming are the Enterprise-grade extras.