Sample template. A starting point to adapt to your organization — not legal advice, and not a finished or binding document. Review with your own counsel before you rely on it.
User access review checklist
Updated
A user access review (UAR) is a periodic check that the right people have the right access and no one has more than they need. It is a core control for SOC 2, SOX ITGCs, and most security frameworks, because stale or excessive access is one of the most common paths to a breach or a control failure. This checklist covers what to review and, just as important, how to evidence it so the review holds up in an audit.
The failure mode of access reviews is not skipping them — it is performing them without evidence, or rubber-stamping. An auditor wants to see who reviewed what, when, what they decided, and that revocations actually happened. Build the checklist around producing that trail, not just clicking approve.
What to review
Scope the review to the systems that matter — those in scope for your framework and those holding sensitive data — and for each, pull the current access list. Review it against what each person's role actually requires, paying special attention to the high-risk cases below.
- All active accounts on in-scope systems, with the access each one holds.
- Privileged and administrator access — reviewed with extra scrutiny.
- Terminated or transferred employees — confirm access was removed on time.
- Service and shared accounts — owner, purpose, and whether still needed.
- Segregation-of-duties conflicts — one person holding incompatible duties.
- Dormant accounts — active credentials with no recent use.
- Third-party and contractor access — scoped and still required.
How to evidence each decision
For every entry, the reviewer records a decision — retain, modify, or revoke — with enough context to defend it. The reviewer should be someone who knows what the access is for (typically the resource or people manager), not just whoever ran the export. Independence matters: the person reviewing should not be approving their own access.
- Capture the reviewer, the date, and the decision for each account.
- For 'retain', a brief business justification tied to the role.
- For 'revoke' or 'modify', a ticket or record that the change was actually made.
- Evidence that revocations completed — not just that they were requested.
- A sign-off that the whole review was completed for the period.
Common pitfalls that fail an audit
The recurring findings are predictable, so design them out. Reviews performed but not evidenced; revocations requested but never confirmed complete; the same person granting and reviewing their own access; and reviews that are late or skipped for a period. Each turns a control that exists into one that cannot be relied on.
Cadence and completeness also matter. Most frameworks expect access reviews at least quarterly for sensitive systems, and the review must cover the full population, not a convenient sample. A review of half the accounts is a partial control, and an auditor will scope its assurance to what was actually covered.
Frequently asked questions
What is a user access review?
A periodic control that verifies the right people have the right access and no one has more than they need. Reviewers examine each account on in-scope systems against role requirements and decide to retain, modify, or revoke — with evidence of the decision and confirmation that revocations completed. It is core to SOC 2, SOX ITGCs, and most security frameworks.
How often should access reviews be performed?
Most frameworks expect at least quarterly reviews for sensitive and privileged systems, and the review must cover the full population rather than a sample. The exact cadence follows your framework and risk, but the key disciplines are completeness and a recorded next-review date so no period is skipped.
Why do access reviews fail audits?
Usually not because they were skipped, but because they lacked evidence: reviews performed without a record, revocations requested but never confirmed complete, reviewers approving their own access, or partial coverage. Auditors want to see who reviewed what, when, the decision, and proof that changes actually happened.