User Access Reviews Auditors Accept (With a Template)

A user access review is a periodic check that every account in a system still belongs to someone who needs it, at the privilege level they need. It is one of the most commonly requested pieces of audit evidence — and one of the most commonly rejected, because teams submit a user list export when the auditor asked for a decision record.

The distinction matters more than any other detail in this article: an export shows state; a review shows judgement. A spreadsheet of everyone who had access in March proves only that you can query your own systems. What the auditor is testing is whether a named human looked at each of those accounts and decided something about it.

What the Frameworks Actually Ask For

Access reviews sit at the intersection of two framework requirements, which is why they come up in almost every audit:

• SOC 2 Common Criteria CC6 covers logical access — how access is registered, authorized, modified, and removed. Reviews are how you demonstrate that authorization stays correct over time rather than only at the moment of provisioning. See the Common Criteria explained.
• ISO 27001 Annex A.5.18 (access rights) covers provisioning, review, and removal of access rights. A.8.2 (privileged access rights) raises the bar for administrative accounts specifically, and A.5.15–A.5.17 cover the surrounding access-control, identity, and authentication practices. The complete Annex A guide maps how these fit together.

Neither framework prescribes a frequency. What both expect is that you define one, justify it against risk, and then actually hit it.

Step 1: Define the Population — This Is What Gets Tested First

Before an auditor looks at a single decision, they will test whether your list was complete. This is the step teams skip, and it is the step that invalidates everything downstream: if the population is wrong, every decision made against it is unverifiable.

Completeness means two things. First, you reviewed every account in the system, not just the ones you remembered — including service accounts, contractor accounts, shared accounts, and accounts belonging to people who left. Second, you can show where the list came from: a system-generated export with a visible source and timestamp, not a hand-maintained spreadsheet.

Practical way to satisfy it: export the user list directly from each in-scope system, capture the export date and the person who ran it, and reconcile the total against your HR roster and your asset and system inventory. Any account that appears in the system but not in HR is either a service account you need to document or a finding you need to fix.

Step 2: Pick Frequency by Risk, Not by Habit

Frequency should follow the blast radius of the access. A defensible pattern for a small team:

• Privileged and administrative access — quarterly. Production infrastructure, cloud root and admin roles, database admin, anything that can grant further access.
• Standard access to systems holding customer data — semi-annually or annually, depending on how sensitive the data is and how much your headcount moves.
• Event-driven, in addition to the calendar — a review triggered by a role change, a team reorganization, or a departure, rather than waiting for the next scheduled cycle.

Write the frequency into your access control policy and then meet it. An auditor comparing a policy that promises quarterly reviews against evidence of two reviews in a year will raise a finding — and the finding is against the missed commitment, not the frequency itself. A policy you actually follow beats an ambitious one you don't.

Step 3: Make Sure the Reviewer Isn't Reviewing Themselves

Independence is the second-most-common rejection reason. The person who reviews an account should not be the person who holds it, and ideally not the person who provisions access either.

For most small companies the workable model is that the system owner or the account holder's manager performs the review, and someone else — a founder, the security lead, whoever owns the ISMS — signs off on the review as a whole. That gives you two names on the record, which is what the auditor is looking for.

The awkward case is the two-person startup where the CTO owns every system and holds every admin credential. The honest answer is not to pretend otherwise: have the other founder review the CTO's access, document that the segregation is constrained by team size, and note the compensating controls (logging, alerting on privilege changes). Auditors accept documented, reasoned constraints far more readily than fictional separation.

Step 4: Record a Decision Per Account

This is the part that turns an export into a review. Every row in the population needs an explicit outcome — and "no action" is an outcome, as long as a human chose it.

The last two columns are the ones teams leave empty, and they are the ones auditors check hardest.

Step 5: Close the Loop — Approved Is Not Removed

A review that identifies twelve accounts to revoke and revokes none of them is worse than no review at all: it documents that you knew about a problem and didn't fix it. Auditors routinely sample the revocations from your review and go look in the live system to confirm the account is gone.

So the evidence package for each cycle needs three artifacts, not one:

1. The population export, with its source and date.
2. The completed review record, with per-account decisions, reviewer names, and dates.
3. Proof of remediation — tickets, change records, or a follow-up export showing the revoked accounts are actually gone.

That third artifact is what converts a review from an assertion into evidence. For how this fits the broader evidence picture, see what auditors actually want as evidence.

Reviews Catch What Offboarding Missed

It helps to be clear about what job the review is doing. Offboarding is your preventive control: when someone leaves, their access goes with them, same day. The access review is the detective control that catches the cases where offboarding didn't fire — the contractor whose engagement quietly ended, the SaaS tool that wasn't on the offboarding checklist, the service account created for a migration that finished a year ago.

If your access reviews consistently surface departed employees, the finding isn't really about the review. It's about the offboarding process, and that is where the fix belongs.

The Anti-Patterns

• Submitting the export as the review. State, not judgement. The most common rejection there is.
• Reviewing only the systems that are easy to export. Auditors ask about the in-scope systems, including the awkward ones.
• Bulk-approving every row in one click. A review where 100% of accounts were retained in a growing company invites scrutiny — and if nothing ever changes, the reviewer isn't reviewing.
• Forgetting service and shared accounts. These carry the most privilege and the least ownership.
• Leaving no trace of the remediation. The decision without the follow-through is an unclosed finding.

The Takeaway

Access reviews are not hard, but they are exacting: a complete population from a system export, a reviewer who doesn't hold the access, an explicit decision on every account, and proof that the revocations actually happened. Run that four times a year on your privileged accounts and the evidence request stops being a scramble.

Next: the year-round monitoring checklist for where reviews sit in the wider calendar, SOC 2 evidence collection for the rest of the request list, or see how automated evidence collection keeps the population and the proof together.