How to Run a User Access Review: Step-by-Step Guide + Free Template
A practical, step-by-step guide to running a User Access Review that satisfies SOC 2 CC6.2/CC6.3 and ISO 27001 A.5.18 - including a free template and tips to avoid rubber-stamping.
7 min read · Last updated August 2026
Your last access review probably approved 95% of everything it touched. That's not governance - that's a checkbox with extra steps.
Studies consistently show that reviewers approve over 95% of access during certification campaigns, with the average reviewer spending fewer than 10 seconds per decision. The result is what the industry calls rubber-stamping: a compliance artifact that looks like evidence but does almost nothing to reduce actual access risk.
This guide gives you a concrete, repeatable process for running a User Access Review (UAR) that actually works - one that produces real decisions, provable remediation, and timestamped evidence your auditor will accept. It also includes a ready-to-use template you can copy today.
What Is a User Access Review (and Why Do Frameworks Require It)?
A User Access Review - also called access recertification or access certification - is a structured process for confirming that every user's entitlements across every system are still appropriate for their current role. It's not a one-time project. It's a recurring control.
Two frameworks make it non-negotiable for most fast-growing companies:
SOC 2 CC6.2 / CC6.3 - CC6 (Logical and Physical Access Controls) is one of the two most heavily tested areas in SOC 2 audits and the most common source of audit exceptions in qualified reports. CC6.2 covers how access is granted; CC6.3 covers how it's modified or removed. Undocumented access reviews are the single most common evidence gap auditors find under these criteria.
ISO 27001 A.5.18 - ISO 27001 Control 5.18 requires organizations to implement a rigorous lifecycle process for the provisioning, regular review, modification, and removal of access rights, ensuring permissions remain aligned with current role responsibilities. The 2022 revision added explicit requirements around temporary access revocation and documentation of every change.
For SOC 2 and ISO 27001, auditors expect at minimum quarterly reviews for privileged access and semi-annual reviews for standard access. Annual reviews are increasingly considered insufficient. And the bar isn't just "did you review?" - it's "can you prove what changed as a result?"
The auditor's actual question: "Show me your last access review. Who reviewed it, when was it completed, and what access was removed as a result?" If you can't answer all three parts with timestamped evidence, you have a finding.
Who Should Review What?
Getting reviewer assignment wrong is one of the fastest ways to produce rubber-stamped results. Two roles matter:
Managers review whether a person still needs access at all - based on their current role, team, and employment status. They're the right reviewer for joiner/mover/leaver decisions.
App or data owners review whether a specific entitlement level is still appropriate - admin vs. read-only, which Slack channels, which GitHub repos. They understand what a permission actually grants. Traditional models rarely involve them, which is a problem: the person who understands the data best is rarely the one certifying access to it.
For non-human identities - service accounts, API keys, automation bots - assign a named human owner. In cloud environments, machine identities outnumber human identities by 82 to 1. Leaving them out of your UAR scope is a coverage gap that auditors and attackers will both find.
The 6-Step UAR Process
Decide which systems are in scope (start with systems that touch sensitive data, production environments, and admin access), who is in scope (employees, contractors, service accounts, AI agents), and how often you'll review. A practical starting cadence: quarterly for privileged and admin access, semi-annually for standard user access. Document this in a policy — an undocumented cadence doesn't satisfy auditors.
This is where most teams fail. They pull a user list from their IdP and call it done — but that only covers SCIM-connected apps. Your real stack includes Notion, Figma, Linear, GitHub, Jira, internal portals, and dozens of other tools that may have no SCIM connector at all. A complete inventory means every user, every app, every entitlement level — not just the apps your SSO happens to govern. If you can't pull it automatically, you need a platform that covers the full stack, not just the SCIM-friendly subset.
Map each app or entitlement group to a named reviewer — either the user's manager or the app/data owner, depending on what's being reviewed. Set a deadline. Send a single, actionable notification with exactly what they need to decide. Don't send a spreadsheet with 400 rows and no context — that's a rubber-stamp waiting to happen.
Context is what separates a real review from a checkbox exercise. Each review item should show: last login date (is this account even active?), peer comparison (does anyone else in this role have this permission?), business justification (why was this access granted originally?), and risk signals (admin rights, external users, dormant accounts). Risk-based context gives reviewers a signal to act on instead of a raw entitlement list — and it's what drives actual revocations.
A decision to revoke is worthless if the access isn't actually removed. Remediation must be tracked: who revoked it, in which system, at what timestamp. If revocation requires a manual ticket to another team, that ticket must be closed and linked to the review record. The control isn't complete until the access is gone — not just marked for removal.
Every review cycle must produce an immutable, timestamped artifact: who reviewed, what decision was made, when, and what changed. A spreadsheet edited the week before your audit covers none of the review period. Evidence must be generated at the time of the review, not reconstructed afterward. This is the artifact your auditor will ask for under SOC 2 CC6.3 and ISO 27001 A.5.18.
The Rubber-Stamping Trap
Over 75% of organizations admit that rubber-stamping is a significant problem in their access review processes. It happens for a predictable reason: reviewers face too many items, too little context, and too much fear that removing access will break someone's work. When every account looks the same, approving everything is the path of least resistance.
The warning sign is a review where nobody loses access. If your last UAR resulted in zero revocations across 200 users and 30 apps, that's not a clean environment - that's a broken process.
The fix isn't more reminders or stricter deadlines. It's better evidence, clearer prioritization, and review items that are actually defensible. Specifically:
- Surface anomalies first. Flag accounts with no login in 90+ days, external users with internal-level permissions, and anyone with admin rights that no peer in their role holds.
- Keep campaigns small. Instead of one massive quarterly review, run targeted micro-certifications: a review of all admin accounts this week, all contractor access next week. Smaller scope means more attention per item.
- Measure decision quality. Track revocation rate per reviewer. A reviewer with a 0% revocation rate across multiple cycles is a signal worth investigating.
Risk-Based Reviews: Not Everything Needs the Same Cadence
Not all access carries the same risk. A risk-based approach applies more scrutiny where it matters most:
| Access Type | Suggested Cadence | Reviewer |
|---|---|---|
| Privileged / admin accounts | Quarterly | App owner + security team |
| Production system access | Quarterly | Data owner |
| Standard SaaS access | Semi-annually | Manager |
| Contractor / third-party access | On contract renewal + quarterly | Manager |
| Service accounts / API keys | Quarterly | Named technical owner |
| Dormant accounts (90+ days no login) | Triggered, not scheduled | Manager |
Event-driven triggers matter too. A role change, a team transfer, or a contractor engagement ending should kick off an immediate targeted review - not wait for the next scheduled campaign.
The UAR Template
Copy this into a spreadsheet or import it into your IGA platform. Every column has a purpose.
Template column guide:
- User - Full name and employee ID or email. Include service accounts and bots by name.
- App - The specific system (GitHub, Notion, Jira, AWS, etc.).
- Entitlement - The specific permission or role (e.g.,
repo:admin,billing-read,#engineeringchannel). - Access Level - Admin / Write / Read / No Access.
- Last Login - Pull from the app's audit log. A blank here is a red flag.
- Business Justification - Why was this access granted? If nobody knows, that's a finding.
- Decision - Keep / Revoke / Escalate. Every row needs a decision.
- Reviewer - Named individual, not a team or role.
- Review Date - The date the decision was made, not the date the campaign started.
Spreadsheet vs. automated platform: A spreadsheet works for your first review cycle with under 50 users. Beyond that, it breaks down fast — no immutable timestamps, no automatic remediation, no coverage for apps without SCIM, and no way to prove the review happened on the date it claims. Auditors increasingly flag spreadsheet-based reviews as insufficient evidence for SOC 2 Type 2 and ISO 27001 surveillance audits.
The Shift to Continuous Certification
Periodic campaigns - quarterly or semi-annual - are the compliance floor, not the ceiling. The direction the industry is moving is clear: modern IAM solutions are shifting toward continuous access certification with automated workflows that enforce governance policies in real-time, replacing resource-intensive periodic snapshots.
Continuous certification doesn't mean reviewing everything every day. It means:
- Event-driven triggers fire a targeted review when a user changes roles, a contractor's engagement ends, or an account goes dormant.
- Micro-certifications replace bulk campaigns with smaller, focused reviews that get more attention per item.
- Automated remediation closes the loop - a revocation decision immediately kicks off deprovisioning across all connected systems, not just the SCIM-enabled ones.
- Persistent evidence is generated at the moment of each decision, building a continuous audit trail rather than a point-in-time snapshot.
This matters especially for non-human identities. Unit 42 investigators found that identity misconfigurations played a material role in almost 90% of investigations in 2025. Service accounts and API keys accumulate privileges faster than periodic reviews can catch them. Continuous governance is the only model that keeps pace.
If you're still running spreadsheet-based quarterly campaigns, the From Spreadsheets to Continuous Certification: A 90-Day Plan lays out exactly how to make the transition without disrupting your existing review cycles.
For the full list of evidence artifacts your auditor will ask for - not just UAR records, but provisioning logs, offboarding proof, and privileged access documentation - see the Identity Evidence Playbook.
What Good Looks Like
A UAR that satisfies auditors and actually reduces risk has five properties:
- Full-stack coverage - every app, not just SCIM-connected ones.
- Context-rich reviews - last login, peer comparison, and business justification surfaced for every item.
- Real revocations - a non-zero revocation rate is evidence the control is working.
- Closed-loop remediation - access is actually removed and the removal is logged.
- Timestamped, immutable evidence - generated at review time, not reconstructed before the audit.
If your current process can't produce all five, you're not running a User Access Review - you're running a compliance theater exercise that leaves real access risk on the table.
Related reading
Zero Standing Privilege: The Case for Just-in-Time Access Across Humans and Machines
Standing privilege is a permanent attack surface. Learn how Just-in-Time access and Zero Standing Privilege eliminate it for privileged humans, contractors, and AI agents alike.
The Complete Guide to Identity Lifecycle Management (ILM)
Everything IT and security teams need to know about ILM: joiner, mover, leaver phases, non-human identities, key metrics, and how to automate the full app stack.
The Complete IT Employee Offboarding Checklist: Every Step, Every App, No Orphaned Accounts
A full, grouped IT offboarding checklist covering SSO, non-SCIM apps, OAuth tokens, shared credentials, MDM, license reclamation, and audit evidence - with a copy-ready template.