Guide · 7 min read
How auditors actually test your user access reviews
A practical guide to how IT auditors test user access reviews: population completeness, reviewer independence, evidence of removals and the common reasons reviews fail.
Most teams treat the quarterly access review as a signature exercise. A spreadsheet goes to managers, they reply "all fine", someone files the email, and the control is marked as operating. Then the auditor arrives and the review fails, usually for reasons that have nothing to do with whether the access was actually right.
Having sat on both sides of the table, I can say auditors don't test whether you did a review. They test whether the review could have caught a problem. Here is what that looks like in practice.
1. They start with the population, not the sign-off
The first request is almost always the user listing the review was based on, and how it was produced. The auditor wants to know three things:
- Was it pulled from the system itself (not from an old spreadsheet)?
- Was it complete, including service accounts, generic IDs and admin roles?
- Can you show how it was generated: the report name, parameters, date and who ran it?
If the listing came from a "saved copy" or someone filtered out accounts before sending it, everything after that point is built on sand. A quick fix: save the query or report screenshot with the extract, and record the total account count before anything is filtered.
2. They reconcile it against HR
Next, the auditor takes the HR leavers and movers list for the period and compares it with the user listing. Any leaver who still has an active account, or any mover who kept their old access, is an exception, even if the manager approved it in the review. In fact, a leaver who was "approved to keep" is worse: it shows the reviewer didn't really look.
3. They check who reviewed whom
Reviewers need to be independent of the access they approve. Common failures:
- An administrator approving their own admin rights.
- A system owner reviewing a list that includes their own account.
- A manager who left the company still listed as the reviewer.
Make sure self-review is routed to someone else, and that reviewer assignments are refreshed from HR each cycle.
4. They follow the removals through
This is where most reviews fall apart. The manager ticks "revoke", but nobody checks it actually happened. Auditors pick a sample of revoked items and ask for proof: a ticket, a system log showing the account disabled, a fresh listing without the user. A request to revoke is not evidence of revocation.
5. They look at timing and precision
Was the review done within the period the control says (quarterly means quarterly)? Were all the rows actually reviewed, or did someone approve 900 rows in four minutes? Some auditors look at the timestamp spread in the tool for exactly this reason. They also check that toxic combinations, such as creating and approving a payment, were flagged rather than approved row by row.
What a review that holds up looks like
- A complete, system-generated listing with evidence of how it was produced.
- Reconciliation to HR leavers and movers, with exceptions explained.
- Independent reviewers, with self-review routed elsewhere.
- Each "revoke" closed with proof of removal, and a final listing to confirm.
- Two-level sign-off: reviewer, then control owner.
None of this needs an expensive tool. It needs the review to be treated as a control that detects problems, not a form that gets signed.