Access Reviews Are Audit Theater (And Everyone Knows It)

For IT administrators tired of quarterly compliance exercises that do not improve security.

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:

1. Export who has access to what
2. Send to managers for review
3. Managers thoughtfully evaluate each person’s access
4. Managers revoke inappropriate access
5. Security posture improves

Here’s what actually happens:

1. Export who has access to what
2. Send to managers for review
3. Managers panic because they have 200 rows to review and don’t know what half the groups do
4. Managers approve everything to avoid breaking something
5. IT checks the “access review completed” box for compliance
6. Nothing changes

Why Access Reviews Fail

1. 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.

2. 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.

3. 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.

4. 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.

5. 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:

Sales Engineers should have:
  - Sales Team group
  - Engineering Tools (read-only)
  - GitLab customer-solutions
  - Salesforce (Sales Engineer profile)

Sales Engineers should NOT have:
  - Production deploy access
  - Admin privileges
  - Finance systems

2. Continuous Reconciliation

Compare actual state (what people have) to expected state (what policy says they should have) every day. Not quarterly. Daily.

Drift Report - 2024-11-24

User: [e-mail]
Role: Sales Engineer

Expected access (from policy):
  ✓ [e-mail]
  ✓ slack:#sales-team
  ✓ gitlab:customer-solutions (reporter)
  ✓ salesforce:profile-sales-engineer

Actual access:
  ✓ [e-mail]
  ✓ slack:#sales-team
  ✓ gitlab:customer-solutions (reporter)
  ✓ salesforce:profile-sales-engineer
  ⚠ gitlab:platform-engineering (developer)  ← NOT IN POLICY

Action required:
  - Remove or justify gitlab:platform-engineering access

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 [e-mail]” 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.

Quarterly Exception Review for Team: Enterprise Sales

Exceptions requiring review:

1. Sarah - gitlab:platform-engineering access
   Reason: Q4 migration project
   Granted: 2024-10-01
   Expires: 2025-01-31
   Action: [ ] Extend [ ] Remove [ ] Convert to permanent (update policy)

2. John - finance-reports group
   Reason: Commission calculation transparency
   Granted: 2024-08-15
   Expires: Never
   Action: [ ] Remove [ ] Justify permanent access

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

1. 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.

2. 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.

3. 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.

4. 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.

5. 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:

Employee Policy (applies to all active employees):
  - Google Workspace access
  - Slack
  - Email group: [e-mail]
  - HRIS access (employee self-service)

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:

Engineering Policy:
  - Everything in Employee Policy
  - GitHub organization access
  - Engineering Slack channels
  - Dev environment access

Sales Policy:
  - Everything in Employee Policy
  - Salesforce
  - Sales Slack channels
  - CRM tools

Now 80% of access is covered by policy.

Step 3: Handle role-specific policies

Add policies for specific roles within departments:

Senior Engineer Policy:
  - Everything in Engineering Policy
  - Production read access
  - On-call tools
  - Security review tools

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.