How to Run an Access Review Without Annoying Everyone
A practical process for running user access reviews that satisfies auditors and doesn't turn your managers into ghosts.
The tell is the silence. You're mid-audit prep, the CPA asks to see evidence of your last access review, and the room goes quiet for three seconds too long. Someone pulls up a spreadsheet from eight months ago that was never fully completed. The auditor writes something down.
Access reviews are one of those controls that teams start with good intentions and then let slide because nobody built the process to be sustainable. The quarterly calendar reminder fires, a manager ignores the email, the security person nudges them, a week passes, and eventually a half-done spreadsheet gets saved as "final."
The fix isn't better nagging. It's a tighter process — one where each person's job is narrow enough that not responding is obviously wrong, and where the total burden per review is small enough that it actually gets done.
What an access review is and why it matters beyond SOC 2
An access review is a scheduled check that confirms every active user account has access to the right things and nothing extra. Users leave, get promoted, change teams, take on side projects that end. Each transition is an opportunity for permissions to accumulate, and those permissions rarely get trimmed proactively.
The reason auditors focus on this isn't bureaucratic — it's because standing access that nobody's examined in a year is one of the most common paths for both external attackers and insider threats. The principle is the same one that least privilege captures: nobody should hold access they don't actively need.
For SOC 2 specifically, CC6.3 in the Trust Services Criteria requires that you authorize, modify, or remove access based on approved authorizations, and that you have a process to review and update access when people's roles change. What auditors want to see is evidence that someone, on a specific date, looked at a list of who had access to what, made explicit decisions, and acted on them. "We trust the IT team" is not evidence. A signed-off spreadsheet with a date is.
HIPAA, ISO 27001, and PCI DSS all have analogous requirements. But honestly, you'd want to do this even without a compliance driver.
Scope it narrowly at first
If you try to review access to every system your company uses in the same quarter, you'll build a process nobody finishes. Start with the systems that matter most: the ones in your SOC 2 scope if you're on that path, or the ones holding your most sensitive data if you're not.
Tier your systems. A reasonable first cut:
- Tier 1 (critical): Production infrastructure, databases, identity provider (Okta/Google Workspace/Azure AD), cloud root accounts, code repositories, any system with customer data.
- Tier 2 (significant): Internal tools with broad visibility, financial systems, HR platforms.
- Tier 3 (standard): Everything else.
Review Tier 1 quarterly, or at minimum twice a year. Tier 2 annually is acceptable. Tier 3 is often "review when someone leaves." You don't need to defend reviewing Slack the same week you audit production AWS.
Start your first formal review with just the Tier 1 list. Completing that cleanly is worth more than a half-finished review of 40 systems.
The process that actually works
Here's the version that gets done instead of dragging out for three weeks.
Pull the access list first. Don't ask managers "do you know who should have access to X?" Ask them to review an actual list. Export current users from each system. Then cross-reference against your HR system or directory — you want to flag anyone whose account is active in a system but who has left the company or changed roles. These are your highest-risk entries and should be caught before the list even goes to managers.
Give each manager exactly their people. Don't send one person a list of 200 accounts across 8 systems. Slice it by manager. Each person sees only the direct reports who have access to each system, and their only job is to say "yes, this is right" or "remove this." Binary decisions take seconds; judgment calls take days.
Set a hard 5-day window. Not "please respond by end of month." A specific date, 5 business days out. After that, you follow up once. After that, you escalate to their manager. Make this policy in writing so people know what happens if they ignore it. The teams that get 100% completion are the ones where non-response has a consequence.
Document the outcome for every account, including accounts where the answer is "access is fine, no change needed." This is the mistake I see most often: people record the removals but not the approvals. An auditor needs to see that you looked at every account and made a deliberate decision, not just that you removed some. A row in your spreadsheet that says "Reviewed 2026-08-10, access confirmed by manager Sarah K., no change" is evidence. A blank row is not.
Act on removals within 24 hours. If you're reviewing access and then waiting a week to actually deprovision accounts, you've got a gap in your process. Assign one person to execute removals, set a deadline, and log when it happened.
Getting managers to actually respond
The access review email that gets ignored is usually either too long, too vague, or too easy to deprioritize. A few things that help:
Give the ask a subject line that states exactly what's needed: "Action required: access review for [System], due [date]." Not "Security review Q3."
Lead with the list, not the explanation. If you need to give context, put it after the table, not before. The first thing a manager sees should be the accounts they're reviewing and the two options for each.
Remind them once, on day 4. One nudge, not three. If they haven't responded by day 5, escalate to whoever manages them. This is not aggressive — you're enforcing a control that has a real audit finding on the other side.
If your company has a security committee or leadership buy-in for the program, have that sponsor send the initial announcement. A note from the CISO carries more weight than one from whoever is running the review.
The access review you don't schedule
Event-triggered reviews matter as much as periodic ones. When someone leaves the company, their access should be removed the same day — ideally automatically through your identity provider, but manually if that's not set up. When someone transfers to a different team, their old access should be reviewed within a week. When a vendor's contract ends, their accounts should go with it.
These aren't audit theater; they're the cases where stale access most often causes real problems. Build the offboarding checklist once, verify it happens for every departure, and document it. That evidence is often more convincing to an auditor than a perfect semi-annual review, because it shows the habit is real.
Incident response playbooks and access offboarding should be linked — when you're handling a departure that ended badly, the access revocation steps need to happen immediately, not as a footnote to the normal review cycle.
What to watch out for
A few patterns that routinely produce incomplete or invalid reviews:
Self-review. If someone is reviewing their own access, that's not an independent control. A developer shouldn't be approving their own production database access. Find a second set of eyes for privileged accounts.
Reviewing a static snapshot. If you pull access lists on Monday and don't run the review until Friday, new accounts provisioned in between don't show up. Pull the list as close to the review date as possible, or include a note that the list was current as of a specific timestamp.
Not tracking what you reviewed. Keep a record of which systems were in scope each period. Auditors sometimes compare rounds — if you covered 12 systems last time and 8 this time, they'll ask why.
The first access review is always the roughest. You'll find accounts nobody knew existed, permissions that were provisioned "temporarily" two years ago, and systems where nobody thought to track access at all. That's expected. The value is in building the muscle so subsequent reviews get cleaner. Schedule the next one before the current one is done.