User Access Review: Process, Checklist, Frequency

A user access review is a periodic check that every person and account with access to a system still needs it, at the level they have it. You pull a current list of accounts and permissions from each in-scope system, send it to the manager or system owner who can actually judge it, record an explicit keep, reduce, or revoke decision for every line, act on the revocations, and keep the whole thing as evidence. SOC 2 and ISO 27001 both expect the control without naming a frequency. PCI DSS v4.0 is the one that puts a number on it: Requirement 7.2.4 says all user accounts and related access privileges, including third-party and vendor accounts, are reviewed at least once every six months.

Access reviews are the control auditors probe hardest, because they are the easiest to fake and the most revealing when you do not. A policy saying reviews happen quarterly is worth nothing. A signed export showing that on a specific date a named manager looked at 43 accounts, revoked 6, and that those 6 were gone from the system a week later is worth a great deal. The gap between those two artifacts is where most first audits lose time.

What is a user access review?

It is the recurring exercise of confirming that access rights still match job function. Somebody joins, gets access to what they need, then changes teams, picks up a project, covers for a colleague on leave, and quietly accumulates permissions nobody ever removes. Security people call the result privilege creep. The access review is the scheduled sweep that catches it, alongside accounts belonging to people who left, shared logins nobody will admit to, and service accounts created for a migration that finished two years ago.

The review is a detective control, not a preventive one. This distinction comes up in audits and it is worth getting right: preventive controls stop bad access from being granted (approval workflows, role-based provisioning, MFA), while the access review detects bad access that already exists. Auditors expect both. A team with excellent provisioning and no reviews cannot show that provisioning worked. A team with diligent reviews and no provisioning discipline is mopping the floor with the tap running.

Which frameworks require a user access review?

Effectively all of them, using different language. The table below maps the control to the requirement each framework raises it under, so you can run one review and satisfy every framework in scope at once.

The pattern is worth internalizing because it applies far beyond access reviews. Only PCI DSS hands you a number. Everywhere else you set the cadence, write it down, and then get judged against your own commitment. Promising monthly reviews and delivering two a year is a worse audit outcome than promising annual reviews and delivering them, which is why the honest cadence beats the impressive one. This is the same one-control-many-requirements logic that control mapping software exists to track, and access review is the textbook example: run it once, evidence it once, and it counts five times.

How often should you do user access reviews?

Quarterly for systems holding sensitive data or granting administrative power, annually for low-risk systems, and immediately on termination regardless of the calendar. That is the pattern most auditors see and accept, and it is defensible because it is risk-based rather than uniform.

Two refinements matter. First, privileged access deserves a tighter loop than general access; a quarterly review of who holds production admin is reasonable even where the rest of the estate is annual. Second, the termination path is not a review at all, it is an event-driven revocation that should happen within hours, and auditors will sample leavers specifically to test it. A quarterly review that catches a departure three months late still shows a three month window where a former employee had access, and that is a finding no cadence argument fixes.

What should a user access review include?

Each line of the review needs enough context for the reviewer to make a real decision, and enough record afterward to prove they made it. At minimum:

• The account identifier and the human behind it. Orphaned accounts with no owner are the single most common finding, and they cannot be judged until somebody claims them.
• The actual permission level, not the group name. "Engineering" tells a reviewing manager nothing. "Write access to the production database" tells them everything.
• Last login or activity date. Dormancy is the strongest signal that access is no longer needed, and it turns a guessing exercise into an evidence-based one.
• A named reviewer who can genuinely judge the access. The security team cannot know whether a specific analyst still needs a specific dashboard. Their manager can.
• An explicit decision per line: keep, reduce, or revoke. Blank means not reviewed, and an auditor will read it that way.
• Evidence the revocations happened, with dates. This is the half teams skip, and it is the half that turns a review into a control.

Do not forget the accounts that are not people. Service accounts, API keys, CI/CD tokens, and integration users all hold access, often broad access, and they are invisible in a review built from an HR roster. The same question now extends to the automated agents teams are wiring into internal systems, where the practical control is enforcing what tools and data each agent can reach rather than trusting it to behave. If an identity can read your production data, it belongs in the review whether or not it has a face.

Is a user access review preventive or detective?

Detective. The review finds access that should not exist after it has already been granted, which is the definition of a detective control. The preventive counterparts are the approval workflow that gates provisioning, role-based access that limits what a grant can include, and automated deprovisioning triggered by an HR event. Auditors ask this question because the answer reveals whether you understand your own control set, and because a control environment made entirely of detective controls is a slow one.

How do you actually run the review?

The mechanics are simple and the failure modes are all operational. Pull the current account and permission export from each in-scope system, on a date you record. Attach the context above to each line. Route each system's list to its owner or to the relevant people managers, with a real deadline, and chase them, because this step is where reviews die. Collect decisions, then hand the revocations to whoever executes them and track them to completion rather than assuming. Finally, keep the artifact set: the original export with its date, the decisions with the reviewer identity, and proof of the revocations.

What auditors sample is that last set. They will pick a handful of accounts from your export and ask to see the decision, then pick a revocation and ask to see the account is gone, then pick a terminated employee and ask when their access ended. Three questions, and the whole control either holds up or does not. Everything else in the process exists to make those three answers easy, which is the same standard that applies to compliance evidence collection generally: the artifact is the control, and anything you cannot produce did not happen as far as the audit is concerned.

Where access reviews go wrong

Rubber-stamping. A manager receiving 200 lines with a Friday deadline approves all 200. The review technically happened and detected nothing. The fix is scope: fewer systems per cycle, dormancy flagged up front so the obvious revocations are pre-identified, and reviewers who own a manageable slice.

Reviewing the roster instead of the system. Building the list from HR records rather than an export from the system itself misses exactly the accounts that matter: shared logins, contractor accounts, leftover service accounts, and anyone whose access outlived their record. Always pull from the source system.

Stopping at the decision. A revoke that nobody executes is worse than no review, because you now have documented proof you knew about inappropriate access and left it in place. Track revocations to closure with the same discipline as the decisions.

No evidence of the date. Reviews reconstructed from memory at audit time do not survive contact with a sampling auditor. The export needs a timestamp, and the decisions need to be recorded when they were made, not afterward.

Making it survivable without a dedicated team

For most companies under 200 people, access reviews fail for a boring reason: nobody owns the calendar. The control is not difficult, it is just recurring, and recurring work without an owner and a due date does not happen. Putting each review on a schedule with a named human, tracking the decisions and the revocations in the same place as the rest of your obligations, and letting the evidence accumulate as a byproduct is most of the battle. That is precisely what obligation tracking software is for, and it is why access reviews are usually the first control to visibly improve once a program stops living in a spreadsheet.

If you are still deciding which platform to run this in, our compliance software comparison covers what nineteen of them cost and which ones publish a price at all. Whatever you choose, judge it on one question: after the review is done, how long does it take to produce the export, the decisions, and the revocation proof for a single account an auditor picks at random? If the answer is more than a few minutes, the tool is filing your evidence rather than running your control.