- Why most access reviews fail: The spreadsheet-based access review fails not because people don't try hard enough, but because it is structurally wrong. The data is stale before the review starts, managers approve without context, identified over-provisioning is never actually revoked, and the "evidence" produced would not survive a rigorous SOC 2 audit sample.
- What a good access review actually requires: Current access data pulled directly from the identity provider and SaaS applications (not exported last month), manager prompts that include enough context for real decisions, a documented approval/revocation record for every account reviewed, and verified revocation of flagged access — not just a spreadsheet marking it for removal.
- Review frequency by risk tier: Privileged access (admin rights, production system access) — quarterly. Standard application access — semi-annually. Low-risk tools with no access to sensitive data — annually. All reviews should produce documented evidence even when no changes are made — "reviewed and confirmed" is itself the evidence.
- The orphaned account problem: Organizations with 18% annual workforce turnover (the 2026 benchmark average) accumulate orphaned accounts — access belonging to former employees — at a rate that quarterly reviews alone cannot fully contain. Automated offboarding is the structural fix; access reviews catch what automation misses.
- The license optimization connection: Access reviews that identify accounts not used in 90 days do not just reduce security risk — they surface SaaS licenses being paid for but not used. A 2026 benchmark found that access review-driven license optimization yielded an average of 28% annual SaaS cost savings for organizations with more than 1,000 cloud users.
- WorkVerge Software Access Visibility: A per-employee view of all provisioned software and licenses, connected to identity provider data and last-login tracking — enabling access reviews that start from current data rather than stale exports, and producing documented approval records as evidence.
Introduction: Why Most Access Reviews Are Security Theater
Most organizations conduct access reviews. Most access reviews are compliance theater — they produce a spreadsheet marked "completed" that a manager approved by clicking through 200 rows in 15 minutes without reading them, based on data that was accurate three months ago, with identified issues that were never actually remediated. The review was conducted. The controls it was supposed to verify were not.
SOC 2 auditors know this. When testing CC6.3 — the logical access review requirement — experienced auditors do not just ask whether access reviews were conducted. They ask to see the data source used (was it current?), the approval records (are they meaningful decisions or checkbox completions?), and the remediation evidence (were identified issues actually resolved?). An access review spreadsheet marked "completed Q2 2026" without corresponding revocation evidence for the 12 over-provisioned accounts the reviewer marked for removal is a finding, not evidence of a control.
Access reviews are one of the IT tasks that everyone agrees is important and almost nobody does well. This guide explains why the spreadsheet approach structurally fails, what a good access review actually requires, and how to build the process that produces genuine security assurance alongside the compliance evidence. For the compliance framework that requires access reviews, see SOC 2 Compliance for IT Teams: What Asset Management and ITSM Must Cover.
Why the Spreadsheet Access Review Fails
First, the data is wrong. A spreadsheet exported from the identity provider or individual SaaS admin consoles last week shows who had access last week — not who has it today. In a 200-person organization, 10–20 changes to access rights happen between export and review. Second, manager context is absent. A spreadsheet row showing "Jordan Lee — Salesforce — Full Admin" provides no context for whether Jordan's current role requires full admin access. Without context, managers approve to avoid the friction of investigating. Third, remediation is not verified. Marking a row "revoke" in a spreadsheet does not revoke access. Someone must action the revocation, and in manual processes, that action is frequently missed, delayed, or forgotten.
According to CloudNuro's 2026 access review benchmark, enterprises that integrated continuous user access review workflows into SaaS management platforms reduced access-related incidents by 48%, and access review-driven license optimization yielded an average of 28% annual SaaS cost savings for organizations with more than 1,000 cloud users. Both outcomes are only achievable when the review produces real revocations, not spreadsheet marks.
The orphaned account dimension adds urgency. With average workforce turnover running around 18% annually, an organization of 500 employees experiences roughly 90 departures per year. Each departure that is not fully automated produces orphaned accounts — SaaS access belonging to former employees — at a rate that manual processes cannot reliably clear. The ghost access security exposure these orphaned accounts create is significant: a former employee's credentials, still active in a CRM or cloud platform months after departure, represent both a data exfiltration risk and a direct SOC 2 finding.
A Six-Step Access Review Process That Actually Works
Not every application requires the same review frequency or scrutiny. Privileged access — admin rights, production database access, billing and payment system access — requires quarterly review because the blast radius of a compromised privileged account is highest. Standard business application access — productivity tools, project management, communication platforms — requires semi-annual review. Low-risk tools with no access to sensitive data require annual review. Defining these tiers before any review begins ensures that review effort is proportional to security risk rather than distributed uniformly across all applications regardless of sensitivity.
The scope definition also determines which applications are in scope for the current review cycle. A well-maintained software access catalog — covering all SaaS applications in use, their sensitivity classification, and the number of active users — is the prerequisite for a scoped review. Without it, the review defaults to whatever applications the reviewer happens to think of, systematically missing the long tail of SaaS applications that shadow IT discovery would surface. The shadow IT problem that creates review blind spots is addressed in Shadow IT: How to Find, Govern, and Secure Unauthorized Apps.
Access data for the review must be pulled directly from the identity provider or SaaS admin console at the time of the review, not from a spreadsheet that was exported at some prior point. The practical requirement is a software access catalog that maintains live synchronization with the identity provider — so that the access data available at review time reflects who actually has access today, not who had access when someone last ran an export. Last-login data is equally important: an account that has not been accessed in 90 days is a candidate for revocation regardless of whether the assigned user is still employed — it represents provisioned access that is no longer actively used, which is both a security risk and a wasted license.
The bottleneck in most access reviews is not pulling the data — it is getting managers to make real decisions rather than approving everything to clear their queue. According to Console's 2026 access review analysis, good access review tools send reviewers clear, specific prompts with enough context to make real decisions, not just approve-or-deny requests. Context that enables genuine decisions: the user's current department and role, the application access level (view only vs. full admin), the date of last login, and a flag if the access level exceeds what the user's current role typically requires. With this context, a manager can make a meaningful decision about whether full admin access to Salesforce is appropriate for a sales associate who last logged in four months ago.
Every account reviewed must produce a documented decision record — approved (access confirmed as appropriate), revoke (access to be removed), or downgrade (access level to be reduced). This record must capture: who made the decision, when, for which user, for which application, and what the decision was. The documentation exists to produce audit evidence — but more importantly, it creates the action list for Step 5. A review where 200 accounts are marked approved and 12 are marked for revocation must result in 12 actual revocations, not 12 spreadsheet marks. The decision record exists as the connection between the review and the remediation.
Every account flagged for revocation or downgrade must have a corresponding execution record showing that the revocation was actually performed — not just marked for action. Automated revocation workflows that fire when a revoke decision is recorded eliminate the manual follow-through gap that is the most common failure point in manual access review processes. For revocations that cannot be automated (applications without API-based access management), the execution record should be a completed ticket showing who performed the revocation, when, and confirming the account's post-revocation status. Auditors check remediation evidence. "Reviewed and identified for removal" without a corresponding revocation record is a finding.
The completed review produces an evidence report covering: review date and period, applications in scope, total accounts reviewed, decisions by category (approved/revoked/downgraded), revocation execution records with timestamps, and reviewer identities. This report is the evidence that SOC 2 CC6.3 and ISO 27001 A.5.9 require — structured, dated, linked to actual revocations, and produced from a process that clearly used current data. Organizations using automated access review workflows generate this report as a byproduct of the review process. Organizations using manual spreadsheet processes must assemble it from multiple sources — and the assembly itself introduces the risk of gaps.
Review Frequency and Scope by Risk Tier
| Access Tier | Examples | Review Frequency | Reviewer |
|---|---|---|---|
| Privileged / Admin | Root/admin accounts, production DB access, billing system admin, security tool admin | Quarterly | CISO / IT Director |
| Sensitive Business Systems | CRM, ERP, financial systems, HRIS, customer data platforms | Quarterly to Semi-annual | Application owner + department manager |
| Standard Business Applications | Productivity suites, project management, communication tools, design tools | Semi-annual | Department manager |
| Low-Sensitivity Tools | Documentation wikis, scheduling tools, analytics dashboards with public data | Annual | Department manager or IT |
ISO 27001 Annex A.9.2.5 specifies that privileged access rights must be reviewed more frequently than standard access rights. SOC 2 does not prescribe specific frequencies but auditors expect frequency to be risk-proportionate. Quarterly privileged access reviews are the standard expectation for SOC 2 Type II certification in SaaS environments.
The Dormant Account Priority
Regardless of tier, accounts with no login activity in 90 days should be flagged in every review cycle for potential revocation. Dormant accounts represent access that is no longer operationally necessary — the assigned user may have changed roles, switched to a different tool, or left the organization without triggering a proper offboarding. The security argument for revoking dormant access is straightforward: unused credentials cannot be compromised if they do not exist. The cost argument is equally direct: unused SaaS seats are wasted license spend. Both arguments point to the same action — systematic dormant account identification and revocation as part of every review cycle.
WorkVerge Software Access Visibility: How It Changes the Review Process
WorkVerge's Software Access Visibility module provides the per-employee, per-application access catalog that makes structured access reviews possible without spreadsheet exports — current data, decision workflows, and execution evidence all in the same platform.
- Live Access Catalog: WorkVerge maintains a continuously updated catalog of every employee's provisioned applications and licenses, synchronized with the identity provider. At review time, the data is current — not an export from last week. Every application entry shows the access level, last-login date, assigned license cost, and whether the application is IT-managed or shadow IT. The catalog makes scope definition straightforward: filter by application sensitivity classification, sort by last-login date, identify dormant accounts before any manual analysis is required.
- Manager Review Workflows: WorkVerge sends managers structured review requests for their direct reports' access — application by application, with the context that enables real decisions: current role, access level, last login, and an access-appropriate flag where the access level exceeds what the user's role typically requires. Managers click approve or flag for revocation directly in the workflow, producing a decision record automatically without requiring a separate documentation step.
- Shadow IT Detection: The access catalog surfaces applications that employees are accessing through SSO but that are not in IT's approved catalog — the shadow IT tools that manual access reviews systematically miss. These applications appear in the review queue for formal approval or revocation, bringing the full SaaS landscape into the review scope rather than only the applications IT already knows about.
- Revocation Execution and Verification: WorkVerge can execute access revocations directly for connected applications and records the execution with a timestamp — closing the gap between "flagged for removal" and "actually removed." For applications without direct revocation API support, a revocation ticket is created automatically, routed to the responsible IT team member, and tracked until completion.
- Evidence Export: The completed review produces a structured report showing review date, applications in scope, all decisions with reviewer identities and timestamps, and all revocation execution records. The evidence satisfies SOC 2 CC6.3 and ISO 27001 A.5.9 requirements directly — without any post-review assembly. For the full compliance context, see SOC 2 Compliance for IT Teams: What Asset Management and ITSM Must Cover.
Conclusion: Reviews Are Controls, Not Reports
The access review exists as a security control, not as a report that demonstrates compliance. A review that identifies over-provisioned and orphaned accounts and revokes them reduces attack surface, eliminates ghost access risk, and recovers wasted license spend. A review that identifies the same issues and marks them in a spreadsheet without revocation reduces none of those things — it just produces a document that could be confused for evidence of a control.
Building an access review process that functions as a genuine control — current data, context-informed decisions, verified revocations, structured evidence — requires more than spreadsheet discipline. It requires a software access catalog that stays current without manual maintenance, manager workflows that present decision context rather than requesting blind approvals, and automated revocation execution that closes the gap between decision and action. The compliance evidence that results is a byproduct of a process that actually works, not a simulation of one.