What auditors actually ask for in an access review
The user access review is the control most teams fail first — usually not because access was wrong, but because they can't prove it was checked.
14 July 2026 · 3 min read · SOC 2
Nearly every security framework asks the same question in slightly different words: do the right people have the right access, and can you show that someone checked? SOC 2 puts it under the CC6 common criteria, ISO 27001 covers it in A.5.15 through A.5.18, and India's DPDPA reaches it through the reasonable security safeguards a Data Fiduciary owes. Different clauses, one underlying control.
Teams usually pass the substance of this control and fail the evidence. The access itself is fine. What's missing is a record showing the review happened, who performed it, what they decided, and what changed as a result.
The four things you'll be asked for
- A complete list of accounts in each in-scope system, as of a date inside the audit period — not today's list.
- Evidence a human reviewed that list, with a name and a date attached to the decision.
- The outcome for anything flagged: revoked, retained with justification, or escalated.
- Proof the revocations actually happened — the part almost everyone under-prepares.
That last one is where reviews unravel. A spreadsheet marked "remove" is a decision, not a result. An auditor testing this control wants to see that the account is gone, and the strongest form of that is an independent observation after the fact — a fresh export from the system showing the account absent, dated later than the decision.
Why terminated users are the usual finding
Offboarding fails quietly. The identity provider gets deactivated on the last day because that's the account everyone remembers. The long tail — a cloud IAM user, a code-repository seat, a monitoring tool that was never wired into SSO — survives, because nothing forces anyone to look at it again.
The gap between "deactivated in the directory" and "removed everywhere" is the single most common access finding we see discussed, and it's structural rather than careless: the systems that hold the leftover access are exactly the ones outside the offboarding checklist.
Make the review continuous instead of quarterly
A quarterly review is a snapshot, and a snapshot can be up to three months stale. If you can compare your directory against every connected system continuously, the review stops being an event you prepare for and becomes a list that is either empty or not.
Two properties make that list trustworthy. First, a person marked inactive in your directory who still holds live access anywhere should surface immediately — no waiting for a cycle. Second, closing an item should require observing that the access is actually gone, not merely someone asserting they removed it.
A practical starting point
- Inventory the systems that grant access outside your identity provider — cloud consoles, code hosting, observability, payments, support tooling.
- For each, work out how to export the current principal list. If you can't export it, you can't review it.
- Reconcile that list against your directory roster, and treat every unmatched account as a question rather than an exception.
- Keep the before-and-after exports. The pair of them is the evidence; either one alone is not.
None of this requires a tool. It requires that the reconciliation happens on a schedule shorter than your audit period, and that removals are confirmed rather than assumed.
See it on your own evidence
Bring a policy document to a 20-minute call and we'll map it across your frameworks live.
Book a demo