A user access review is a scheduled check that every account still needs the access it has, signed off by someone who knows the answer. It is one of the most commonly tested controls in any audit, and one of the most commonly failed, usually not because access is wrong but because the review cannot be proven. This guide covers what each framework requires, how often to review, a process that holds up, a checklist, and the evidence auditors ask to see.
What a user access review is, and why it fails audits
Access tends to grow. People change roles and keep their old permissions, contractors finish and their accounts stay enabled, and service accounts collect rights that nobody remembers granting. A user access review, sometimes called an access recertification, is the control that pulls that drift back. A reviewer looks at who has access to a system, confirms each entitlement is still needed, and removes what is not.
When the control fails an audit, it is rarely because no review happened. It is because the review cannot be shown to have happened properly. The usual findings are:
- Rubber stamping. Every line approved in minutes, with no sign that anyone looked.
- The wrong reviewer. IT approves access it cannot judge, instead of the manager or data owner who can.
- An incomplete population. The list left out service accounts, local administrators, or a system that was in scope.
- No follow-through. Access was marked for removal, and the removal was never made or never confirmed.
- Missing evidence. The review happened in email and nobody kept the record.
What each framework requires
Most frameworks ask for the same thing in different words: review access on a schedule, remove what is no longer needed, and keep a record. Where they differ is how often, and how specific they are.
| Framework | What it asks for | How often |
|---|---|---|
| PCI DSS 4.0 | 7.2.4 requires review of all user accounts and related access privileges, including third-party and vendor accounts. 7.2.5.1 covers application and system accounts. | At least once every six months for user accounts. System accounts at a frequency set by your targeted risk analysis. |
| HIPAA Security Rule | 45 CFR 164.308(a)(4)(ii)(C) calls for policies to establish, document, review and modify a user’s right of access. | Not stated. Set a schedule in policy and follow it. |
| GLBA Safeguards Rule | 16 CFR 314.4(c)(1) requires implementing and periodically reviewing access controls, limiting users to the customer information they need. | Periodically. Define it in your information security program. |
| NYDFS Part 500 | 500.7 requires reviewing all user access privileges and removing or disabling accounts and access that are no longer necessary. | At least annually. |
| NIST SP 800-171 Rev. 3 | 03.01.05 Least Privilege requires reviewing the privileges assigned to roles or classes of users, and reassigning or removing them as necessary. 03.01.01 Account Management adds monitoring the use of system accounts. | At a frequency your organization defines. |
| ISO/IEC 27001:2022 | Annex A 5.18 Access rights covers provisioning, reviewing, modifying and removing access. 8.2 covers privileged access rights. | At regular intervals you define, and after changes such as a role move. |
| SOX | The Act does not mention access reviews. They come from the IT general controls auditors test as part of internal control over financial reporting under Section 404. | Set by your control design. Quarterly is common for financially significant systems. |
SOC 2 works the same way. The trust services criteria for logical access, chiefly CC6.2 and CC6.3, expect access to be authorized, modified and removed as roles change, and auditors usually test that through a periodic review.
How often to review access
Start from the strictest requirement that applies to the system, then adjust for risk. A sensible pattern for many organizations:
- Privileged and administrator accounts: quarterly. They carry the most risk and change often. Our guide to the privileged access management audit covers what auditors expect for these accounts in more detail.
- Systems holding regulated data: at least every six months, which also satisfies PCI DSS 7.2.4.
- Everything else in scope: at least annually, which matches the NYDFS minimum.
- Event driven: whenever someone changes role or leaves, rather than waiting for the next cycle.
Whatever you choose, write it down. Where a framework leaves the frequency to you, the auditor will test you against your own policy, so a schedule you cannot keep is worse than a modest one you can.
A user access review process that holds up
- Define the scope. List the systems in scope and who owns each one. Include directories, file shares, applications and cloud tenants, not only the obvious ones.
- Pull the access, from the system itself. Export current accounts, group memberships and permissions directly, on the day of the review. A spreadsheet kept by hand is not evidence of what the system actually grants.
- Add context. Show each reviewer the person’s role, manager, last logon and when the access was granted. A reviewer who cannot see that an account has not logged on in 120 days will approve it.
- Send it to the right reviewer. The manager confirms a person still needs the role. The data or system owner confirms the role should carry that access. Nobody reviews their own access.
- Record a decision for every line. Keep or remove, with the reviewer’s name and date, and a reason for any exception.
- Remove what was rejected, and confirm it. Raise a change for each removal, then check the system again to prove the access is gone.
- Keep the package. Store the extract, the decisions, the removal tickets and the confirmation together, by review cycle.
The accounts reviews usually miss
An auditor testing completeness will compare your review population with the system. These are the accounts most often missing from it:
- Nested groups. A person can hold administrator rights through a group inside a group. Review effective membership, not just direct members.
- Service accounts. They need a named owner who can vouch for them, and they often hold far more rights than they use.
- Dormant and orphaned accounts. Accounts for people who have left, or that have not logged on in months. PCI DSS 8.2.6 requires inactive user accounts to be removed or disabled within 90 days.
- Local administrators. Rights granted on individual servers and workstations sit outside the directory review.
- File share permissions. Folders granted to individuals or to broad groups such as Everyone. Our guide to file server auditing covers how to see who is using that access.
- Cloud and hybrid identities. Roles in Microsoft Entra ID and other tenants that never appear in on-premises Active Directory.
What evidence auditors ask for
Expect the auditor to pick a sample of review cycles and systems and ask for the following:
- The access listing, showing where it came from and when it was produced.
- The reviewer’s decision for each line, with name and date.
- Tickets for every removal, and proof the removal took effect.
- Evidence that reviews happened on the schedule your policy states.
- A record of changes between reviews. Group membership changes appear in the Windows Security log as events 4728, 4732 and 4756, and account creation, change and deletion as 4720, 4738 and 4726. Our Active Directory auditing guide covers how to collect and keep them.
The last point matters more than it looks. A review is a snapshot. The change record shows what happened between snapshots, such as someone added to Domain Admins the day after the review and removed the day before the next one.
A user access review checklist
- Every in-scope system has a named owner and a documented review frequency.
- Access listings are extracted from the system on the day of the review.
- Effective group membership is shown, including nested groups.
- Reviewers see role, manager, last logon and grant date for every line.
- Managers confirm the need and data owners confirm the access.
- No one reviews their own access.
- Service, dormant, local administrator and cloud accounts are in the population.
- Every rejected entitlement has a removal ticket and a confirmation.
- Group and account changes between reviews are logged and retained.
- The full evidence package is stored for each cycle.
Common questions about user access reviews
What is a user access review?
A user access review is a periodic check that each account still needs the access it holds. A manager or system owner confirms or removes each entitlement, the removals are carried out, and the decisions are kept as evidence for auditors.
How often should user access reviews be done?
It depends on the framework and the risk. PCI DSS requires user account reviews at least every six months and NYDFS at least annually. Many organizations review privileged accounts quarterly. Where a framework leaves it to you, set a frequency in policy and keep to it.
Who should perform a user access review?
The person who can judge whether the access is still needed, usually the user’s manager together with the owner of the system or data. IT prepares the listings and carries out removals, but should not approve access on a business owner’s behalf. Nobody should review their own access.
What evidence do auditors need from an access review?
Auditors usually ask for the system-generated access listing, each reviewer’s dated decision, tickets showing removals were made, proof the access is gone, and evidence that reviews followed the schedule in your policy. A record of access changes between reviews strengthens the evidence.
Make access reviews easier to prove
LT AuditorMP® tracks user and group changes, uncovers excessive permissions, and monitors file and folder access and permission changes across Windows, Linux and macOS systems, Active Directory and Microsoft Entra ID. It keeps that history in one place and exports reporting mapped to frameworks including HIPAA, PCI DSS, ISO 27001 and NIST, so the record between reviews is already there when an auditor asks.
Request a demo to see who has access to what in your own environment.