User Access Review Process: Steps and Evidence

Last updated August 2026. A user access review runs in six steps: define the scope, build a complete population of accounts and entitlements, assign each system to an owner who can judge the access, collect keep, modify and remove decisions with dates, carry out every removal and record when it closed, then retain the whole set as evidence. The step teams skip is the last half of step five, and it is the one auditors sample.

This guide walks the process end to end, shows the evidence an auditor actually asks for, covers how often to run it under each framework, and lists the five exceptions that get written up most often. It is aimed at whoever owns the review: compliance leads, IT managers and internal audit at US companies carrying SOC 2, SOX, PCI DSS or ISO 27001.

What is a user access review?

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 their current job requires. An owner looks at each account, decides to keep, modify or remove the access, and the decisions plus the resulting revocations are kept as evidence. You will also see it called a user entitlement review, an access certification, or just a UAR.

It is a detective control, not a preventive one. The access already exists by the time anyone looks at it. Provisioning approval and automated deprovisioning are the preventive controls, and the review is the net underneath them. That relationship matters more than it sounds: if your reviews keep catching accounts belonging to people who left months ago, the finding is not really about the review. It is evidence that offboarding is broken, and a good auditor will say so.

The user access review process, step by step

Step 1: define the scope

Decide which systems are in scope and write down why. For SOC 2 that is the systems supporting the services in your description. For SOX it is the applications and the infrastructure underneath them that feed financial reporting. For PCI DSS it is everything in and connected to the cardholder data environment. Scope creep in both directions is common: teams review the identity provider and nothing else, or they try to review all 200 SaaS apps and finish none.

Be explicit about what you excluded and why. An auditor is generally comfortable with a narrow, reasoned scope and very uncomfortable with a scope that has no documented rationale.

Step 2: build a complete population

This is the step that decides whether the review is worth anything. The population is every account and its entitlements in each in-scope system, pulled as close to the source as possible, with a record of how and when it was extracted.

Completeness is what gets tested. An auditor will ask how you know the list is complete, and "I exported it from the admin console" is a reasonable answer only if you can show the export, the date and who ran it. Screenshots of a filtered view are not a population. If you already land identity and entitlement data in a warehouse, the reconciliation between systems gets much easier, and you can ask the joins in plain English rather than hand-writing them each quarter.

Two things routinely go missing here. Application-level roles inside an ERP or CRM, which are invisible from your SSO directory, so someone correctly provisioned into the app can hold a role inside it nobody approved. And non-human accounts: service accounts, API keys, integration users. Those are usually the most privileged accounts you own and the least reviewed.

Step 3: assign an owner to every system

Route each account to the person who can actually judge the access. That is usually the system or data owner, not IT and not the security team. IT knows the access exists; only the owner knows whether this analyst still needs write access to the billing module.

ISO 27001 is explicit that asset owners are involved, and the practical reason is the same everywhere: a reviewer who cannot tell the difference between appropriate and inappropriate access will approve everything. Rubber-stamped reviews are a common exception, and the tell is a campaign where 100 percent of accounts were kept and every decision was made within the same few minutes.

Step 4: collect decisions, dated

Each account gets a keep, modify or remove decision, attributed to the reviewer and timestamped. Reviewers need enough context to decide: the person's role, when they last logged in, what the entitlement actually permits. Handing someone a list of usernames and group names and asking for a signature produces a signature, not a review.

Set a deadline and chase it. Incomplete campaigns that quietly expire are the second most common exception in this area.

Step 5: carry out the removals and record closure

This is where reviews fail. The decision is not the control. The revocation is. Every remove and modify decision needs to be executed and evidenced with the date it was completed, and it should stay open until then.

Auditors sample this deliberately. They take a handful of remove decisions from your review and ask you to prove the access is gone. If you can produce the signed review but not the revocation records, the control is tested as ineffective even though the review itself was thorough. Set a service level for closure, seven or fourteen days is typical, and track the exceptions.

Step 6: retain the evidence as one package

Keep the population extract, the reviewer assignments, the decisions, the revocation records and the sign-off together for the review period, dated. Reviews assembled from three different tools and a shared drive nine months later are how a control that ran perfectly gets written up anyway.

What evidence do auditors want from a user access review?

Four things, and the fourth is where most reviews come apart.

How often should user access reviews be performed?

Quarterly is the working standard for in-scope systems and it is what most auditors expect to see. Only one major framework names a frequency in the standard itself: PCI DSS v4.0 requirement 7.2.4 sets at least once every six months for user accounts, including third-party and vendor accounts, with management confirming the access remains appropriate. Application and system accounts are handled separately under 7.2.5, where the frequency comes from a targeted risk analysis.

SOC 2, ISO 27001 and the HIPAA Security Rule do not state an interval. That sounds like freedom and is not: you set the cadence in your own policy, and you are then tested against what you wrote. A policy promising monthly reviews that produced three campaigns last year is a worse position than an honest quarterly policy that ran four. The user access review software comparison table sets out where the requirement sits in each framework side by side.

Privileged accounts usually get a shorter cycle. Administrators, break-glass accounts and service accounts with elevated rights are reviewed monthly or quarterly in most policies, because one stale privileged account is worth more to an attacker than a hundred stale read-only ones.

The five exceptions auditors write up most

In rough order of how often they appear:

1. Removals never carried out. The review was completed and signed, and the access identified for removal is still live at testing. This is the single most common finding in the area.
2. Incomplete population. The extract missed application-level roles, service accounts or a system that was in scope but not on anyone's list.
3. Rubber-stamping. Everything approved, no modifications, decisions made faster than anyone could have read the list.
4. Self-review. Someone certified their own access, or a manager certified access to a system they do not own.
5. Missed cadence. Three reviews in a year against a quarterly policy, or a campaign that opened on time and never closed.

Four of the five are process failures rather than security failures, which is why teams that run this well treat the review as an operations problem with a deadline, not a compliance form.

What to automate, and what not to

The instinct is to automate the sign-off. That is the wrong target, because the sign-off is the one part that genuinely requires a human. Automate the parts that break silently instead.

Population building is first. If the account list assembles itself from live entitlement data, the completeness question mostly answers itself and nobody spends a week on exports. Routing and chasing is second: campaigns fail because reviewers ignore them, and something has to escalate. Revocation tracking is third and arguably most valuable, because it turns the decision into a tracked item that stays open until the access is actually gone.

Worth being clear on a distinction the market blurs. Identity governance platforms provision and enforce access; they can grant and revoke entitlements directly, and they are priced and deployed accordingly. Access review tooling collects entitlements, runs the campaign and produces the evidence, then hands the revocation to whoever owns the system. Teams that need an audit finding closed usually need the second and get sold the first.

Is a user access review a preventive or detective control?

Detective. The access already exists when the review runs, so the review finds problems rather than preventing them. The preventive controls in this family are provisioning approval, role-based access design and automated deprovisioning triggered by HR. Auditors look at the pair together, and a review that keeps surfacing the same category of problem is read as evidence that the preventive control is not working.

Are user access reviews done for ISO or SOC audits?

Both, and for several others. SOC 2 tests them under the CC6 logical access criteria, ISO 27001 under Annex A 5.18 access rights, PCI DSS under requirement 7.2.4, and SOX through the IT general controls the external auditor tests over financial systems. The underlying evidence is the same population, the same decisions and the same revocation records, which is why running the review once against a mapped control set costs far less than running it once per framework. The SOC 2 compliance software and ISO 27001 compliance pages cover how the rest of each control set maps.

What is a user access review in ITGC?

In IT general controls, the user access review is one of the access to programs and data controls the external auditor tests as part of a financial statement audit. Its failure has an unusual blast radius: if the auditor cannot rely on who had access to a financial system, they cannot rely on the automated controls or the reports coming out of it, so testing shifts to substantive procedures that cost considerably more. That knock-on effect is why access review exceptions get escalated faster than most control failures, and why finance leadership tends to hear about this one.

Where to start if you are running this in a spreadsheet

Pick the two or three systems that carry the most risk, usually the identity provider, the cloud account and the financial system, and run a genuine quarterly review over just those. Get the revocation tracking right on a small scope before widening it. A narrow review with complete evidence passes; a broad review with signatures and no revocation records does not.

Then widen by adding systems, not by adding reviewers. Every system you add needs an owner who can judge the access, and the constraint is almost always owners rather than tooling. Once the cadence holds, mapping the same evidence across the frameworks you report against is mostly a labeling exercise.