GitHub repository permissions audit checklist

Most GitHub access audits go wrong for a simple reason: the org already drifted, but nobody has one clean view of the drift.

This checklist is for org admins, engineering managers, and security-minded platform teams who need to review repo access in a way that is fast, repeatable, and defensible.

TL;DR

Problem: stale admins, direct grants, inherited access, and old exceptions build up quietly until an audit or security review forces the cleanup.
Who this is for: GitHub org admins, engineering managers, and platform teams responsible for private code and least privilege.
What this helps you fix: a practical review order for high-risk access, temporary exceptions, external collaborators, service accounts, and the evidence you should keep.

1. What usually breaks

An ex-employee still has admin on one or more repos.
A contractor still has direct repo access because the original exception was never removed.
A sensitive repo inherits access from a broad parent team that nobody wants to untangle by hand.
Service accounts and bot tokens exist, but nobody can explain who owns them or why they still need the permissions they have.
An auditor asks who can see private code, and the answer takes hours to assemble.

The point of the audit is not to count every permission. It is to decide whether the live access model still matches how the org actually works.

2. GitHub repository permissions to review

Repository admins: check every repo with admin or maintain outside a small trusted group.
Direct user grants: find user-to-repo permissions that bypass teams and ask whether each one is still justified.
External collaborators: confirm the owner, purpose, and end date for each external access path.
Inherited team access: review sensitive repos attached high in the hierarchy, where parent access may now be too broad.
Unowned repositories: if nobody can name the owning team, you do not have a stable permission model yet.
Machine access: review service accounts, bot identities, and automation tokens separately from human access.

3. GitHub repo access review checklist

[ ] List critical repos, sensitive repos, and customer-facing systems first.
[ ] Review everyone with admin or maintain.
[ ] Review direct user grants and record the reason for each one that remains.
[ ] Review external collaborators and contractor access.
[ ] Check whether sensitive repos inherit access from teams that are now too broad.
[ ] Check whether base permissions or broad teams give write access to more repositories than intended.
[ ] Review GitHub Actions-heavy repos separately, especially when workflows use secrets, packages, environments, or deployment paths.
[ ] Confirm the owning team for every important repo.
[ ] Review service accounts, deploy keys, and long-lived automation identities.
[ ] Keep an audit note of what changed, what remained as an exception, and who approved it.

4. Blanket write access and Actions-heavy repos

Broad write access deserves its own audit question. If everyone can write to every repo, the review is no longer only about PR approval. You also need to understand which repositories run GitHub Actions, which workflows can reach secrets or packages, and which branch rules actually stop unreviewed changes from landing.

For the deeper risk model, review the blanket GitHub write access risks.

5. Repository roles: what evidence to keep

Good audits leave a paper trail. Keep a dated org-history record of the current state, a short list of the risky findings, the approved exceptions, and who signed off the cleanup.

Export or org-history record of current repo and team access
List of repos with high privilege or direct grants
Named owners for exceptions that remain
Proof of cleanup for stale users, contractors, and broad team mappings

6. GitHub audit log vs permission audit evidence

The GitHub audit log helps explain recent changes. A permissions audit needs a current-state record too: repository roles, team access, direct grants, external collaborators, and the exceptions you chose to keep.

7. Where native GitHub gets slow

GitHub gives you the underlying access model, but it does not give you a fast org-wide review surface. Once you have enough repos and enough exceptions, the bottleneck becomes visibility and review effort, not the absence of permissions features.

If you want the broader operating model behind this checklist, read the GitHub governance and permission drift guide. For inherited access and parent-team review, use GitHub Teams hierarchy and repository permissions. If the immediate question is how GitHub reports the access path, continue with GitHub Direct access vs Organization access.

8. Turn the checklist into a live review

If you want a faster starting point than manual clicking, see our GitHub access audit tool page or run the free audit directly.

Run Free GitHub Access Audit