List who has access, to what, and through which route, then remove what nobody can justify and record it. For GitHub that means members, outside collaborators, repository roles, personal access tokens, installed apps and recent audit log activity. One afternoon per quarter is enough if you keep the same steps each time.
What to review and where
| Area | Where to look | What to decide |
|---|---|---|
| Members and 2FA | People page | Remove leavers, chase missing 2FA |
| Outside collaborators | People page | Keep only those with an active engagement |
| Repository roles | Repository and team settings | Reduce Write, Maintain and Admin |
| Fine-grained tokens | Personal access tokens, Active tokens | Revoke unknown or overbroad |
| Token policy | Personal access tokens, Settings | Restrict classic tokens, set lifetime |
| OAuth and GitHub Apps | Organization app settings | Remove unowned apps |
| Audit log | Organization audit log | Spot rule changes and removals |
Each row maps to a page in GitHub's documentation, and each can be checked by an organization owner.
The afternoon, in order
- Export the audit log for the quarter first, since only 180 days are kept and exports are capped at 100 MB compressed.
- Review the member list against the HR roster. Remove anyone who left.
- Review outside collaborators against active contracts.
- Review Write and above by team, and cut extra grants.
- Review active tokens and the token policy.
- Review approved apps and OAuth restrictions.
- Search the audit log for branch protection, ruleset and visibility changes, and ask owners to explain any you did not expect.
Make the evidence easy
Keep one folder per quarter with the audit export, a screenshot or export of each list before changes, a short change log of what you removed, and the name of the reviewer. A reviewer who is not the person who made the changes adds credibility.
Do not claim the review proves compliance with any framework on its own. It is one input that an auditor can sample.
Common failure modes
- Reviewing people but not tokens, so a departed person's token lives on.
- Reviewing teams but not direct grants.
- Skipping the audit export and finding the oldest events gone.
- Writing a fine report and never removing anything.
If a review removes nothing for three quarters running, either your access is tidy or the review is shallow. Spot check by picking one repository and tracing every route to it.
Where Safeguard fits
Safeguard scans dependencies and builds an SBOM, and its policies and gates can block a pull request that adds a known-vulnerable package. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Open the framework mapping demo and see how one review record can support several control families.
Click through it at your own pace, or open it full screen.
Quick check
How often should we review access?
Quarterly is a common choice. Choose a rhythm you will actually keep and write it into your policy.
Who should run it?
An organization owner can see every screen, and a second person should review the result.
Sources
- Reviewing the audit log for your organization (GitHub Docs)
- Reviewing and revoking personal access tokens in your organization (GitHub Docs)
- Repository roles for an organization (GitHub Docs)
Last reviewed: 19 October 2026.
