User access reviews: the step-by-step process auditors accept

Access reviews fail audit for one of two reasons: nobody can prove who decided, or nobody can prove the removals happened. This is the operational cycle that closes both gaps — scope, export, review, remediate, evidence.

Michael McCarroll 12 min read Updated August 2026

Step 1 — Scope and schedule

Step 1

Define the system inventory in scope

List every system with a data classification and an owner. Include the identity provider, cloud consoles, source control, CI/CD, endpoint management, HR, finance and any customer-data application. Write the inclusion rule down so the scope is repeatable.
Step 2

Split privileged from standard

Privileged and administrative access on a quarterly cycle; standard user access annually or semi-annually. Mixing them means either over-reviewing low-risk accounts or under-reviewing the ones that matter.

Step 2 — Export, review, remediate

Step 3

Pull a dated entitlement export

Export users, roles, groups and last-login date per system on a fixed date. Note the export date and who produced it — this is the anchor for the entire evidence chain.
Step 4

Send to the accountable reviewer

The system or line owner decides per account: retain, downgrade, or remove. Require a reason for every retained privileged account. Set a hard deadline — 10 working days works.
Step 5

Action changes through tickets

Every removal or downgrade goes through your normal change or service ticket so it has an independent completion record. Chasing removals by email leaves no timestamp.
Step 6

Verify and sign off

Re-export after remediation and confirm the changes landed. Sign off with the reviewer name, date and the exception list. Any exception becomes a risk entry with an owner and a review date.

Access review checklist

  • In-scope system list approved, with owner and data classification per system.
  • Review cadence documented and differentiated for privileged access.
  • Dated entitlement export captured per system, including roles and last login.
  • Orphaned accounts (no matching active employee) identified against the HR list.
  • Service and shared accounts reviewed separately, each with a named human owner.
  • Reviewer decision recorded per account — retain, downgrade or remove.
  • Justification captured for every retained privileged account.
  • Removals raised as tickets, with completion dates recorded.
  • Post-remediation export confirms the changes took effect.
  • Exceptions logged as risks with owner, rationale and expiry date.
  • Sign-off stored with the cycle date and pushed to the evidence library.
  • Leaver sample tested: were their accounts disabled within the SLA?

What good remediation looks like

A clean cycle almost always finds something: a contractor who left, an admin group that grew, an integration account with far more scope than the integration needs. Findings are not a failure — a review that finds nothing, repeatedly, tends to suggest the review is not real.

Where the same issue keeps recurring, fix the joiner-mover-leaver process rather than the symptom. Recurring orphaned accounts mean HR offboarding is not triggering deprovisioning, and that root cause is what an auditor will pursue.

Frequently asked questions

How often should user access reviews be run?
Quarterly for privileged and administrative accounts, and at least annually for standard access, is the pattern most ISO 27001 and SOC 2 auditors expect. Increase frequency for systems holding regulated or customer data, and always trigger an out-of-cycle review after a restructure or an acquisition.
Which systems must be in scope?
Start with anything that stores or processes customer, financial or personal data, plus the identity provider itself and any system granting administrative reach — cloud consoles, source control, CI/CD, endpoint management, HR and finance. Document the inclusion rule so the scope is defensible rather than arbitrary.
Who should review the access list?
The system owner or the line manager, not IT. IT can produce the entitlement export and action removals, but the person who understands whether the access is still justified must make the decision and sign the record.
What evidence does an auditor want?
The entitlement export with a date, the reviewer's decision per account, the change tickets showing removals or downgrades, the date each change completed, and sign-off. An untimestamped spreadsheet with 'reviewed - OK' at the bottom is the most commonly rejected evidence in this area.
How do we handle service and shared accounts?
Review them separately with a named human owner for each. Confirm the account is still required, its credentials are vaulted and rotated, and its permissions are the minimum needed. Shared accounts without an owner should be raised as a risk, not silently approved.
How does this map to ISO 27001 and SOC 2?
ISO 27001:2022 Annex A 5.15, 5.16, 5.18 and 8.2 cover access control, identity lifecycle, access rights and privileged access. For SOC 2 it evidences the logical access criteria under CC6. One review cycle, evidenced properly, satisfies both.

Run access reviews on a schedule with the evidence attached

A system register with owners, scheduled review campaigns, per-account decisions, exception tracking and an evidence trail your auditor can follow end to end.

ISO-STANDARD.app ships a ready-to-adopt ISO 27001 workspace with the risk register, controls catalogue, policies and audit-ready exports already wired together — no spreadsheet sprawl, no consultant lock-in.

Free downloads for this topic

Prefer a conversation? Email hello@iso-standard.app — a real human responds within one business day.

Related guides
Trust & security
ISO 27001 aligned
Controls mapped to Annex A
Encryption in transit & at rest
TLS 1.3 · AES-256
MFA enforced
TOTP required for all admins
GDPR & UK GDPR
DPA on request · EU/UK data
SOC 2 ready posture
Audit-grade logging
RLS-isolated tenants
Row-level data separation
← All guidesHome →