GitHub offboarding playbook for private engineering teams

Weak offboarding is one of the clearest ways a GitHub org drifts out of control.

If a leaver, contractor, or internal mover keeps repo access after they should not, the problem is rarely one missed click. The problem is that the access model depends too heavily on scattered direct grants and weak review habits.

TL;DR

Problem: people leave, roles change, and contractor work ends, but GitHub access often lingers in teams, direct grants, and old automation paths.
Who this is for: GitHub org admins, engineering managers, platform teams, and anyone responsible for joiner-mover-leaver controls.
What this helps you fix: a practical offboarding sequence for members, teams, direct repo grants, external collaborators, service accounts, and evidence of cleanup.

1. What fails in real orgs

The user is removed from the company directory, but still has direct access to one or more repositories.
A contractor leaves, but stays on a broad team because nobody owns the cleanup step.
An internal mover loses one team membership but keeps admin access on older repos.
A machine user or bot token still has more access than the workflow now needs.
The security team asks for proof of removal, but nobody kept a dated record of what changed.

2. The practical sequence

Remove or suspend the user at the org level when appropriate.
Remove the user from teams that no longer apply.
Review direct repository grants and revoke those that are no longer justified.
Review outside collaborator access for contractors, vendors, and short-term partners.
Check service accounts, bot users, and automation credentials owned by the departing person or team.
Record what was removed, what stayed, and who approved any remaining exception.

3. Treat direct grants as the danger zone

Team-based access usually offboards cleanly because membership drives the change. Direct repo grants are where access lingers. That is why direct grants should be rare, temporary where possible, and easy to review.

If your current model relies on lots of direct grants, you do not just have an offboarding problem. You have a structure problem. Read GitHub team access vs direct repository access if you need the argument laid out clearly.

4. Contractors and vendors need their own rule set

Keep contractors and vendors separate from broad employee membership teams.
Prefer narrower teams or explicit short-term access over inherited broad access.
Set a review date when the access is granted, not after the engagement becomes fuzzy.
Do not hide contractor access inside generic department teams.

5. What evidence you should keep

Date of offboarding review
Who performed it
Which teams and direct grants were removed
Any exception that remained, with owner and reason
Follow-up action for machine accounts or vendor access

That is enough to make later reviews faster and to stop the same access from quietly reappearing.

6. Where repod helps

repod is useful when offboarding slows down because nobody can review current repo-team access and direct exceptions quickly enough. It gives you a clearer org-wide picture, a safer review path, and a simpler way to spot the access that did not move with team membership.

For the broader operating model, read the GitHub governance and permission drift guide. For the audit angle, continue with the GitHub permission audit checklist.

Audit repo access