Every quarter, someone exports a list of users from each system, sends a spreadsheet to each manager, and asks them to confirm their people should still have access. Every manager approves everything. The evidence is filed, the control passes, and nobody's access changed.
That is the access review as most companies run it, and it satisfies an auditor while removing no risk. This post is why the default design produces rubber-stamping, and what to change so the review finds things. For whoever owns the control, usually alongside four other jobs.
Why managers approve everything
Not laziness. The task as presented is nearly impossible to do well.
The list is uninterpretable. A manager sees prod-db-readonly and svc_pipeline_rw next to an engineer's name. They do not know what those grant, when they were used, or what removing them would break. The safe answer to a question you cannot evaluate is yes.
The default costs nothing and the alternative costs something. Approve, and nothing happens. Revoke, and you might break a colleague's workflow and get a message about it on Friday. The incentives point one way.
It arrives as an interruption with no context, a deadline, and no obvious connection to anything the manager cares about.
Everything is reviewed at once, so the fifty routine entitlements bury the two that matter.
Any design that ignores these produces approval-in-bulk, no matter how the form is worded.
Changes that make it work
Show last-used dates, and sort by them. This is the single highest-value change and it is usually available: cloud providers, identity providers and most SaaS expose last sign-in or last API use. An entitlement unused for 200 days is a different question from one used yesterday, and it turns an unanswerable question into an obvious one.
If your system cannot tell you when a permission was last used, that is worth knowing too, and worth fixing before the next cycle.
Review the exceptions, not the population. Instead of every user and every entitlement, send only:
- Access unused for more than 90 days
- Access granted outside the standard role for that job function
- Anyone holding administrative or production-write permissions
- Anything granted during an incident and never revoked
- Service accounts with no named owner
That is usually five to ten percent of the rows and it contains essentially all of the risk. The rest can be recertified in bulk with a sampled spot-check, which is defensible if you document the sampling method.
Make revocation the default for the unused set. Invert the burden. Tell people what will be removed on a date unless they object, rather than asking them to approve removal. Requiring an action to keep access rather than to remove it changes the outcome more than any amount of training.
Give it a safe reversal path, a self-service re-request that takes minutes, so the cost of a wrong removal is small. Then people stop defending access they do not need.
Route to someone who can evaluate it. The line manager knows what their report does. They often do not know what a specific database role grants. For technical entitlements, route to the system owner and ask a different question: not "should this person have access" but "does this permission still need to exist, and for whom".
Service accounts are where the real problem is
Human access reviews get attention because humans have managers. Service accounts do not, and they are usually the most privileged identities in the environment.
The recurring findings:
- No named owner, so nobody is asked about them.
- Credentials that have never rotated, from an integration set up in 2021.
- Permissions granted broadly during setup because scoping was fiddly, never narrowed.
- Accounts for vendors no longer under contract.
- Keys in CI belonging to someone who left.
Every one of these is a standing access path with no review cycle. Give every service account a named human owner and put them in the review with the same exception rules: unused, over-privileged, unrotated. If an account has no owner, that is the finding, and the remediation is to find one or disable it.
What auditors actually test
If you are in scope for SOC 2 or ISO 27001, expect them to check that reviews happened on the stated frequency, that they covered in-scope systems, that a reviewer is identifiable, that exceptions were remediated, and that remediation completed.
That last one fails most often. The review found things, tickets were raised, and three quarters later the access is still there. A review that identifies and does not remediate is worse evidence than no review, because it documents that you knew.
So track closure, with a deadline, and report the closure rate rather than the completion rate. Completion measures whether the spreadsheets came back. Closure measures whether anything changed.
Measure whether it is working
One number tells you almost everything: the revocation rate, the percentage of reviewed entitlements actually removed.
If it is near zero, the review is theatre. A healthy first cycle on a system that has never been reviewed removes a substantial fraction, often more than a fifth, because access accumulates and nothing removes it. If your rate is under a few percent and holding, either you have unusually tidy access management, or nobody is reading.
Track it per system. A single system with a zero rate while others find things is usually a routing problem: the reviews are going to someone who cannot evaluate them.
The concession
Reviewing exceptions rather than the full population is a genuine reduction in coverage, and an auditor may push back. The answer is to document the risk-based method: what the exception criteria are, why they capture the material risk, and what sampling covers the remainder. Risk-based recertification is accepted practice, and it is more defensible than a full review that everyone rubber-stamps.
There is also a real limit to periodic review as a control. Quarterly means access can be wrong for three months. Where that matters, the answer is not a more frequent review, it is time-bound access that expires on its own, so that most entitlements never need reviewing because they are already gone.
The implication
The purpose is to remove access that should not exist. A review that removes nothing has not passed, it has failed quietly while producing evidence that says otherwise.
So judge yours on what it revoked. If the answer is nothing, the design is wrong, and the fix is almost always the same two changes: show last-used dates, and make removal the default.
