A user access review is the recurring check that asks, for every account and entitlement in scope, whether the person still needs it. Someone with the authority to decide looks at the access and chooses per item to keep it or remove it. The decision is recorded together with proof that the removals happened. It is one of the load-bearing controls in every major compliance framework, and it is also one of the most commonly faked.
pull every account and entitlement in scope
|
v
route each item to someone who can judge it (manager or app owner)
|
v
decide per item: keep or remove <-- the rubber stamp happens here,
| when the reviewer has no context
v
EXECUTE the removals in the apps <-- the step most reviews skip
|
v
record who decided what, when, and proof the removals happened --> audit evidenceWhy does the control exist?
Access accumulates over a tenure whether or not anyone intends it to.
How the accumulation happens
People join, change roles, join projects and pick up permissions along the way. Each grant is reasonable on the day it is made, which is why none of them is ever questioned later. Four sources feed the pile, and none of them is anyone's mistake. A new role adds its bundle without anyone removing the last one, because the mover stage of the lifecycle rarely revokes. A project adds a temporary grant with no end date attached. An incident adds an elevated permission at two in the morning that nobody comes back to. And a colleague adds access directly inside an application, which the identity provider never sees. Left alone, a long-serving employee ends up with access reaching back through every role they have ever held.
Why a periodic check is the answer
The access review is the periodic correction to that accumulation. It is the moment someone is supposed to look at the accumulated access and cut what is no longer justified. Done well, it is the main thing standing between a stack and quiet privilege creep, and it is how orphaned and over-scoped accounts get caught between offboarding events. It is also the control an auditor can most easily verify, which is why frameworks lean on it:
SOC2 does a great job of assuring that you don't have to trust us that we're terminating access when employees leave, and that we're conducting frequent access review meetings.
How does a user access review work?
The mechanics are consistent across frameworks, whatever the framework calls the control.
1Scope
The systems, the population and the entitlements in the review are defined in advance. A review scoped to the applications behind SSO is a review of the part of the stack that was already easiest to govern.
2Pull
The current access is pulled: every account and entitlement across the systems in scope, from the systems themselves rather than from a list someone maintains. For the applications the identity provider does not manage, this means an API call or an export from each one.
3Route
Each item is routed to a reviewer who can judge it, usually the person's manager or the owner of the resource. A row routed to someone with no context is a signature, not a decision.
4Decide
The reviewer decides per item whether it stays or goes, and the decision is recorded with the reviewer, the timestamp and the context they saw.
5Enforce
Removals are executed in the application where the access lives, not noted for someone to do later.
6Evidence
The whole exercise is recorded: who reviewed, when, what they decided, and proof that the removals actually happened. That last step is the one that separates a real review from a documented one.
How does the review change for apps without SCIM?
Where the population comes from
For SCIM-connected applications, the identity provider already knows every account and group, so pulling the review population is a query. For applications without SCIM, the account list lives inside the application, and the review covers only what someone exports from it. The difference is not one of effort alone. A directory query returns every account that exists; an export returns every account the person doing the export knew to look for, which is a smaller and less stable set.
| Application | Where the population comes from | Where the revocation runs |
|---|---|---|
| SCIM on the current plan | The identity provider's view of the application | The directory, which the application honours |
| SSO but no SCIM | An export from the application; the identity provider only sees who logged in through it | Inside the application, by hand or over its API |
| No SSO | An export from the application, if someone remembers it is in scope | Inside the application |
Why the gap concentrates the findings
A review that skips the non-SCIM applications checks the accounts the identity provider already controls and misses the ones where orphaned accounts and stale contractors actually live. The concentration is structural, not a matter of which teams are careless. An application connected to the directory has its accounts created and closed by machinery, so its drift is small. An application outside the directory has its accounts created by invitation and closed by memory, so its drift is where the sample lands. Someone who has taken companies through SOC 2 described the alternative:
Lots of apps being used by enterprises don't even have support for SSO at all, even if you were willing to pay the tax. Audits can't require you to use something that does not exist. Thus, the manual syncing and comparing is a frequent ritual of audit compliance (and to be fair, is something that should be done regularly even if no auditor is asking for it).
Why are most access reviews theater?
Two failures account for it, and the first is structural rather than lazy.
The rubber stamp
A reviewer is sent a spreadsheet with hundreds of rows, each one a cryptic entitlement string. Nothing on the sheet says what the access does, whether it is used or why it was granted. Investigating each row would take hours, approving the whole sheet takes one click, and so the sheet gets approved, the audit is satisfied, and not a single grant changes. The review exists as evidence rather than as a control. That gap between the paperwork and the reality is what practitioners mean by governance theater, and the cost of the manual version is what pushes large organizations toward automation:
Big orgs will pay more for SCIM to avoid having to do user access reviews in the UIs of individual products they have bought. It directly translates to person-hours of busywork and admin burden of executing / tracking that work.
The unenforced decision
The second failure is quieter and harder for an auditor to spot. The decision is made but never enforced. A reviewer marks access for removal, the note is saved, and the revocation never runs. The evidence now says the access was removed while the system says it is still there, and an auditor who checks both finds the discrepancy.
What makes an access review real?
Three things fix it, and none of them is a longer spreadsheet.
Context at the point of decision
The reviewer sees what the entitlement grants, when the account was last used, how the person came to have it, and whether the person is still employed and in the same role. The decision is then informed, not a guess made under a deadline.
Enforcement wired to the decision
A rejection triggers the actual revocation in the application where the access lives. The review changes the state of the system rather than documenting an intention. The test is mechanical: after the campaign closes, a fresh pull from the application should no longer contain the entitlement that was rejected, and nobody should have to run that pull by hand to find out.
A scope that includes the applications outside SSO
The population under review has to be every account that exists, not every assignment the identity provider made. That means reading each application's own list, including the ones reachable only through an admin console, and reconciling the two views before the review is routed. A review whose scope is defined by what was easy to pull is answering a different question from the one the framework asks.
| A review that is theater | A review that is a control |
|---|---|
| A spreadsheet of entitlement strings | Each row shows what the access grants and when it was last used |
| Routed to whoever is available | Routed to the manager or the resource owner |
| One approval covers the sheet | One decision per entitlement, recorded with a timestamp |
| Rejections noted for later | Rejections executed in the application |
| Evidence is the spreadsheet | Evidence is the record of decisions plus proof of removal |
| Quarterly, all at once | Continuous for changes, with a smaller scheduled run for the rest |
An access review in Iden pulls the account list from each application directly, so the population includes the applications the identity provider cannot see. Each row shows the reviewer the person's employment status, department, role and groups beside the entitlement, approve and revoke sit on every row, and a revoke is executed in the application rather than noted for later. The feature behind it is Access reviews with a decision on every row.
A SOC 2 review of one app. Two rows are flagged because the employee is Inactive in HR and still holds access, and three of the rows are not people.
The test is whether, after a review closes, the organization can show that everything marked for removal is actually gone without anyone checking by hand. If it cannot, the review recorded a decision it did not enforce.