You restrict repository creation by limiting which organisation roles or members can create new repositories in the organisation settings. Allow only the smallest practical group, then monitor for exceptions such as owner accounts or integration-driven creation. Also review whether repository templates and fork settings can be used to keep new projects under controlled governance.
What “restrict repository creation” means in an organisation
Repository creation is an organisation-level governance control, not just a convenience setting. The practical question is who is allowed to create new repositories, under what role, and whether that permission is broad enough to create uncontrolled sprawl. In GitHub organisations, the safe default is to keep creation rights narrow, then use templates and fork policy to shape how new code enters the organisation.
The key distinction is between permission to create and permission to govern. If too many members can create repositories, you increase the chance of unreviewed projects, inconsistent settings, and repositories that bypass naming, visibility, or compliance expectations. If creation is too restricted, teams may work around the control by creating resources elsewhere and importing them later, so the policy needs to be deliberate rather than absolute.
Where the organisation also uses GitHub Actions or shared automation, repository creation policy should be reviewed alongside workflow governance because the initial repository owner, default settings, and inherited permissions can affect everything that happens next. NHIMG’s GitHub and GitHub Actions Security Guide covers the broader control surface that sits around repository creation, including organisation-wide governance decisions that influence downstream risk.
Which GitHub settings shape who can create new repositories?
Start with the organisation’s repository creation permissions and make the smallest practical group eligible to create repos. In most environments that means limiting creation to owners or a tightly controlled admin group, then allowing exceptions only when there is a clear operational reason. That keeps the control understandable and makes exceptions easy to audit.
Repository templates are the main way to make controlled creation repeatable. They do not replace permission management, but they help ensure that approved projects start with the right branch structure, files, labels, and baseline settings instead of being assembled ad hoc. Fork settings matter too, because unrestricted forks can produce new collaboration paths that are not the same as deliberate repository provisioning.
Forks and templates also affect visibility of ownership. A repository created from a template still needs the same governance review as any other new project, while a fork policy that is too open can blur the line between sanctioned development and uncontrolled duplication. The control is strongest when creation rights, template use, and fork policy all reinforce the same governance model.
Why repository creation control matters for security and governance
Every new repository is a new policy boundary. It may inherit default access, secrets handling, branch protections, audit expectations, and automation hooks differently from the rest of the organisation. If creation is uncontrolled, the organisation can end up with unmanaged projects that never receive the same review cadence as core repositories.
Security teams should treat repository creation as part of the organisation’s attack surface and compliance footprint. A poorly governed repository can become the place where sensitive source code, environment configuration, or automation logic lands first, before controls are applied. That is why creation policy should be paired with baseline settings, review workflows, and visibility into who created what and why.
For a broader control perspective, NIST Cybersecurity Framework 2.0 supports the governance, protect, detect, and recover view of this problem, while NIST SP 800-53 Rev 5 Security and Privacy Controls maps cleanly to access control, auditing, and configuration management expectations for the environment around repository creation.
Risk and Threat Considerations
Unchecked repository creation can lead to configuration drift, uncontrolled exposure of code, and gaps in oversight when teams create projects outside the intended governance path. The risk is not only accidental exposure, but also the long tail of repositories that never receive the same review, monitoring, or lifecycle management as sanctioned projects.
Failure mechanism: Creation rights are too broad, so users or automation create repositories without the normal approval, template, or visibility controls, and those repositories persist with weak defaults or inconsistent ownership.
Impact: The organisation may accumulate unmanaged code, miss auditability requirements, and increase the chance that secrets, integrations, or public exposure settings are introduced before anyone notices.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Limits who can create repositories and who can exceed standard creation scope. |
| AU-2 — Event Logging | Repository creation needs auditable evidence of who created what and when. | |
| CM-2 — Baseline Configuration | New repositories should start from controlled defaults, not ad hoc settings. | |
| Recommendation — Restrict repository creation to the smallest practical role set and approve exceptions explicitly. Log repository creation events and review them for exceptions and anomalies. Define baseline repository settings and apply them to new repositories by default. | ||
| NIST CSF 2.0 | GV.RR-01 — Roles, Responsibilities, and Authorities | Repository creation is a governance decision about who holds authority to initiate projects. |
| PR.AA-05 — Identity Management, Authentication and Access Control | Creation permissions must be enforced as access control over an organisation resource. | |
| Recommendation — Assign repository-creation authority to clearly defined roles and review exceptions. Enforce creation permissions through role-based access and periodic access review. | ||
Practitioner Guidance
What to prioritise: Decide first who truly needs to create repositories, then align the organisation setting, template strategy, and fork policy to that decision. If the business needs broad project creation, compensate with stronger defaults and review rather than leaving creation unrestricted.
What to verify: Confirm that repository creation is limited to the intended role set, that exception paths are documented, and that new repositories inherit the expected baseline controls. Check whether integration-driven creation is separately governed so automation cannot silently bypass the policy.
Common mistake: Treating repository creation as a low-risk admin toggle. In practice it is a governance choke point, because it determines where new code starts its lifecycle and how much control the organisation has before the repository is used.
Practitioner takeaway: The strongest control is not merely “who can click create,” but whether every new repository enters the organisation through a predictable, reviewable path with known defaults and accountable ownership.
Related resources from NHI Mgmt Group
- What is the difference between repository-level GitHub security controls and organisation-wide governance for code security?
- How do you enforce SAML SSO for a GitHub organisation?
- How do you require two-factor authentication for a GitHub organisation?
- How do you set strict base permissions for repositories in a GitHub organisation?