A quarterly review of your Git host should cover people, machines and exceptions: who is an admin, which outside collaborators remain, which tokens and deploy keys exist, who can bypass rules, and which forks and bots hold access. Keep a dated record of what you checked and what you changed.
People
- Admins and owners. List them and ask whether each still needs the role. Admins are exempt from branch protection by default, as covered in branch protection and admin bypass.
- Members versus leavers. Compare the member list with HR records.
- Outside collaborators. Confirm each has an owner and an end date. See outside collaborators and base permissions.
- Two-factor. Confirm it is required for the organization.
Machines
- Deploy keys. GitHub notes they have no expiry and are not tied to membership, so review each one's purpose and owner. See deploy keys, GitHub Apps or machine users.
- Personal access tokens. Look for classic tokens and ones with no expiry; GitHub recommends fine-grained tokens. See fine-grained or classic tokens.
- Apps and OAuth apps. Remove those nobody uses and check requested permissions.
- Automation accounts. Confirm ownership and last use.
Rules and exceptions
- Rulesets and branch protection. Confirm the baseline still applies to every important branch.
- Bypass lists. Check each name on the list and why it is there. See ruleset bypass lists and layering.
- CODEOWNERS. Confirm owners still exist and have write access.
- Fork settings and workflows. Check approval levels for fork pull requests.
Evidence to keep
Save a dated export or screenshot per item, with a short note of changes and who approved them. Store them in one folder per quarter. Auditors usually want to see that the review happened, who did it, and that findings were closed.
Make it smaller next time
Every item you remove, such as an unused token, shortens the next review. Automate the list pulls where your platform allows, and set calendar owners for each section.
Assign each section to a named person and give them a due date before the review meeting, so the meeting is for decisions rather than data gathering. A person who owns the list of deploy keys will know which ones are live; a person who owns the contractor list will know which contracts ended. Close each finding with a ticket, and record the ticket number next to the item so the evidence trail is complete.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how one control can map to several frameworks.
Quick check
How often should access reviews happen?
Quarterly is a common baseline. Your policy or auditor may set a different frequency, so check it.
What counts as evidence?
A dated export or screenshot, who reviewed it, and the changes made.
Safeguard compliance and evidence automation can help you collect and store these records.
Last reviewed: 19 October 2026.
