How to Run a User Access Review That Actually Revokes Access

An access review that produces a signed spreadsheet but leaves the entitlements in place is not a review. It is a compliance ritual. Auditors are increasingly asking for the API response from the revocation, not the manager's checkmark. That is the standard this playbook targets.

The mechanics are boring and the failure modes are predictable. Here is what actually works.

What is a user access review and what makes one fail?

A user access review (UAR) is the periodic process of confirming, per user and per entitlement, that the access is still justified by the person's role. If not, the entitlement is revoked in the source system. In the SOC 2 language, it is the operational proof of CC6.1 (logical access controls) and CC6.3 (removal of access on role change or termination).

Reviews fail in three predictable ways.

• Rubber-stamp approvals. Reviewers get a spreadsheet with 300 rows of raw scope strings, click "approve all", and the campaign closes with zero revocations. Auditors now sample-test this pattern explicitly.
• Revocations that never execute. The reviewer clicks "revoke", IT gets a ticket, the ticket sits in a queue, the user still has access 45 days later. The campaign is closed but the risk is not.
• Coverage gaps. The review covers Okta groups but misses IAM policies attached directly to users, GitHub outside-collaborator invites, and admin access inside SaaS apps that predate the SSO rollout.

Any one of these turns the review into audit theater. All three together are the norm.

What entitlements should be in scope?

Everything that can read, modify, or approve regulated data. The clean scope is easier to name in a table than in prose.

The rule of thumb: if a person can act on production data with the entitlement, it belongs in the review. If they can only see a public marketing wiki, it does not.

Who is the right reviewer for each entitlement?

The direct manager, not IT. IT owns the connectors and the evidence, not the judgment call.

• Standard SaaS access. Direct manager of the user. Reviews their whole team in one campaign view.
• Privileged production access. Direct manager plus the application or system owner as a second reviewer. Two-person approval is the SOC 2 baseline for privileged access.
• Service accounts. The application owner, always. Service accounts have no manager. Route them explicitly or they become orphans.
• Shared accounts. Kill them. Do not review them. If you cannot kill them, name a single accountable owner and treat it as privileged.

The other rule: reviewers see only their own reports. A campaign that shows a manager the whole company's entitlements is a campaign the manager will not finish.

How do you translate raw entitlements into decisions reviewers can make?

Reviewers need three things per entitlement, on one line: what it grants in plain language, when the user last exercised it, and a one-click decision.

• Plain language. iam:* is not a decision prompt. "Full admin access to production AWS, including billing and IAM" is a decision prompt.
• Last-used timestamp. Dormant for 90+ days is the single strongest revocation signal. Highlight it.
• One-click decision. Approve, revoke, or escalate. Anything more (comments, tickets, forms) triples campaign time.

If you can only add one column to your review UI, add last-used. It changes reviewer behavior more than any other change.

What SLA should you set for revocation?

Five business days from the reviewer clicking revoke to the entitlement gone in the source system. Not a ticket in a queue: gone. Track it as a first-class SLA, separate from the campaign completion date.

• Day 0. Reviewer clicks revoke. System of record calls the source app's API. For apps with a write API (most), the change lands immediately and the response is logged.
• Day 1 to 3. For apps without a write API, IT gets a task with the exact change and a due date. Task cannot close until a screenshot of the executed change is attached.
• Day 5. SLA breach alert to the CISO. Every breach becomes a finding in your next SOC 2 report, whether or not the auditor sees it.

An SLA that names a day but has no consequence is not an SLA. The consequence is public visibility, not punishment.

What goes into the evidence bundle?

Auditors want six artifacts per campaign, ordered by weight.

1. Entitlement population snapshot at campaign start. CSV of every user, every entitlement, every system, timestamped.
2. Reviewer decision log. Every row, the reviewer's identity, the timestamp, the decision.
3. Revocation execution proof. For every "revoke" decision, the API response or the ticket close with the executed-state screenshot.
4. Exception list. Anything the reviewer flagged as needing extended review, with the owner and the target close date.
5. Control mapping. The bundle indexed to SOC 2 CC6.1 to CC6.3, ISO 27001 A.5.18, HIPAA 164.308(a)(4), whatever is in scope for your framework.
6. Signed campaign attestation. One-page statement, signed by the CISO or head of IT, confirming the population was complete and the process ran as documented.

Deliver all six as a single bundle per campaign. If your auditor has to ask for artifact number two, your process is not mature enough to test.

How do you close a review in ten business days?

The cadence is the same every quarter. Print it and pin it.

• Day 0. Snapshot entitlement population. Launch campaign. Reviewers get one Slack ping and one email.
• Day 3. First reminder to non-starters. Highlight dormant access to nudge quick wins.
• Day 6. Escalation to reviewer's manager for any campaign under 50% complete. This is where campaigns usually stall.
• Day 8. All reviewer decisions in. Revocation SLA clock starts.
• Day 10. Campaign closed. Evidence bundle exported. Any open revocations tracked as breaches, not as open reviews.

If your review takes six weeks, the actual campaign is one week and the drift is five. Compress the drift, not the review.

The mistake to avoid

Most access reviews fail not because reviewers are lazy but because the system is asking them the wrong question. "Should Priya still have iam:*?" is unanswerable. "Priya has full production AWS admin, has not used it in 94 days, is on the growth team, click approve or revoke" is answerable in three seconds. Redesign the question, add the last-used signal, and enforce a revocation SLA with public visibility. Everything else, including which vendor runs the review, is downstream of those three moves.