User access review software: a user access review tool for SOC 2, ISO 27001, PCI DSS and SOX access reviews

A user access review is a periodic check that every account with access to a system still needs it, and that the level of access matches what the person does now. You export the current users and their entitlements, have someone who knows the role decide keep or revoke on each line, act on the revocations, and keep the dated record. It is also called a user access certification or an entitlement review.

Quarterly for standard accounts and monthly for privileged or administrative accounts is the convention most auditors expect, but only PCI DSS names an actual number: at least once every six months under requirement 7.2.4. SOC 2, ISO 27001 and HIPAA leave the interval to your own risk assessment and then test whether you meet the interval you set. Choose one you can sustain and document why.

Detective. The review finds inappropriate access that already exists, after the fact, which is why frameworks pair it with preventive controls rather than accepting it alone. The preventive counterparts are the approval step at provisioning and the termination procedure that removes access on exit. An auditor expects both, because a detective control catching the same problem every quarter signals the preventive one is broken.

The manager or system owner who knows what the person does now, not the IT team that granted the access. IT knows what access exists; only the business owner knows whether it is still warranted. In practice the security or compliance team runs the process, sets the deadline and collects the evidence, while the actual keep or revoke decisions come from the people accountable for each system or team.

The system in scope, the complete list of accounts and their entitlements, a keep or revoke decision on every line, the name of the reviewer, the date the decision was made, and confirmation that each revocation actually happened. Blank lines are the most common defect, because an auditor reads an undecided line as an unfinished review rather than an implicit approval.

Decide which systems are in scope and record why anything is excluded. Export current users and entitlements from each one, including local and service accounts that bypass single sign on. Split the list by manager or system owner and ask for an explicit keep or revoke on each line with a deadline. Raise tickets for the revocations, confirm they closed, then file the export, the decisions and the closure proof together.

At least once every six months. Requirement 7.2.4 of PCI DSS 4.0.1 covers all user accounts and related access privileges, including third party and vendor accounts, and requires that inappropriate access is addressed and that management confirms the access level is appropriate. It was a future dated requirement and became mandatory on March 31, 2025. Application and system accounts can follow a frequency set by a targeted risk analysis under 7.2.5.1 instead.

Both, and the same review satisfies each. SOC 2 tests it under CC6.2 and CC6.3, which cover authorization, periodic review of access appropriateness, and removal. ISO 27001:2022 covers it under Annex A 5.18, access rights. Because the evidence an auditor wants is nearly identical, running one review and cross mapping it to both is the normal approach rather than running two.

The original export showing who had access at the time, a decision recorded against each account, the identity of the reviewer, the date, and proof that revoked access was actually removed. A screenshot of a current user list does not work, because it shows today rather than the review period. The point of the artifact is to be dated and unchanged since.

In IT general controls, usually in a SOX context, the user access review is the periodic control proving that access to financially relevant systems is appropriate and restricted. It sits alongside access provisioning, access removal and privileged access controls. External auditors typically sample across the year, so quarterly is close to universal for in scope financial systems and a single missed quarter is treated as a deficiency.

A spreadsheet genuinely works up to a point: a handful of systems, one reviewer, and someone disciplined enough to date and archive each cycle. It stops working when reviewers stop replying, when nobody can prove the revocations closed, or when the file is overwritten and last quarter's version is gone. Those three failures, not the size of the list, are what push teams onto a tool.

Identity governance connects to your applications and can execute the change, revoking entitlements and deprovisioning accounts. Compliance oriented access review tooling holds the review as an obligation, captures the decisions and keeps the evidence, without touching your identity plane. They overlap in the middle and solve different problems at the edges, so the deciding question is whether your bottleneck is doing the revocation or proving the review.

Very few vendors say. As of September 2026, Microsoft publishes Entra ID Governance at $7.00 per user per month paid yearly on top of a required Entra ID P1 or P2 licence at $7.00 or $10.00, and AccessOwl publishes $4.50 and $6.00 per user per month with a $250 monthly minimum. Okta, Lumos, C1, Vanta, Drata, Secureframe and Sprinto all publish no figure. Complies publishes $79, $199 and $499 a month, flat rather than per user.

No, and it is worth being blunt about it. Complies reads access and configuration from Okta, Google Workspace, GitHub and AWS to help assemble the list, then holds the review, the decisions and the evidence. It does not push changes back, revoke entitlements, deprovision accounts or run joiner mover leaver workflows. If automated revocation is the requirement, an identity governance platform is the right purchase.