Access review season. Again.
A spreadsheet with 8,000 rows gets exported. Each row represents someone’s access to something. Forty managers receive an email with the subject line: “Q4 Access Review - Due in 2 Weeks.”
Two weeks later:
- 12 managers haven’t responded
- 23 managers approved everything without reviewing
- 5 managers asked “what is this?” and needed the entire process explained
- Zero meaningful security improvements resulted
But the auditors are happy. Documentation shows that access was “reviewed.”
This is access review theater—the compliance ritual where everyone pretends they’re improving security, but nothing actually changes.
The Access Review Fantasy
Here’s how access reviews are supposed to work:
- Export who has access to what
- Send to managers for review
- Managers thoughtfully evaluate each person’s access
- Managers revoke inappropriate access
- Security posture improves
Here’s what actually happens:
- Export who has access to what
- Send to managers for review
- Managers panic because they have 200 rows to review and don’t know what half the groups do
- Managers approve everything to avoid breaking something
- IT checks the “access review completed” box for compliance
- Nothing changes
Why Access Reviews Fail
Managers don't have the context
“Should Sarah still have access to prod-deploy-eng?” Sarah’s manager has no idea. They don’t know what that group does, when Sarah got it, why she got it, whether her current role needs it, or what would break if they removed it. So they approve it. Better safe than sorry.
The spreadsheet is overwhelming
A manager receives 200 rows to review. Each row has user name, group name (often cryptic like okta-grp-eng-tools-v2), system name, and date granted. The manager has 2 weeks and 47 other priorities. They spend 10 minutes scanning it, approve everything, and move on.
Reviews show what people have, not what they should have
Access reviews are backward-looking. They show current state. They don’t show what access this person should have based on their current role, what access they’re missing that they should have, or what access is baseline entitlement vs. exception. False negatives are invisible. If Sarah should have access but doesn’t, the review won’t catch it.
Reviews happen too infrequently
Quarterly reviews mean someone can operate with excessive privilege for 3 months before anyone notices. And that’s assuming the review catches it—it usually doesn’t.
There's no clear action when something's wrong
Manager finds inappropriate access. Now what? Do they remove it immediately (might break something critical)? Do they investigate why it was granted (don’t have time)? Do they consult with IT (creates a ticket that sits in the queue)? Do they approve it and make a mental note to “look into it later” (this is what actually happens)?
The Real Purpose of Access Reviews
The uncomfortable truth: access reviews exist for auditors, not for security.
They’re a compliance checkbox. They create paper trails. They demonstrate “governance.”
But they don’t meaningfully reduce risk.
If access provisioning is wrong, quarterly reviews won’t fix it. They just document the wrong state four times a year.
Auditors require evidence of access reviews, but sophisticated auditors recognize the difference between review theater and meaningful controls. When managers rubber-stamp 200 access decisions in 10 minutes, that’s a control weakness, not a strength. Organizations that can demonstrate continuous policy validation and exception-only reviews present stronger evidence for CC6.1 and CC6.2 compliance.
What Actually Works: Continuous Access Compliance
Companies with genuinely good access governance don’t rely on quarterly reviews. They use continuous compliance—where access is validated constantly, not four times a year.
Here’s the model:
1. Define Expected State (Policy)
Instead of asking “does Sarah have access to X?” ask “should Sarah have access to X based on her current role?”
Define this as policy:
2. Continuous Reconciliation
Compare actual state (what people have) to expected state (what policy says they should have) every day. Not quarterly. Daily.
This surfaces drift immediately. Not in 90 days. Today.
3. Exception Management
When someone needs access that’s not in their role’s policy, it should be:
Explicit: “Sarah needs platform-engineering access for Q4 migration project”
Temporary: “Expires 2025-01-31”
Approved: “Approved by [email protected]”
Tracked: “Automatically removed on expiration unless renewed”
Exceptions are first-class citizens in the system, not shadow IT.
4. Manager Review for Exceptions Only
Instead of reviewing 200 rows of “is this correct?” managers review 8 rows of “these are exceptions to policy. Should they continue?”
That’s a conversation managers can actually have.
This is manageable. Eight decisions, not 200.
Exception-based reviews demonstrate stronger controls than full-population reviews. When auditors see that baseline entitlements are policy-driven and only exceptions require human review, they see evidence of least-privilege design. This satisfies SOC 2 CC6.3 (role-based access) and ISO 27001 A.9.2.5 (review of user access rights) more effectively than quarterly spreadsheet attestations.
The Benefits of Continuous Compliance
Drift is visible immediately
Someone manually grants access outside of policy? The system flags it within 24 hours. Investigation happens while context is fresh, not 90 days later.
Managers focus on exceptions, not baselines
Managers aren’t reviewing whether every Sales Engineer has the Sales Team group (that’s policy). They’re reviewing the 5% of access that’s unusual.
Audit evidence is continuous
Auditors don’t see “we reviewed access in Q1, Q2, Q3, Q4.” They see “policy defines expected access, system validates compliance daily, all drift is tracked and justified.” That’s stronger evidence than quarterly spreadsheets.
Access is always correct
When Sarah’s role changes from Sales Engineer to Product Manager, the system immediately knows what access she should lose (Sales Engineer baseline entitlements), what access she should gain (Product Manager baseline entitlements), and what exceptions persist (project-based access with defined expiration). Her access is correct within hours, not months.
Security posture actually improves
Continuous compliance catches privilege creep (accumulation across role changes), orphaned access (people who left but still have access), policy violations (manual grants outside approved patterns), and stale exceptions (temporary access that should have expired). It finds and fixes security issues rather than just documenting them.
Implementing Continuous Compliance
Step 1: Start with policy definition
Pick the most common role (probably a generic “Employee” role). Define what everyone in that role should have:
Deploy that. Let the system validate compliance for one week. Drift becomes immediately visible.
Step 2: Expand to department-level policies
Add policies for each department:
Now 80% of access is covered by policy.
Step 3: Handle role-specific policies
Add policies for specific roles within departments:
This covers another 15% of access.
Step 4: Exception workflow for the remaining 5%
The 5% that doesn’t fit policy goes through an exception workflow: request with justification, approval from appropriate owner, and expiration date (temporary) or policy update (permanent).
Every exception is tracked. Every exception is reviewed regularly.
Step 5: Decommission quarterly reviews
Once there is comprehensive policy coverage (95%+ of access defined), daily drift detection, and exception management, quarterly reviews can be replaced with quarterly exception reviews (review the 5%, not the 95%) and continuous audit logs (auditors see policy + compliance evidence).
Transitioning from quarterly reviews to continuous compliance requires documentation that satisfies control objectives. The key evidence: policy documentation (this role should have this access), continuous compliance monitoring (daily validation that policy matches reality), and exception tracking (any deviation from policy is logged, justified, and reviewed). This is stronger evidence than quarterly reviews where managers approved everything without scrutiny.
The Pushback (And How to Address It)
“But auditors require quarterly access reviews!”
Auditors require evidence that access is validated appropriately. They don’t specifically require quarterly spreadsheet reviews.
The stronger evidence package includes policy documentation (this role should have this access), continuous compliance monitoring (daily validation that policy matches reality), and exception tracking (any deviation from policy is logged, justified, and reviewed). This demonstrates better controls than quarterly reviews where managers approved everything without looking.
“But managers need to review their team’s access!”
Yes. But they should review exceptions, not baseline entitlements.
Asking managers to validate that every Engineer has GitHub access wastes their time. Asking them to validate that Sarah still needs finance-reports access for her cross-functional project? That’s a valuable decision.
“But this requires policy-based access management!”
Correct. This model requires a policy engine that defines expected access, continuous reconciliation between policy and reality, and exception management workflows.
Organizations without these capabilities have two options: build (expensive, ongoing maintenance) or adopt purpose-built tooling (platforms like Provisionr).
What This Means for Audits
When auditors arrive, the evidence package includes:
Policies (documented expected access per role)
Compliance dashboard (policy vs. reality, daily)
Exception log (any deviation from policy, with justification and approval)
Drift remediation process (how discovered violations are handled)
Auditors see strong controls (policy-driven, not ad-hoc), continuous validation (not point-in-time), clear audit trail (every access decision is documented), and proactive remediation (drift is caught and fixed immediately).
This is objectively better than quarterly spreadsheet reviews.
The Bottom Line
Access reviews are security theater because they treat symptoms, not causes.
The cause isn’t “we need to review access more often.” The cause is “access provisioning isn’t policy-driven, so manual validation is required to confirm people have appropriate access.”
Fix the cause. Move to continuous compliance. Define expected state as policy. Validate daily. Handle exceptions explicitly.
Quarterly spreadsheet reviews don’t improve security. They document the chaos four times a year. 
