User Access Review

What Is a User Access Review?

A user access review is a scheduled, documented process in which an organization examines every account and entitlement across its in-scope systems and requires an accountable person to confirm that each one is still appropriate. Access that is confirmed stays. Access that is not confirmed is removed, and the removal is tracked to completion. The activity is also called access recertification, entitlement review, or user access recertification, and in identity governance tooling it is usually labeled a campaign.

The control exists because access grows in one direction on its own. Onboarding adds rights. Promotions add rights. A short project adds rights that outlast the project. An outage at 2 a.m. adds emergency rights that nobody revisits at 9 a.m. Offboarding is supposed to remove everything, and it usually removes the obvious accounts while missing the contractor portal, the vendor management console, and the shared mailbox. Left alone, an environment drifts steadily toward a state where a large share of users can reach systems their current job has nothing to do with.

Access reviews are the scheduled counterweight to that drift. They differ from provisioning controls, which govern the moment access is granted, and from monitoring controls, which watch how access is used. A review looks backward at the accumulated state and asks a question that no automated rule can answer on its own: does this person still need this, given what they do now? That judgment has to come from someone who knows the job, which is why the reviewer is a business owner or manager rather than an IT administrator.

The distinction that trips organizations up is between a user list and a review. Exporting the members of a group is an inventory task that takes minutes. A review requires that a specific human being looked at that inventory, made a decision on each line, recorded the decision, and that the revocations flowing from it were executed and verified. Craig Petronella, MIT-certified cybersecurity professional and cybersecurity expert witness, has examined enough incident timelines to know which half organizations skip. The export is almost always there. The decisions and the closed revocation tickets are what an assessor cannot find.

Five Problems Only a Review Finds

Every finding class below is invisible to perimeter security, endpoint protection, and monitoring. Each one is a standing grant that looks entirely legitimate to a security tool because, procedurally, it was legitimate when it was issued.

Two further classes deserve their own mention because they are consistently the most contested findings in a review cycle. The first is shared and generic credentials: the operations login that four people use, the vendor account with a password in a wiki, the break-glass administrator whose password has not rotated since the last audit. Shared credentials defeat attribution entirely, which means that if something goes wrong, forensic reconstruction of who did what becomes guesswork. Our data breach forensics work regularly runs into exactly this wall.

The second is standing administrative access. Administrator rights held permanently, rather than requested and time-boxed when needed, convert every routine credential theft into a total compromise. A review that recertifies fifty standard users while waving through nine permanent domain administrators has inverted its own priorities. Sort the population by privilege before you sort it by name, and spend the reviewer attention where the blast radius is.

Which Regulations Require Access Reviews

Access recertification appears in every major security framework, though the wording and the mandated frequency differ. If your organization is subject to more than one, the practical approach is to run a single review process at the strictest cadence you face and map the one evidence package to every framework that asks for it.

The pattern across the table is worth naming. Only PCI DSS commits to a number. Every other framework hands the frequency decision back to you and then holds you to whatever you wrote down. That is the trap: an organization writes "quarterly" into its access control policy because quarterly sounds rigorous, runs one review in March, and hands an assessor a policy that documents its own non-compliance. Pick a cadence you will actually sustain, write that one down, and hit it. If you are building the policy set behind this, our data classification policy guidance covers the same discipline applied to information handling.

Defense contractors have a further consideration. Under CMMC, gaps in access control practices affect your assessment score, and not every unmet requirement can be deferred. If a review reveals systemic access problems you cannot close before assessment, understand the POA&M eligibility rules before you assume you can schedule the fix for later, and check what the shortfall does to your SPRS score.

Which Systems Belong in the Review

Scope determines whether a review is a security control or a compliance ritual. The instinct is to review the identity provider and declare victory, because that is the system with the cleanest export. The identity provider is exactly the system where access is best managed already. The risk lives in the places it does not reach.

Build the population from the systems that hold or reach regulated and sensitive data, then work outward. In most environments that means the following categories, and the order below reflects how often each one produces findings rather than how easy it is to export.

A note on nested groups, because it is the single most common technical defect in a first review. If a reviewer is shown group membership, they are being asked to affirm a label rather than an entitlement. A group named Finance Read Only may, through two layers of nesting, confer write access to a payroll share. Reviewers cannot catch that, and they should not be expected to. Resolve effective permissions before the review begins, and show the reviewer what the account can actually do.

The Seven-Stage Review Cycle

A repeatable review has a defined beginning, a defined end, and an evidence artifact at each stage. Skipping stage six is the reason so many organizations run reviews for years and still fail on access control findings.

Stage one, scope and cadence. Decide which systems are in scope for this cycle and how often each tier is reviewed. Privileged access on a shorter interval than standard users is a defensible and common split. Write the decision into your access control policy, because that policy is what an assessor will hold you to.

Stage two, extract and reconcile. Pull the account population from each in-scope system and reconcile it against the authoritative worker roster from HR. This step alone surfaces orphaned accounts before any reviewer sees the list. Resolve nested groups and effective permissions here, not later. A population that is wrong at extraction produces a review that is confidently wrong at every subsequent stage.

Stage three, assign reviewers. The reviewer is the person accountable for the business function, not the administrator who provisioned the account. IT can attest that an account exists. Only the manager can attest that the person still needs it. For service accounts, the reviewer is the named technical owner recorded during scoping, and if no owner can be identified, that absence is itself the finding.

Stage four, run the certification. Give reviewers a bounded window, a clear decision on each line, and a required justification for anything retained at an elevated privilege. Track completion. A review with a sixty percent response rate is not a completed review, and reporting it as one is how organizations end up with an evidence package that contradicts itself.

Stage five, execute revocations. Every revocation decision becomes a ticket with an owner and a due date. This is the handoff where reviews most often decay: decisions get made, the spreadsheet gets filed, and nothing is actually removed. Tie the ticket back to the review line item so the two can be reconciled later.

Stage six, verify removal. Re-query the source system and confirm the account or entitlement is gone. This is the step that separates a control from a formality, and it is the one an experienced assessor probes first. A closed ticket is a claim. A fresh export showing the account absent is proof.

Stage seven, package the evidence. Assemble the starting population, the reviewer decisions with timestamps, the revocation tickets, the verification exports, and a summary of exceptions and their disposition. Store it as an immutable record for the cycle. This package is what you hand an auditor, and it is what supports the access control narrative in your System Security Plan.

Why Reviews Get Rubber-Stamped

The most predictable failure in access recertification has nothing to do with tooling. It is that reviewers approve everything. Send a manager a spreadsheet with four hundred rows and a Friday deadline, and the rational response is to select all and approve. The review completes, the metrics look excellent, and the environment is exactly as permissive as it was before.

This is a design problem, not a discipline problem, and it responds to design fixes. The first is population size. If a reviewer is handed hundreds of lines, you have asked for a decision they cannot make. Segment by system and by manager so that no single reviewer faces more than they can genuinely assess in one sitting. Risk-rank the lines so the privileged entitlements appear first, while attention is highest.

The second fix is context. A row that reads "jdoe, group FIN-APP-02" is unanswerable. A row that reads "Jane Doe, Accounts Payable, can approve payments in the finance system, last used 94 days ago" is a decision anyone can make in seconds. Last-login and last-use data change reviewer behavior more than any policy reminder, because dormancy makes the revocation obvious and lowers the perceived cost of saying no.

The third fix is consequence. If approvals and revocations produce identical outcomes because revocations are never executed, reviewers learn quickly that the exercise is theater. Closing the loop visibly, so managers see that their revocations actually removed access, is what converts a compliance chore into a control people take seriously. As Craig Petronella details in his book How Hackers Can Crush Your Business, the controls that fail in practice are rarely the ones nobody implemented. They are the ones that were implemented in a form that made honest participation optional.

Spreadsheets, Identity Governance Tooling, or Managed

There are three realistic ways to run access reviews, and the right answer depends on the size of your account population, the number of systems outside single sign-on, and whether you have someone whose job includes chasing reviewers to completion.

Spreadsheets are not automatically wrong. For an organization with two hundred accounts across four systems and a single framework obligation, a disciplined spreadsheet process with real revocation verification beats an identity governance platform that was purchased and half configured. The failure mode of the spreadsheet approach is not the tool. It is that no one owns the chase, so cycles slip from quarterly to whenever the audit is scheduled.

Six Ways Access Reviews Fail

That last one deserves emphasis because it reveals a distinct class of problem. When the same entitlement is revoked in one cycle and present again in the next, the review is working and the provisioning process is broken. Something, usually a role template or an automated group assignment, is re-granting it. No amount of reviewing fixes that. Comparing cycles is the only way the pattern becomes visible.

Access Reviews with Petronella Technology Group

Petronella Technology Group has been securing regulated organizations from Raleigh since April 2002. We are a CyberAB Registered Provider Organization, RPO #1449, our team holds CMMC Registered Practitioner certification, and we have held a BBB A+ rating since 2003. Access review sits inside our broader cybersecurity and compliance practice rather than being sold as an isolated exercise, because a review that is not connected to provisioning, offboarding, and monitoring simply reports the same findings every quarter.

An engagement starts with scoping. We map your authentication surface, identify the applications that authenticate outside single sign-on, and locate the non-human identities that no one has claimed. That discovery output is frequently the most useful deliverable of the first cycle, because most organizations have never had a complete list of where authentication actually happens.

From there we build the review population with effective permissions resolved and the HR roster reconciled, assign reviewers, and run the certification with the follow-through that determines whether a cycle completes. Revocations are tracked to closure and verified against the source system. The evidence package is assembled to support the access control narrative in your System Security Plan, and where multiple frameworks apply, ComplianceArmor® maps the one package across them. Organizations that also want the underlying access controls tested can pair the review with penetration testing to confirm that what the entitlement list says matches what an attacker can reach.

We serve Raleigh, Durham, Chapel Hill, Cary, Apex, and the wider Research Triangle, and we support regulated clients nationwide. Whether your driver is a SOC 2 Type II window, a CMMC assessment, a HIPAA risk analysis, or a board that has started asking who can reach the financial system, the review process is the same. What changes is which evidence mapping you need at the end of it.

User Access Review Questions