The user access review, explained (with example record)

In a user access review, the owner of each in-scope system walks its account list and confirms three things: every account belongs to a current member of the team, every permission level is still justified by the person’s role, and access that should have been removed actually was. The output is a dated, signed record with findings and the tickets that resolved them.

Auditors lean on this control because it’s where paper meets reality. Policies describe intent; the access review shows whether anyone checks. It’s also perfectly testable — discrete, dated, recurring — so an auditor can request four quarters of records and see instantly whether the control operated all year or was reconstructed the week before fieldwork. Backfilled reviews give themselves away: identical timestamps, zero findings, no tickets.

And it catches the failure nearly every company has. Access accumulates: a contractor rolls off but the SSO account lives on, an engineer keeps admin from an incident rotation two quarters back, a service account outlives the project that created it. Without a forcing function nobody notices until an auditor — or an incident — does. That drift is an insider-risk problem before it’s a compliance one.

Scope starts with the systems that matter: production infrastructure (cloud consoles, databases, orchestration), the identity provider itself, source control and CI/CD, and every SaaS product holding customer or sensitive data — support desk, data warehouse, billing. Write the list down once, give each system a named owner, and change it deliberately; re-deciding scope every quarter is how systems quietly fall out of it.

Within each system, four populations deserve different attention. Privileged accounts get line-by-line scrutiny — admin on the cloud console or the identity provider is where a compromised account does real damage. Service accounts need a named human owner, a documented purpose, and credentials that rotate; the orphaned service account is a perennial finding. Departed users get cross-checked against the HR roster, because deprovisioning gaps are precisely what the review exists to catch. Standard users get the two-question test: still here, and still needs this level?

One person coordinates — usually the compliance or security lead — but each system’s review belongs to whoever can actually judge its accounts: the infrastructure lead for AWS, the engineering manager for source control, the support lead for the help desk. Centralizing the judgment in someone who can’t evaluate whether access is needed produces rubber stamps, and auditors interview reviewers precisely to test for that.

Evidence of completion is a package, not a screenshot: the signed record, the raw exports it was performed against, and the revocation tickets traced to closure. One caution from the audit side — a program reporting zero findings quarter after quarter reads as a review nobody performed. Finding and fixing drift is the control working, so write the findings down. A review that exists on the policy page but not in the evidence folder is the single most predictable finding in the policy and access domain.

For programs Agency operates, the quarterly review runs on our calendar, not yours. We pull the exports, pre-screen them against your roster, chase each system owner for the judgment calls only they can make, open the revocation tickets, verify they closed, and file the signed record in Vanta or Drata where the auditor will look. Your team’s contribution shrinks to about an hour of decisions per quarter.

That’s the general shape of managed compliance: recurring controls become routine because someone is accountable for making them routine. The access review stops being the task everyone dreads in week eleven and becomes the one finished in week two.