Most of what this pillar describes requires a plan that a single organisation does not have.
That is worth establishing before anything else, because a great deal of enterprise governance advice is unusable without an enterprise account, and finding that out three chapters into a rollout plan is expensive.
The short answer
Section titled “The short answer”An enterprise account sits above organisations. GitHub’s documentation describes it as “the central point of administration for your business on GitHub.”
It contains users, organisations, teams, repositories, cost centers, policies and apps. An enterprise account “may contain one or more organizations.”
Repositories are not directly under it. The documentation is explicit: “repositories are owned by organizations and are not directly accessible under the enterprise account.” The enterprise governs through organisations rather than around them.
The capability that matters most is policy at a level organisation owners cannot override. Everything else follows from that.
The three-level hierarchy
Section titled “The three-level hierarchy”Enterprise account └── Organisation └── RepositoryEach level has owners, and each level can set policy affecting the levels below.
Enterprise owners set policies across every organisation. They cannot be overridden by organisation owners — that is the point of the level existing.
Organisation owners administer their organisation within whatever latitude the enterprise leaves them.
Repository administrators administer a repository within what the organisation permits.
The delegation pattern is explicit in the settings themselves. Most enterprise policies offer an option along the lines of allowing organisation owners to administer the setting — which is how an enterprise chooses, per policy, between mandating a value and delegating the decision.
What an enterprise account provides
Section titled “What an enterprise account provides”The capabilities that do not exist without one.
Enterprise-level policies. Settings applied across every organisation, covering repository creation, visibility, forking, deletion and transfer, base permissions, default branch name, deploy keys, outside collaborators and more. Covered in detail in enterprise account architecture.
Enterprise rulesets. Branch, tag and push rules applied across organisations and repositories, targeted by organisation, by repository name pattern, or by custom property. See enterprise rulesets.
Internal repositories. A visibility level between private and public, readable by everybody in the enterprise. The foundation of innersource.
SAML single sign-on and SCIM provisioning at the enterprise level, and the option of Enterprise Managed Users.
The enterprise audit log, with API access and streaming to external destinations.
Custom repository roles, which GitHub documents as available to GitHub Enterprise Cloud organisations, and custom organisation roles.
IP allow lists applied across organisations.
Cost centers, for attributing usage within the enterprise.
Where policy is actually enforced
Section titled “Where policy is actually enforced”A structural point that determines how you design governance: the enterprise account is not a single enforcement mechanism. It is several, with different targeting models and different behaviour.
Enterprise policies are settings. Each one is a value applied across the enterprise, or delegated to organisations. Their granularity is the whole enterprise — a policy is on or off, mandated or delegated, and there is no partial targeting.
Enterprise rulesets are targeted. They select organisations and repositories — by name pattern, by list, or by custom property — and apply branch, tag or push rules to what they select. This is where governance that varies by repository type lives.
Repository policies control lifecycle events: who can create, delete, transfer and change visibility. GitHub documents these as currently in public preview and subject to change.
Organisation settings fill in whatever the enterprise delegated.
Getting the mechanism right matters more than getting the value right. A rule that should vary by repository type, implemented as an enterprise policy, has to be set to the most permissive value that any team needs — which means it constrains nobody. The same rule as a ruleset targeted by custom property constrains exactly the repositories it should.
The recurring pattern in this pillar: uniform requirements become policies, varying requirements become rulesets targeted by metadata, and the metadata is custom properties.
The two enterprise products
Section titled “The two enterprise products”GitHub Enterprise Cloud is hosted by GitHub. Organisations live on GitHub.com, or on a dedicated ghe.com subdomain when data residency is in use.
GitHub Enterprise Server is an appliance you run. Same conceptual model, different operational responsibilities, and a feature set that trails the cloud product because it ships on a release cycle.
They are not interchangeable, and the differences matter for planning. Enterprise Cloud versus Server covers the comparison in full.
Enterprise policies in practice
Section titled “Enterprise policies in practice”The list is worth walking through, because it is the concrete answer to “what can an enterprise actually decide?”
Base permissions. The default level every organisation member has to every repository in an organisation — none, read, write or admin, or delegated. This is the highest-leverage single setting in the whole enterprise, because it determines the floor of everybody’s access, and a default of write across a large organisation is a very large blast radius.
Repository creation. Whether members may create repositories at all, and which visibilities they may choose. An enterprise can permit private and internal while forbidding public, which is the common posture for organisations that are not deliberately publishing.
Repository visibility changes. Whether a repository admin may change visibility, or whether that requires an organisation owner. Making a private repository public is a one-click disclosure, which is why this setting exists.
Repository deletion and transfer. Whether admins may delete a repository or transfer it out of the organisation. Transfer-out is the one people forget, and it removes a repository from your governance entirely.
Forking. Whether private and internal repositories may be forked at all. Central to the innersource model and to visibility and forking policy.
Outside collaborators. Who may invite people from outside the organisation — members, organisation owners, or enterprise owners only.
Default branch name. Set for new repositories, either enforced across the enterprise or delegated.
Deploy keys. Whether members may create them. Deploy keys are a credential outside the identity system, which is why an enterprise might restrict them; see machine identities.
Issue deletion and protected branch renames round out the set — small in scope, both concerned with actions that destroy or obscure a record.
The pattern across all of them: each is a decision about who may take an action that is difficult or impossible to reverse. That is a good lens for reviewing your own configuration — for each policy, ask what the irreversible action is and who should be able to take it.
Data residency
Section titled “Data residency”GitHub Enterprise Cloud with data residency places enterprise data in a chosen region, on a dedicated ghe.com subdomain rather than on GitHub.com.
It is not simply a location change. Some features behave differently or are unavailable, and integrations that assume github.com URLs need attention.
Users are managed differently. Data residency enterprises use managed user accounts, which carries the whole set of EMU constraints.
If data residency is on the table, treat every feature decision in this pillar as requiring separate verification. The gap between “documented for Enterprise Cloud” and “available in your residency region” is real.
Enterprise owner and the roles around it
Section titled “Enterprise owner and the roles around it”Enterprise owner is the highest level of access. Enterprise owners can manage policies, manage organisations within the enterprise, and manage enterprise settings — but notably, enterprise owners do not automatically have access to repository content in every organisation. Administrative authority and content access are separate.
That separation is deliberate and worth preserving. An enterprise owner who grants themselves access to every repository has replaced a governance role with a superuser account, and the audit log will show it.
Billing managers handle billing without administrative authority over organisations.
Enterprise members are the users in the enterprise, whose access to any particular repository comes through organisation and team membership.
Enterprise owners are a small number of people, and treating that list as a controlled population — reviewed, MFA-enforced, offboarded promptly — is a basic control. See access reviews and offboarding.
What an enterprise plan is actually bought for
Section titled “What an enterprise plan is actually bought for”Organisations rarely adopt an enterprise plan because they read a feature list. There are four recurring reasons, and knowing which one applies determines what you should configure first.
Identity consolidation. The organisation has decided that access to source code must be governed by the corporate identity provider — joiners provisioned, leavers deprovisioned, access reviewable. This is the most common driver and the one with the clearest business case, because it converts an untracked access surface into a tracked one. Start with SAML and SCIM.
Audit and evidence. Somebody has asked who approved a change, who has access to a repository, or when a permission was granted, and the answer took three days to produce. The enterprise audit log with streaming turns that into a query. Start there.
Uniform controls across teams. Twenty organisations, each with its own idea of what branch protection means, and no way to state a baseline. Enterprise rulesets are the answer. Start with one rule everybody already agrees with, applied everywhere, and build from there.
Consolidating sprawl. Repositories in several organisations, several accounts, and sometimes several platforms, with no single view. This is a fleet problem before it is a governance one — see repository fleet management.
Naming the driver focuses the work. An enterprise rollout that tries to do all four at once takes a year and delivers none of them. One driver, done well, creates the credibility to do the next.
What does not change
Section titled “What does not change”Worth being explicit about, because enterprise plans are frequently oversold internally.
Git does not change. Clone, commit, branch, merge — identical.
Repository-level features are largely the same. Pull requests, issues, Actions, branch protection.
An enterprise account does not make anything compliant. It provides controls and evidence; whether your use of them satisfies a framework is a separate assessment.
Developers should not notice. A well-run enterprise configuration is invisible to the people doing the work, and a configuration developers are constantly fighting is usually one where mandates were applied where delegation was appropriate.
Preview features and how to treat them
Section titled “Preview features and how to treat them”Several capabilities in this pillar are labelled by GitHub as public preview, and that label carries real consequences for planning.
At the time of writing, repository policies, Actions policies and workflow execution protections are documented as being in public preview and subject to change. Multiple audit log streams and API request events in the audit log carry the same status.
Preview means the behaviour may change, the interface may change, and availability may change. It does not mean the feature is unreliable — it means the contract is not yet fixed.
Which affects three things:
- Do not build a compliance control that depends solely on a preview feature. If your evidence for a control is produced by something whose behaviour may change, the control has an unstated dependency.
- Do not assume availability. Preview features are frequently limited to particular plans or configurations.
- Do re-verify before each planning cycle. A feature that was preview last quarter may be generally available now, or may have changed shape.
Use them. Preview features are frequently the best available answer to a real problem, and waiting for general availability has its own cost. Use them knowingly, document the dependency, and have a position on what you do if the behaviour changes.
Deciding what to mandate
Section titled “Deciding what to mandate”The governance question the plan makes possible, and the one that determines whether it succeeds.
Mandate what must be uniform for a defensible reason. Authentication. Repository visibility rules. Audit log retention. The things where an exception is a risk rather than a preference.
Delegate what teams legitimately differ on. Default branch protections, review counts, required checks. A payments team and a documentation team have genuinely different needs.
Every mandate has a cost, paid by every team, forever, in exceptions and friction. A mandate whose reason cannot be stated in one sentence is a mandate that will be resented and worked around.
Start narrow. It is far easier to add a mandate later than to remove one, because removing it looks like weakening a control even when it is not.
Write down which is which. A policy inventory listing every enterprise setting, its value, whether it is mandated or delegated, and why, is the single most useful governance artifact an organisation can maintain — and almost nobody has one.
The first ninety days
Section titled “The first ninety days”If the enterprise account is new, this is the order that produces a working governance position without a year-long programme.
-
Inventory what exists. Organisations, repositories, owners, and who has enterprise-level access. You cannot govern a fleet you have not counted, and this step routinely finds organisations nobody remembered.
-
Fix the enterprise owner list. It is small, it is powerful, and it is almost always stale. Remove people who no longer need it and enforce MFA.
-
Turn on the audit log and start streaming it. Retention is finite — GitHub documents 180 days for the audit log, with Git events retained for seven days — so every day you do not stream is a day of evidence you will not have later. This is the single most time-sensitive step.
-
Establish metadata before policy. Define the custom properties that describe what a repository is — its tier, its team, its data classification. Every targeted policy afterwards depends on this existing.
-
Set the policies that are genuinely uniform, and delegate the rest explicitly. Record both, with reasons.
-
Ship one enterprise ruleset in evaluate mode. Something uncontroversial. Watch what it would have blocked. This is how you learn what your fleet actually looks like without breaking anything.
-
Only then start enforcing. See policy rollout for how to do that without a revolt.
Step 3 is the one people postpone and regret. Audit retention is a rolling window; you cannot go back and capture what has already aged out.
Common mistakes
Section titled “Common mistakes”Planning around features the plan does not include. Verify availability first.
Assuming Enterprise Server has the same features as Enterprise Cloud. It trails, and some things are cloud-only.
Assuming data residency is only a location change. Feature availability and user management both differ.
Treating enterprise owner as a superuser account. Administrative authority and content access are separate; keep them separate.
Mandating everything possible. Every mandate is paid for by every team forever.
Presenting configuration as compliance. The control is the process; the setting is evidence for it.
Not recording what is mandated and why. The next administrator cannot tell a deliberate policy from an accident.
Who does this work
Section titled “Who does this work”A question that determines whether any of it lasts.
Enterprise administration is a role, not a side task. In organisations where it is nobody’s job, the configuration is whatever the last person who touched it left behind, and no one can explain why any setting has its current value.
It is usually one to three people in a platform, developer experience or security engineering function, with enterprise owner access and a mandate to say no.
It requires a decision-making forum, because the interesting questions — should we mandate signed commits, should internal repositories be readable by contractors — are not technical and should not be settled by whoever has the access.
And it requires the policy inventory. A document that lists every enterprise setting, its current value, whether it is mandated or delegated, who decided, and when. Without it, every future review starts from archaeology.
The failure pattern is delegation to a ticket queue. Enterprise settings changed on request, one at a time, by whoever picks up the ticket, with no record of intent. After two years the configuration is a fossil record of individual requests rather than a design.
Mental model
Section titled “Mental model”An enterprise account is a policy layer above organisations. It does not own repositories and it does not change Git. What it provides is the ability to set a value that organisation owners cannot override — and the corresponding responsibility to decide, for every setting, whether uniformity is worth what it costs.
What you learned
Section titled “What you learned”- An enterprise account is the central point of administration, containing organisations, users, teams, policies, cost centers and apps
- Repositories are owned by organisations and are not directly accessible under the enterprise account
- Most enterprise policies offer either a mandated value or explicit delegation to organisation owners
- Enterprise accounts enable enterprise rulesets, internal repositories, enterprise SSO and SCIM, the enterprise audit log, custom roles and IP allow lists
- Enterprise Cloud and Enterprise Server differ in feature availability and operational responsibility
- Data residency changes more than location — feature availability and user management both differ
- Enterprise owner is administrative authority, not automatic content access, and that separation is worth preserving
- No GitHub configuration produces compliance by itself
- Deciding what to mandate versus delegate is the governance model, and it should be written down
Exercise
Section titled “Exercise”Use an enterprise you have access to, or reason from the documentation.
-
Draw your organisation’s structure: enterprise, organisations, and roughly how many repositories in each.
-
List everyone with enterprise owner access. Predict: is that list current, and does everyone on it still need it?
-
Open the enterprise policy settings. For each policy, record whether it is set to a fixed value or delegated to organisations.
-
For each mandated policy, write the reason in one sentence. Predict: how many can you actually justify?
-
Identify three features you assumed you had. Verify each against the documentation for your exact platform.
-
Find one policy that is mandated but should be delegated, and one that is delegated but should be mandated. Justify both.
-
Start a policy inventory document with what you found. It is the artifact the rest of this cluster builds on.