A reviewer who approves 30 entitlements in 90 seconds is behaving rationally. Hand somebody a flat list, no context and a deadline, and rubber-stamping is the sensible response. The rubber stamp is an output of the process working as designed, not a failure of the reviewer.
The spreadsheet shows up 2 weeks before the audit: 43 apps, 230 users, 12,000 individual entitlements. Then 28 managers get an email. Most reply "looks good" within an hour. A handful raise a flag. The IT team chases down the rest, exports CSVs from admin panels nobody else has logged into in years, and assembles the evidence packet by Friday.
The auditor leaves. The next quarter, the spreadsheet shows up again.
Most companies call this an access review. The auditor calls it adequate. The reviewers, if pressed, call it what it is: a quarterly performance of governance that doesn't change much. The orphaned account from last June is still there. The contractor who left in March kept their SAP access until someone noticed. Nobody is lying. The process just wasn't built to find these things.
Why most access reviews fail
A review with teeth produces three things the spreadsheet review cannot.
Specific decisions. Not "looks good" across a hundred entitlements. A reviewer sees what a person does in an app, has a baseline to compare against, and approves or removes per entitlement. The decision is meaningful because the context is meaningful.
Actions that fire. The approve or remove decision translates into a revocation in the app. Not a follow-up Jira ticket. Not an IT manager logging into thirteen admin panels at midnight. The action happens.
Evidence that assembles itself. The full timeline, with timestamps, with the reviewer's identity, with the policy that triggered the review, with the action and its outcome. Exportable. Mapped to SOC 2 CC6.2, ISO 27001 A.5.18, HIPAA §164.308(a)(4). When the auditor asks, you click export, not "give me until Tuesday."
If a review produces all three, it bites. If only the first one fires (decisions with no follow-through), it's theater. Worse is the third one alone: evidence that says reviews happened, without proving they meant anything. That's the configuration most companies have right now.
The structural reason is that the tooling was built around the audit, not around the work.
The scale problem. A growing company with 800 people on 40 apps generates tens of thousands of entitlements. The honest way to review that volume is per-entitlement, per-quarter, with context. Nothing about the typical access-review workflow makes that possible. The reviewer gets a flat list, no context about what the entitlement does, no signal about whether the person uses it, and a deadline. The rational behavior in that situation is to rubber-stamp. The system is producing the rubber stamps.
The evidence problem. Evidence in most companies is scattered. The CSV from Okta with group memberships. The Slack thread where someone mentioned an exception. The Jira ticket that documented a contractor's elevated access. The screenshot the IT team took to prove the offboarding ran. None of it is structured. None of it ties to a policy. The week-before-audit work is reconstructing a story from artifacts that were never written to be evidence.
Both problems compound. Scale produces rubber-stamp decisions, which produce evidence that says reviews happened without proving they meant anything. Auditors catch this. So do internal compliance teams who care about the outcome.
What it takes to make a review bite
Four conditions. All four, or you're closer to theater than governance.
1. One source of truth for access. The HRIS knows who works there, in what role, in what status. SSO knows who can authenticate. Iden knows what each person can actually do, per app, per resource. When a review starts, it pulls from one place. Not five.
2. Reviewer routing tied to ownership. The right person to review someone's GitHub repository access is their engineering manager, not the IT team. The right person to review a finance-system grant is whoever owns that system, not the people-manager. The mapping has to live in the system, and it has to update when ownership changes. Otherwise reviewer routing decays into "whoever was in that role 2 years ago."
3. Decisions that translate to action. "Remove" in the reviewer view means the access is removed. Not flagged for removal. Not added to a Jira queue. Removed. The mechanism that handled provisioning handles deprovisioning at the same granularity. Channel-level, repository-level, project-level, wherever the original grant sat.
4. Continuous evidence assembly. The evidence isn't built the week before the audit. It's built every time a review action runs, in a structured format that maps to the control. SOC 2 CC6.2 (logical access provisioning), CC6.3 (deprovisioning). ISO 27001 A.5.18 (access rights review). HIPAA termination procedures. The mapping is in the system. The export is one click.
Patterns that break access reviews
Five failure modes, named so you can spot them.
-
The rubber stamp. A manager opens the review, sees 30 entitlements, has no context for what most of them do, and approves all of them in 90 seconds. This is the default outcome of any review that doesn't give reviewers anything to look at besides a flat list.
-
The spreadsheet. Reviews run by exporting access lists from each app into a CSV, consolidating manually, sending to managers as Excel files, collecting replies, reconciling, and then doing revocations by hand back in each app. Multiple steps, multiple handoffs, multiple places for the chain to break.
-
Group-level only. The review asks whether the person is still in the Engineers group. The manager says yes. But the person has eight individual repo grants, three database roles, and an admin permission in the staging environment that no group represents. None of those get touched.
-
The reviewer who left. The reviewer for an entitlement is hardcoded as a specific person. That person quit two quarters ago. The review keeps going to their old email. Nothing happens. Nobody notices until the auditor asks who reviewed what.
-
The exception that became the rule. Someone needed elevated access for one project. It got approved with a note. The note didn't have an expiry. Then 2 years later the elevated access is still there and nobody remembers why.
Doing this without a tool
A defensible review is possible on a spreadsheet. It's just expensive, and the expense is concentrated in one step people underestimate.
- Pull entitlements per app, per person, at the grain the auditor asks about. Not group membership. The repository, the channel, the role. This is the expensive step and there is no shortcut.
- Map each system to its real owner, not to IT. Keep that map somewhere that gets updated when people change jobs, or your reviewers go stale within 2 quarters.
- Give reviewers context, not a list. At minimum: when the access was granted, by whom, and whether it's been used. A reviewer with no context rubber-stamps, and that's rational rather than lazy.
- Track removals to completion. A decision that never became a revocation is worse than no review, because it produces evidence that reviews happened without proving they meant anything.
- Time-box every exception at the moment it's approved. An exception without an expiry is a permanent grant with paperwork.
- Keep the record as you go, not the week before the audit. Reconstructing a story from Slack threads and screenshots is the single biggest cost in the whole cycle.
Two to 4 weeks of elapsed time per cycle for a 40-app stack, and almost none of it is the reviewing. It's the pulling and the chasing.
There's a specific way this goes wrong and it's worth naming: a company accumulates 3 years of clean review records with the same orphaned account sitting under all of them. Nobody lied. The decisions were made and never executed.
What still needs a person
The review itself. That's the point, and no tool should take it.
What a tool can do is make the decision cheap and the follow-through automatic. What it can't do is decide whether a finance analyst genuinely still needs write access to the general ledger. Somebody who understands the job has to answer that.
Two other things stay human. A shared account used by a team has no single reviewer, and picking one is an ownership decision. And an entitlement that only one person understands, usually in the oldest system you run, needs that person to explain it before anyone can approve or remove it.
Where Iden fits
Step 3 above, solved, which is the step that decides whether the rest is worth doing.
A reviewer opens one app's review and sees each person with their employment status, department, role and groups on the same row as the approve and revoke buttons. The rows that need attention are flagged: the employee who is Inactive in HR and still holds access, the accounts that aren't people. The decision takes seconds because the context is already there.
Ein SOC-2-Review für eine Applikation. Zwei Zeilen sind markiert, weil die Person im HR-System inaktiv ist und den Zugriff noch hat. Drei der Zeilen sind keine Personen.
Removals fire through the same provisioning layer that made the original grant, at the same grain. Evidence lands in Drata, Vanta or Secureframe mapped to the control, as the review runs rather than after it.
"Access reviews finally have teeth. Employees, security, GRC, auditors. Everyone's happy."
Director of IT, 580-employee fintech
The teeth aren't a metaphor. The gap is between a process that collects signatures and one that produces revocations. That's the gap this layer closes.