When an auditor tests your user access review, they are not checking that a review happened. They are checking three things: that someone looked at a complete list of who has access to what, that the person looking had the standing to say “this person should not have this”, and that the decisions turned into actual removals.
Most reviews that produce exceptions fail on one of those three, not on the review itself. The spreadsheet exists, the sign-off is there, and the exception still lands because the list was missing four systems, or the reviewer was the same admin who provisions the accounts, or six accounts marked for removal were still active at the end of the period.
What the auditor is actually testing
Two separate questions sit behind every access review test.
The first is design: is this control capable of catching inappropriate access? A review that only shows account names with no roles or entitlements cannot answer “does this person have more than they need”, so it is weakly designed regardless of how diligently it is performed.
The second is operation: did it run at the frequency and in the manner your own description says? This is where the words you wrote come back to you. If your system description says “quarterly access reviews are performed by system owners across all in-scope production systems”, the auditor will test quarterly (four cycles in a twelve-month period, reasonably spaced), system owners (not the person who administers the accounts), and all in-scope systems (reconciled against the system list in your description).
An exception here is usually measured against your own stated policy, not against an external benchmark. That is worth internalising: the most avoidable access review finding is committing to a cadence you do not run.
Completeness of the population decides the outcome
There are two populations in an access review, and auditors probe both.
The list of systems. The question is always some form of “how do you know this is every system?” Answering “this is the list we maintain” is circular. Answering with a reconciliation is not. Tie your in-scope system list to something independent — the application catalogue in your identity provider, your cloud account inventory, and the software line items in accounts payable or the corporate card statement. The three together catch most of what a hand-maintained list misses, particularly the tool a single team bought on a free tier and never told anyone about.
The list of accounts within each system. This needs to be a system-generated export with a date on it, not a list someone typed. A console or API export that the auditor could ask you to re-run is evidence. A tidied-up spreadsheet is an assertion.
The export has to include the account types people habitually leave off, because those are precisely the ones most likely to be wrong: service accounts and API keys, contractors and temporary staff, shared or break-glass accounts, third-party support users, and anyone holding administrative privilege. A review that covers only named employee accounts has excluded the highest-risk population from itself.
Some auditors will ask you to re-run an export during fieldwork and tie the record count back to what you reviewed months earlier; others will accept the original export with its metadata. Practice varies, so keep the raw file, not just the annotated version.
What a review record needs on it
For each system and each cycle, the record should hold:
- The population as pulled, with the source system and the date it came from
- The reviewer’s name and their relationship to the system — owner, manager, or whoever your policy nominates
- A decision on every line, not just the ones that changed
- The remediation trail: for each account marked for removal or downgrade, a ticket and a timestamp showing it happened
- A dated sign-off recorded in a system, not in an email thread
The gap that produces the most exceptions is the fourth one. Reviewers mark “remove” and the record ends there. Auditors will select flagged accounts and trace them to revocation, and an account still active weeks later is a finding even though the review itself was performed properly.
The failure modes that produce exceptions
Self-review. The administrator who grants access is the person confirming it was appropriate. There is no independent judgment in that loop, and it is a design problem, not an evidence problem.
Compressed timing. Four quarterly reviews all completed in the same fortnight of month eleven. The dates typed into a spreadsheet say quarterly; the file metadata, ticket timestamps and export dates say otherwise, and auditors look at the latter.
Rubber-stamping. Zero removals across an entire period at a company with normal turnover invites the question of whether anyone actually read the list. Removals are not the point of the control, but their complete absence is a signal.
Reviewing groups without reviewing membership. Confirming that “the engineering group has deploy access” is not the same as confirming who is in the engineering group. Both halves need to be looked at, in whichever order suits your identity provider.
Systems left out. The data warehouse, the support tool with customer records, the payment processor console, the source code repository, the cloud provider root account. Each one omitted is a hole in the population.
Stale entitlements from role changes. Someone moved from support to engineering and kept both sets of access. Reviews that check only leavers miss this entirely, and internal movers are a common source of accumulated privilege.
Running it so the evidence is a by-product
The teams that find access reviews cheap have made the review produce its own record.
One ticket per system per cycle. The export is attached at the top of the ticket. Decisions are recorded in the ticket. Removals are child tickets that close with a revocation timestamp. Sign-off is a field, not a reply-all. At the end of the cycle the evidence package already exists, because it is the ticket.
Pull exports on a fixed date with a scheduled job. If the export lands automatically on the first working day of the quarter, nobody has to remember, and the timestamp is system-generated rather than typed.
Cross-check against the leaver list in the same cycle. Pull terminations from your HR system for the period and confirm none of them appear in any access export. This takes minutes and catches the offboarding misses that would otherwise surface as separate findings.
Shrink the surface you have to review. Every standing entitlement you replace with group-based or time-bound access makes the review smaller and the population easier to defend. Reviewing fifteen group definitions plus their membership is a different job from reviewing four hundred individual user-to-app grants.
How often, and against what scope
Practice varies more than people expect. Quarterly reviews for systems holding production or customer data, with annual reviews for lower-risk internal tools, is a common and defensible split. Some auditors accept semi-annual across the board for smaller organisations; some enterprise buyers reading your report will not be satisfied by that regardless of what your auditor accepted.
The cadence matters less than three things being consistent with each other: what your policy says, what your system description says, and what you actually did. Where those three agree, a reasonable cadence holds up. Where they disagree, even an aggressive cadence produces an exception.
What to do next
Pull the user list from your single most sensitive system right now, and put it next to your HR active-employee list. Every account in the first that is not in the second needs an explanation — contractor, service account, or a leaver nobody removed. That five-minute exercise tells you more about the state of your access controls than a quarter of policy writing.
Then read your own access control policy and count whether you performed the number of reviews it commits you to. If the answer is no, change the policy to a cadence you will actually run before your observation window starts, rather than carrying the gap into fieldwork.
Assurion performs SOC 2 and ISO 27001 examinations and can tell you during readiness whether your review records will hold up before they are tested.