User Access Review: How to Run One That Survives an Audit

Short answer: A user access review is a periodic check, usually by managers or resource owners, that every account and permission still matches a current job need, followed by removal of anything that does not. An auditor accepts one when the scope is complete, the reviewer is accountable, every revocation is actually applied and the evidence shows who decided what and when.

Who this guide is for

This guide is for the admin or security engineer who has been handed the access review control: a 200-person SaaS company preparing for its first SOC 2 audit, a retailer in PCI DSS scope that has to show six-month reviews, or an IT team that runs reviews in spreadsheets and is weighing whether user access review software is worth buying.

It covers what to review, what the major frameworks actually say, how to run a campaign, and what to test before buying a tool. For the wider identity platform decision, see the identity and access management category hub.

What a user access review covers

A user access review, also called an access certification or user entitlement review, covers more than the list of active users. The scope that holds up in an audit includes every identity type and every place a permission lives.

Microsoft's documentation lists the same pressure points as reasons to run reviews: too many users in privileged roles, guests who were never removed, and policy exception lists that need proof of regular review (Microsoft Learn).

What compliance frameworks require for user access reviews

Most frameworks require periodic review but do not set a number, so the interval you pick and document becomes the control. The PCI DSS rows follow the requirement text as Microsoft reproduces it; the ISO 27001 and SOC 2 rows come from a compliance vendor's summary, so treat them as secondary and confirm against the official standard your auditor uses.

Watch out: PCI DSS 7.2.4 names third-party and vendor accounts explicitly, so a review that only covers employees from the HR feed fails the requirement as written.

Secureframe recommends at least quarterly reviews for privileged administrators and at least annual reviews for general users (Secureframe). That is a common starting point, not a framework mandate.

How to run a user access review, step by step

A repeatable user access review has eight steps. Each step produces an artifact you keep as audit evidence.

1. Set the policy. Write down scope, interval per risk tier, reviewer for each resource and the deadline for remediation. Output: an approved access review policy. Owner: security or GRC lead.
2. Build the inventory. List every in-scope system and where its permissions live (directory groups, app roles, local accounts). Output: system inventory with a named owner per system. Owner: IT.
3. Take the snapshot. Export accounts and entitlements at a fixed date. Microsoft Entra, for example, captures a snapshot at the start of each review instance, and changes made during the review appear in the next cycle (Microsoft Learn). Output: dated entitlement extract.
4. Enrich the data. Add manager, department, employment status and last sign-in date so reviewers can decide without chasing context. Output: review packet per reviewer.
5. Assign reviewers. Managers review their people; resource owners review who can reach their system; a second reviewer covers privileged roles. Name a fallback for users with no manager. Output: reviewer assignment list.
6. Collect decisions with justification. Require a reason for every approval of privileged access and every denial. Output: decision log with reviewer, timestamp and reason.
7. Remediate and verify. Remove denied access, then re-extract and confirm it is gone. Output: before-and-after evidence, ticket numbers.
8. Close and report. Record completion rate, number of revocations and exceptions, and sign-off by management (PCI DSS 7.2.4 asks for management confirmation). Output: signed campaign report.

Admin tip: Step 7 is where spreadsheet reviews usually fail an audit. A decision to revoke that was never applied to the system is a finding, so keep the re-extract as proof.

Access review tool settings that change the outcome

Access review software automates steps 3 to 8, but a few settings decide whether the tool helps or causes an outage. Microsoft Entra ID Governance is used below because its behavior is publicly documented; ask any other vendor the same questions.

• Non-response default. Entra offers No change, Remove access, Approve access or Take recommendations for users nobody reviewed. With Remove access or Take recommendations plus auto-apply, Microsoft warns all access to the resource could be revoked if reviewers fail to respond (Microsoft Learn).
• Auto-apply. When auto-apply is off, results must be applied manually after the review ends, which reopens the step 7 gap.
• Decision helpers. Entra's "No sign-in within 30 days" helper recommends denial for users without a sign-in in the prior 30 days; for application reviews it uses sign-ins to that application.
• Nested groups. Entra flattens nested groups in a group review, and a denied user is removed from direct membership only, not from the nested group. Access through the nested group survives.
• Reviewer changes mid-review. Only group owners at the time the review starts are reviewers; ownership changes apply from the next recurrence.
• Multi-stage reviews. Entra supports up to three sequential stages, useful for manager review followed by resource owner review.
• Justification and reminders. Justification can be made mandatory; reminders go out halfway through the review period.

Pricing note: Microsoft lists Microsoft Entra ID Governance at $7.00 per user per month paid yearly, as an add-on for Entra ID P1 or P2 customers, and Microsoft Entra Suite, which includes ID Governance, at $12.00 (Microsoft Entra pricing, checked September 22, 2026). Access reviews require ID Governance or Entra Suite licenses; some capabilities may work with Entra ID P2 (Microsoft Learn).

Run a pilot that proves the access review software works

A user access review software pilot should prove remediation and evidence, not the reviewer screen. Run these tests on one real, low-risk application before buying.

Questions to ask user access review software vendors

Coverage and data

• Which applications have native connectors, and how are apps without connectors handled (file upload, API, manual)?
• Are service accounts, guests and privileged roles in scope, or only directory users?
• How fresh is the entitlement snapshot, and can it be re-run during a campaign?

Reviewer experience

• Can reviewers see last sign-in, manager and peer comparison next to each decision?
• Can justification be required only for high-risk items?
• What happens when a reviewer leaves mid-campaign?

Remediation and evidence

• Is revocation automatic, a ticket, or a task for IT, and how is completion verified?
• What does the audit export contain, and in what format?
• How long is campaign history retained?

Pricing and contract

• Is pricing per user, per identity, per connector or per application?
• Is access review a separate module or tier from provisioning and access requests?
• Are contractors and guests counted as billable identities?

Mistakes to avoid in a user access review

• Reviewing only HR-fed employees. PCI DSS 7.2.4 names third-party and vendor accounts explicitly (Microsoft Learn).
• Setting mass removal as the non-response default. Microsoft documents that this can revoke all access to a resource (Microsoft Learn).
• Trusting nested groups. In Entra group reviews, denial removes direct membership only, so access through a nested group remains.
• Skipping verification. A recorded revoke decision without proof it was applied is weak evidence.
• No written interval. Under NIST AC-2(j) and ISO 27001 the interval is yours to define, so an undocumented schedule leaves nothing to test against.
• Giving reviewers raw entitlement names. Reviewers approve what they cannot interpret; add descriptions and last-use data.

Shortlist by scenario

To compare identity platforms against your requirements, use the shortlist builder.

Bottom line

Write the interval and scope down first, include vendors, guests and service accounts, and treat verified remediation as the step that makes a user access review pass. If you evaluate software, pilot the non-response default and the evidence export before anything else.

The answer changes if most of your applications sit outside SSO: then connector coverage, not the reviewer screen, decides the tool. Start from the identity and access management category hub to see the platforms in this market.