User Access Review

You make sure the only people with access are the ones who should have it, with no more power than the job needs. Former staff with live accounts, admin rights handed out "temporarily" two years ago, and API keys nobody owns are among the most common ways small companies get breached. The review produces decisions on record, so an auditor can see who decided what and when.

When to use

• "Do our quarterly access review."
• "Sam left on Friday; make sure all their access is gone."
• "Who has admin on our AWS / Google Workspace / GitHub?"
• "The SOC 2 auditor needs evidence of access reviews."
• After a reorganisation, an acquisition or a security incident.

What you need

• The people roster: name, email, role, team, manager, start date, leave date, employee or contractor. From the HR system if connected, or a sheet the owner provides.
• A list of systems in scope, with an access owner for each (the person who decides who should have access).
• Read access to each system's user and permission list: an admin console in your browser signed in by the owner, a connected app (Google Workspace, GitHub, Slack and so on), or CSV exports the owner provides. Read-only roles are enough for the review itself.
• The previous review, if any, to carry over accepted exceptions.

Method

1. Scope the systems, most critical first: identity provider or email suite, cloud consoles, code hosting, production databases and servers, password manager, finance, payroll and banking, CRM and customer data tools, domain registrar and DNS, social media and ad accounts. Use todo to track one item per system.
2. Export accounts from each system into one sheet with these columns: system, account, display name, email, role or permission level, MFA status, last login, created date, account type (human, service, shared, guest), and for keys and tokens their creation date and last use. Save the raw exports unchanged with the date; they are audit evidence.
3. Match accounts to people by email first, then by name. Use execute_code for anything over a few dozen rows. Every account ends up matched to an active person, a known service, or nothing.
4. Flag each row with every rule it hits:

   Flag	Rule	Default action to propose
   Leaver	Matched person has a leave date, or no match at all	Remove (highest priority)
   Dormant	No login for 90 days (or the owner's threshold)	Disable after confirming with the access owner
   Excess privilege	Admin or write access the role does not need	Reduce to the role's standard access
   Too many admins	More admins than the system needs	Reduce; keep at least two for recovery
   No MFA	MFA not enrolled where available	Enrol, then enforce
   Shared account	One login used by several people	Replace with named accounts, or store in the password manager with an owner
   Orphan service account	No named owner or purpose	Assign an owner or disable
   Stale key	Key or token older than 90 days, or unused for 90 days	Rotate or revoke
   Guest or external	Contractor, agency or partner access	Confirm end date and sponsor
   Risky app grant	Third-party OAuth app with broad scopes (mail, drive, repo admin)	Confirm need; revoke if unknown
   Duty conflict	One person can both create and approve payments, or both write and deploy code without review	Split or add a review control

5. Send decisions to access owners. Give each access owner only their system's flagged rows, with a clear keep, modify or remove choice and a due date. Ask through ask_teammate or the owner. Record who decided, the decision and the date. Silence is not approval: chase, then escalate to the owner.
6. Apply only approved changes, and only with the owner's explicit go-ahead. Prefer disable over delete for the first 30 days. For leavers, transfer ownership of their files, shared drives, repos and scheduled jobs before removal, and check for mail forwarding they set up. Revoking a service account key can break production: agree a time with the service owner.
7. Verify. Re-export after changes and confirm each approved removal took effect. Save the after-export with the date.
8. Fix the process. If leavers were found, the off-boarding step that missed them needs fixing: write it down as an action for the owner.
9. Schedule the next review with cronjob: quarterly for all systems, monthly for privileged access, and a same-day leaver check whenever the roster shows a leave date.

Single leaver checklist

Use this when someone leaves, without waiting for the quarterly review. Every step needs the owner's go-ahead and is logged with a time.

• Suspend the identity provider or email account first; this cuts off single sign-on apps.
• Revoke active sessions and app passwords; remove their MFA devices from the account.
• Remove them from SaaS tools that use local logins (check each one, not just single sign-on).
• Rotate any shared passwords or keys they knew; remove their SSH keys from servers.
• Revoke personal access tokens and OAuth apps they authorised for company accounts.
• Transfer ownership of documents, shared drives, repositories, calendars and scheduled jobs.
• Check for and remove mail forwarding rules and delegated mailbox access.
• Set up email auto-reply or forwarding to their manager if the owner wants it.
• Recover company devices and remove them from device management.
• Record completion on the leaver checklist with the date; this is audit evidence.

Output

• The review workbook (CSV or spreadsheet): all accounts, flags, decisions, decider, date, action taken, verified.
• An evidence folder: before and after exports, dated, plus the decision log.
• A short summary on a show_card: accounts reviewed, flags by type, changes made, exceptions accepted, overdue decisions.

Access review <quarter> | <date>
Systems: 12 | Accounts: 214 | Flagged: 37
Leavers removed: 4 | Dormant disabled: 9 | Admin reduced: 6 | MFA gaps closed: 5
Accepted exceptions: 3 (listed, with review dates) | Awaiting decision: 2 (owner chased)

Checks before you finish

• Every flagged row has a decision, a decider and a date, or is listed as overdue.
• Every removal was approved and verified in a fresh export.
• Leavers' data ownership was transferred before removal.
• Raw exports are saved unchanged with dates.
• The next review is scheduled.

Pitfalls

• Reviewing only the identity provider. Many SaaS tools have local accounts outside single sign-on. Check each system's own user list.
• Rubber-stamping. Access owners approving everything without reading is the classic audit finding. Send them only the flagged rows, with the reason, so they can actually decide.
• Deleting instead of disabling. Deletion can destroy data and evidence. Disable first, delete later.
• Forgetting non-human access. API keys, service accounts, deploy keys and OAuth apps often hold wider rights than any person.
• Leaving the owner as the only admin. Keep a second admin or break-glass account so a lost phone does not lock the company out.
• Sign-off. Each access owner decides for their system; the owner signs off the review as a whole. You never remove access without that go-ahead.