Once a month, list every outside collaborator, match each to an approved request and end date, then search the audit log for access changes since your last review. Remove anything unmatched, record what you did, and file the notes. It takes about thirty minutes and produces the evidence auditors ask for.
Why monthly
GitHub's audit log lists events for the past 180 days, and only organization owners can open it. A monthly review leaves plenty of margin, so a change made early in the window is still visible when you look. If you review once a year, you will have lost most of the history.
GitHub also describes other ways to access and retain audit log data, including an API endpoint, and notes that each method exposes a different subset. For longer retention, stream or export the log to your own storage. If your organization belongs to an enterprise, GitHub advises working with an enterprise owner to enable streaming and set a retention period.
What you need before you start
- An access register: one row per contractor with name, GitHub username, repositories, role, sponsor, approval date and end date.
- An owner account that can read the audit log.
- Ten minutes of your sponsor's time if something looks wrong.
The 30 minute routine
| Step | Minutes | Action |
|---|---|---|
| 1 | 5 | Export the list of outside collaborators and the repositories each can reach |
| 2 | 5 | Match each person to a register row, flag unmatched or expired ones |
| 3 | 10 | Search the audit log for access related events since last month |
| 4 | 5 | Check tokens, keys and invitations tied to flagged people |
| 5 | 5 | Remove, extend or escalate, and write the notes |
Step three in detail
The audit log supports searching with the action qualifier, and events are grouped into categories. Use it to look for events that add or change collaborator access, repository permissions, deploy keys, and changes to branch protection or ownership files, then filter by the date range since your last review. The documentation lists all categories and example queries, so build your saved searches from it rather than from memory. Examples of what to look for:
- Who was added as a collaborator, by whom, and was there a request?
- Did anyone change a repository role upward?
- Were deploy keys added or removed?
- Were protection rules changed or disabled for a repository a contractor works on?
- Did an unfamiliar account gain access?
Decisions
- Unmatched person with access. Remove first, ask questions after. Reinstatement is easy for the first three months.
- Past end date. Remove unless the sponsor extends in writing.
- Role higher than needed. Lower it and note the reason.
- Missing 2FA or odd activity. Escalate to your security contact.
The record
Write down the date, who reviewed, the number of contractors, what you removed and why. Store it where the audit team can find it. This record is often the whole answer to an access review question, and it is the same evidence discussed in access review evidence auditors look for.
Where it fits
This routine catches drift. The contractor offboarding checklist handles the planned exit, and the intake process for invitations controls the front door.
Safeguard's compliance and evidence automation can schedule and store recurring control evidence like this, and its asset discovery helps you check the repositories you expect against what exists. See the free scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through it and compare continuous checks with the monthly manual review described above.
Quick check
How far back does the GitHub organization audit log go?
GitHub's documentation says it lists events from the last 180 days, and only owners can access it.
What if I need to keep history longer?
Export or stream the log to your own storage. GitHub describes API access and enterprise streaming for this purpose.
Sources
- Reviewing the audit log for your organization
- Removing an outside collaborator from an organization repository
Last reviewed: 19 October 2026.
