Why Quarterly Access Reviews Fail (and How to Fix It)

Every CTO reaches the same fork eventually: the quarterly access review has stopped being a formality and started eating a full week of someone's time, and the question is no longer "should we automate this" but "how." That's the real decision behind access review automation — not whether to keep using a spreadsheet forever, but whether to build the automation in-house with scripts against your identity provider's API, buy one of the dozens of commercial platforms now competing for this budget line, or stay manual a little longer because your entitlement graph genuinely doesn't justify either yet. Gart's compliance audit team gets asked to referee this exact decision more often than almost any other access-governance question, usually right after a failed or painfully expensive SOC 2 or ISO 27001 cycle. This guide is that referee call in writing: what each path — manual, build, and buy — actually costs in time, headcount, and risk; the commercial tool categories worth knowing before a vendor call; and a decision framework you can apply to your own organization without sitting through six demos first. The conversation usually starts after a failed or painfully expensive audit exposed how much of the IAM configuration nobody had actually reviewed in years. What Access Review Automation Actually Means Access review automation is the use of software — whether custom-built or purchased — to collect entitlement data, route certify-or-revoke decisions to the right owner, and log the resulting evidence, without a human manually exporting, emailing, and re-importing a spreadsheet each cycle. It's the mechanism; the underlying goal is unchanged from every identity framework's core idea, NIST's principle of least privilege — that every account should hold only the access it currently needs, no more. The "automation" part isn't all-or-nothing. Most mature programs automate data collection and evidence capture fully, automate routing and reminders almost completely, and keep the actual certify-or-revoke judgment call with a human reviewer — the tooling narrows what a person has to look at, rather than replacing the decision itself. We covered that workflow distinction in detail in how to run a user access review without spreadsheets; this article picks up from there to answer the question that guide doesn't: which delivery model gets you to that workflow fastest for your specific situation. The Three Paths: Manual, Build, or Buy Every organization automating access reviews chooses, deliberately or by default, between three approaches. None of them is universally correct, and the right one depends far more on entitlement complexity and available engineering capacity than on company size alone: Manual — spreadsheets, shared docs, or email threads, run by a person who owns the process end to end. Cheapest to start, most expensive to sustain past a certain scale. Build — scripts and internal tooling written against your identity provider's API (Okta, Entra ID, Google Workspace, AWS IAM) that automate collection, routing, and evidence capture without buying a dedicated product. Buy — a commercial platform, ranging from a lightweight access-certification tool to a full enterprise identity governance and administration (IGA) suite, that provides the workflow, evidence trail, and integrations out of the box. The rest of this guide breaks down what each path actually requires and where it tends to fail, so the decision isn't made on a vendor's pitch deck alone. Staying Manual: When It Still Works (and When It Doesn't) Manual reviews aren't automatically wrong. For a genuinely small entitlement footprint — a handful of systems, a headcount under roughly 150, and a first-time compliance audit — a well-structured spreadsheet process, run with discipline, can pass a SOC 2 or ISO 27001 review without a platform purchase. The mistake isn't staying manual early; it's staying manual past the point where the process can no longer keep up, which research from Secureframe's access review benchmarking puts at a full review cycle averaging 149 days manually versus 55 days once automated — nearly a hundred extra days per cycle spent chasing sign-offs instead of running the business. ⚠️ The break point is roughly 500 employees or 100 applications Past that rough threshold, the number of entitlements to cross-reference exceeds what any one person can track reliably inside a review window, and the same failure modes show up in nearly every organization we audit: stale snapshots, no single source of truth once the file is emailed around, and reviewers defaulting to "approve all" because a raw permission list carries no usage context to judge by. If that describes your organization today, the deeper mechanics of what breaks and the exact process fix are in our companion guide on running a user access review without spreadsheets. What this article adds is the next decision: once you've decided manual is no longer sustainable, do you build the automation yourselves or buy it? Building Your Own Access Review Automation Building in-house is genuinely the right call for some organizations — typically ones with a narrow, stable set of systems, an identity provider with a solid API, and spare platform engineering capacity that isn't fighting fires elsewhere. A first version is often just a scheduled script that pulls group memberships from your SSO provider, drops them into a lightweight workflow tool for manager sign-off, and logs the decision to a database instead of a spreadsheet tab. That can realistically ship in a few weeks. What rarely gets budgeted honestly is what happens after v1 ships. A sustained in-house access review system needs ongoing coverage across roughly five distinct functions: the software engineering to build and extend it, operations to keep the integrations running as each connected system changes its API, security expertise to get the risk logic right, user support for the managers stuck on the workflow, and someone who actually understands the entitlement domain well enough to keep the automation meaningful rather than mechanical. None of that shows up as a single line item — it's absorbed into the engineering backlog, which is exactly why "build" often looks free in the planning meeting and expensive eighteen months later. API coverage for every connected system — not just your primary IdP. Shadow SaaS and systems outside SSO are usually where the build scope quietly triples. A workflow and notification layer — routing, reminders, and escalations that someone has to design, not just the data pull. An evidence store an auditor will accept — timestamped, queryable records of reviewer, decision, and action, not a log file nobody's tested against a real audit request. A maintenance owner named today — the person who updates the integration when Okta or Entra ID changes an API, not "whoever's free." A plan for scope creep — new compliance frameworks, new subsidiaries, new systems all expand what the in-house tool needs to cover, indefinitely. None of this rules out building — plenty of engineering-heavy organizations run this well. It rules out building without naming, up front, who owns it in twelve months. Buying a Commercial Platform: The Three Tool Categories "Buy" isn't one category of product — it's at least three, and conflating them is the single most common mistake we see in vendor selection. Compliance evidence platforms, lightweight access-certification tools, and full enterprise IGA suites solve overlapping but distinct problems, and picking the wrong one for your actual entitlement complexity means either overpaying for capability you don't need or under-buying and hitting the same wall in eighteen months. CategoryWhat it actually doesTypical time to valueWatch out forCompliance evidence platforms (e.g., Vanta, Drata, Secureframe)Document that reviews happened and collect audit evidence; often layered on top of another system that does the actual review workflowWeeksProves reviews occurred — doesn't necessarily automate the certify/revoke decision itselfLightweight access-certification tools (e.g., Zluri, AccessOwl, Cakewalk, SecurEnds, Clarity Security)Run the actual review workflow — collect entitlements from connected SaaS apps, route certifications, execute revocations1-2 weeksDiscovery usually runs through your IdP, so apps outside SSO can stay invisible — ask vendors directly how they cover non-SSO and non-employee identitiesEnterprise IGA suites (e.g., SailPoint, Okta Identity Governance, Saviynt)Full lifecycle governance — birthright provisioning, role modeling, separation-of-duties enforcement, deep on-prem and cloud coverage6-12 months, often longer with legacy platformsProfessional services costs can match or exceed the license fee; confirm before signing whether implementation is vendor-led or self-serveBuying a Commercial Platform: The Three Tool Categories A useful shortcut when evaluating any of the three: ask what percentage of your actual entitlement landscape the tool discovers on day one without custom integration work. Platforms that lean entirely on IdP-based discovery routinely cover only 30-40% of a real SaaS footprint, leaving contractors, vendors, and service accounts as an unreviewed blind spot that shows up as an audit finding later. One "buy" scenario deserves a special note: if you're already a Microsoft 365 E5 customer, the build-vs-buy math often changes entirely, because a meaningful share of enterprises already own Entra ID Governance access reviews as part of their existing license and simply haven't turned them on. Our Entra ID Governance vs. manual access reviews cost breakdown walks through the exact licensing math before you evaluate a third-party purchase. Which Approach Fits Your Organization There's no formula that replaces a proper assessment of your own entitlement graph, but the pattern below reflects what actually tends to work across the engagements we run, and it lines up with ISACA's guidance on structuring access review verification around risk-based triggers rather than a one-size cadence: Your situationRecommended pathUnder ~150 employees, a handful of systems, first SOC 2 or ISO 27001 cycleStay manual, but structured — or layer a compliance evidence platform on top to shorten audit prep without a full workflow buy yet150-1,000 employees, cloud/SaaS-heavy stack, entitlement volume still trackableBuy a lightweight access-certification tool — fastest path to real automation without enterprise IGA cost or timelineDeep in-house platform engineering capacity, narrow and stable system listBuild — with a named long-term owner and budget for the five functions above, reviewed annually against whether buying now makes more sense1,000+ employees, hybrid on-prem/cloud, multiple overlapping frameworks (SOX, SOC 2, ISO 27001), M&A-driven entitlement sprawlBuy an enterprise IGA suite — the role modeling and separation-of-duties enforcement earn their cost at this complexityNeed audit-ready evidence now while still deciding on a long-term platformLayer a compliance evidence platform in immediately; run the build-vs-buy evaluation for the workflow layer in parallel, not sequentiallyWhich Approach Fits Your Organization Hidden Costs Nobody Puts in the Pitch Deck Whichever path you're leaning toward, a handful of costs consistently get left out of the initial comparison, and they're usually what turns a confident decision into a regretted one a year later: 💸 SOC 2's own criteria don't specify a tool — only evidenceThe AICPA's Trust Services Criteria (CC6.1-CC6.3) require documented, periodic review of logical access with evidence of the decision and any resulting removal — they don't mandate a specific product. That means a manual process, a build, or any of the three buy categories above can all satisfy the letter of the requirement; the real differentiator is whether the evidence is trustworthy and reproducible under audit pressure, not which logo is on the invoice. The same logic holds for more prescriptive frameworks like PCI DSS, whose own access-review requirements care about the control, not the vendor enforcing it. Beyond that, watch for: integration costs that don't show up in the license quote (custom connectors for internal or legacy systems usually cost extra, on either the build or buy path); the "shelf-ware" risk of buying enterprise IGA capability you don't yet have the process maturity to use, which is common when the tool purchase happens before the workflow is actually defined; and the reverse risk on the build side engineering time that was supposed to be temporary becoming a permanent, unbudgeted maintenance line as soon as the first integration breaks during a platform migration elsewhere in the company. Access Governance & Compliance Audit Not sure whether to build, buy, or wait? Gart Solutions runs a vendor-neutral assessment of your entitlement landscape — every system, every identity type, every framework you're accountable to — and gives you a straight recommendation on whether to automate in-house, adopt a lightweight access-review tool, or invest in enterprise IGA, before you sit through a single vendor demo. IT Audit Services Compliance Audit Security Audit Infrastructure Audit DevSecOps Consulting IT Infrastructure Consulting Talk to an audit specialist You might also like Why Quarterly Access Reviews Fail (and How to Fix It) Least-Privilege Access: A Practical Playbook for Lean IT Teams The Real Cost of a Failed SOC 2 Audit (and How to Avoid One) IT Infrastructure Audit Checklist: Signs You Need a Checkup IT Audit Services Overview Roman Burdiuzha Co-founder & CTO, Gart Solutions · Cloud Architecture Expert Roman has 15+ years of experience in DevOps and cloud architecture, with prior leadership roles at SoftServe and lifecell Ukraine. He co-founded Gart Solutions, where he leads cloud transformation and infrastructure modernization engagements across Europe and North America. In one recent client engagement, Gart reduced infrastructure waste by 38% through consolidating idle resources and introducing usage-aware automation. Read more on Startup Weekly.

Every audit season, the same file resurfaces: a bloated spreadsheet with one tab per system, colored cells for "approved," and a manager who hasn't opened it since the last audit. Learning how to run a user access review without spreadsheets isn't about finding a fancier template — it's about replacing a process that was never designed to scale past a handful of systems and a few dozen employees. If you're the one chasing down sign-offs every quarter, or the one explaining to an auditor why three ex-employees still show "active" in a system nobody remembers to check, Gart's compliance audit team sees this exact bottleneck across almost every engagement — and it's fixable without buying an enterprise IGA platform on day one. This guide walks through why spreadsheet-based reviews break down, what a modern access review process looks like instead, how often to run one by risk tier, and where to draw the line between what should be automated and what still needs a human decision. Result: hours per cycle, reviewers only see what changed, audit trail is a byproduct — not a scramble.The spreadsheet version isn't just slower — it's stale the moment it's filed. The automated version keeps its own audit trail as a side effect of running. What a User Access Review Actually Checks A user access review is the process of confirming, system by system and person by person, that everyone's current access still matches their current job — no more, no less. In practice that means pulling every account, role, and permission across your critical systems, matching each one against the person's actual responsibilities today (not the responsibilities they had when the access was granted), and making an explicit decision for every entry: keep it, downgrade it, or revoke it. The review exists to catch three specific failure modes that accumulate quietly in any growing organization: privilege creep (employees who change roles but keep accumulating old permissions instead of shedding them), orphaned accounts (access left active after someone leaves or a contractor's engagement ends), and excess standing access (admin-level permissions granted for a one-time task and never revoked). None of these show up as an incident on their own — they're the precondition that turns a single stolen password into a much larger breach, which is exactly why Verizon's 2026 Data Breach Investigations Report puts the number of corporate users reusing an already-exposed password at roughly four in ten — access reviews are one of the few controls that catch the damage before that reused password becomes a working credential inside your systems. Why Spreadsheet-Based Access Reviews Break Down Spreadsheets aren't a bad tool for a five-person startup with three SaaS logins. They become a liability at a very specific, predictable point: once the number of systems, users, and role changes exceeds what one person can manually cross-reference inside a review window. Past that point, the same problems show up in almost every organization we audit: 📉 The review becomes a snapshot of last quarter, not this oneExporting access into a spreadsheet freezes it at the moment of export. Every role change, offboarding, or new hire that happens during the two-to-four weeks it takes to collect sign-offs is invisible to the review — which means the "completed" review is already out of date before anyone files it. Beyond staleness, three more issues compound: there's no single source of truth once the file is emailed to five different managers, each keeping their own copy; there's no reliable evidence trail showing who actually reviewed which row and when, which is precisely what a security audit or SOC 2 assessor asks to see; and reviewers default to rubber-stamping "approve all" on long lists because reading 400 rows of raw permission names with no context about actual usage is not a task a manager can realistically do well in the fifteen minutes they've allotted for it. How to Run a User Access Review Without Spreadsheets: Step by Step Removing the spreadsheet doesn't require ripping out your entire identity stack on day one. It means restructuring the process so data collection, routing, and evidence capture happen automatically, and the only manual step left is the actual judgment call a human has to make anyway. Inventory every system that holds an access decision. Start with a real list — cloud consoles, source control, CI/CD, databases, SaaS admin panels, VPN, and any internal tooling with role-based permissions. Most organizations underestimate this list by half; shadow SaaS and forgotten admin panels are where stale access hides longest. Pull entitlement data directly from each system's API or SSO provider, not a manual export. Most identity providers (Okta, Entra ID, Google Workspace) and major cloud platforms expose an API or a native access-review feature that reads current group membership and role assignments in real time, eliminating the export-then-email step entirely. Route each access decision to the person who actually knows the answer. A centralized IT team rarely knows whether a specific engineer still needs production database access — their manager or the system owner does. Automated routing sends each reviewer only the entitlements they're actually qualified to judge, instead of one giant undifferentiated list. Surface usage data alongside each entitlement, not just the permission name. "Has write access to the billing database" is hard to judge in isolation. "Has write access to the billing database, last used 214 days ago" makes the decision almost automatic — this single change is what turns a rubber-stamp exercise into a real review. Auto-approve birthright access, and only surface exceptions and changes since the last cycle. If someone's access was already reviewed and hasn't changed, re-certifying it from scratch every quarter is wasted reviewer attention. Mature programs certify only what's new, changed, or flagged as anomalous — role outliers, separation-of-duties conflicts, dormant accounts, and access that doesn't match the person's department. Capture the decision, the reviewer, and the timestamp automatically, in the same system. This is the evidence an auditor asks for — not a policy document saying reviews happen, but a record of the specific decision made on a specific entitlement by a specific person on a specific date. Execute revocations immediately, and verify they took effect. A "revoke" decision that sits in a spreadsheet for two weeks before IT actions it is functionally the same as no decision at all. Closing the loop — confirming the access was actually removed — is the step most manual processes skip. None of these steps require a full identity governance platform to start. Many teams begin with scripts against their SSO provider's API and a lightweight workflow tool, then graduate to a dedicated access-review or IGA product once the entitlement volume justifies it. What matters is removing the manual export-email-chase cycle, not which specific tool replaces it — Gart's infrastructure audit engagements typically start by mapping exactly this: which systems can already feed a review automatically, and which still need the plumbing built. How Often to Review Access, by Risk Tier Review frequency isn't one-size-fits-all, and treating every system on the same quarterly calendar wastes reviewer attention on low-risk access while under-reviewing the accounts that matter most. Risk-based cadence is also what most frameworks actually expect once you read past the headline "periodic review" language in NIST SP 800-53's AC-2 account management control, which leaves the exact interval to the organization's own risk determination rather than mandating a fixed number. Access tierRecommended cadenceTypical spreadsheet failure modePrivileged / admin (root, domain admin, production DB write)Monthly, or continuous with automated flagsAdmin lists go stale fastest; a single missed cycle can leave standing root access unreviewed for a full quarterStandard business systems (CRM, finance tools, internal apps)QuarterlyLargest row count, most likely to get "approve all" treatment under time pressureService accounts & API keysQuarterly, with automated dormancy alertsNo human owner to chase for sign-off, so these are the rows most often skipped entirelyLow-risk / read-only (internal wikis, reporting dashboards)Semi-annual to annualRarely the actual risk, but often consumes disproportionate review time on a flat spreadsheet What to Automate vs. What Still Needs a Human Removing spreadsheets doesn't mean removing judgment — it means reserving human attention for the decisions that actually need it, and letting the process handle everything else. A well-built review workflow should automate: Data collection and formatting. Pulling current entitlements from every system and normalizing them into one reviewable list — the part spreadsheets require someone to do by hand every single cycle. Routing and reminders. Sending each entitlement to the correct reviewer automatically and escalating overdue items, rather than one person manually emailing and re-emailing managers. Evidence capture. Logging who decided what, and when, in a format an auditor can query directly instead of a screenshot of a spreadsheet tab. Anomaly flagging. Surfacing separation-of-duties conflicts, dormant accounts, and role outliers automatically, so reviewers spend their time on the entries that are actually unusual. What should stay human: the actual certify-or-revoke decision on any entitlement flagged as an exception, sign-off from the system owner who understands business context a script can't infer, and the judgment call on ambiguous cases — a contractor whose engagement was extended verbally but not yet in the HR system, for example. Automation should narrow what a human has to look at, not replace the look itself. How Access Reviews Map to SOC 2, ISO 27001, and NIS2 Every major security framework requires some form of periodic access review — the specific language differs, but auditors are checking for the same underlying evidence: a documented, repeatable process with named reviewers, dated decisions, and proof that revocations were actually executed. Microsoft's Entra ID Governance documentation frames this well as confirming that "the right people have the right access to the right resources" on an ongoing basis — a vendor-neutral definition that maps cleanly onto every framework below, regardless of which tooling actually runs the review. FrameworkWhat it expects from access reviewsSOC 2Trust Services Criteria CC6.1-CC6.3 require restricting logical access to authorized personnel and demonstrating periodic review of that access, with evidence of both the review and any resulting removalsISO/IEC 27001Annex A access control clauses require documented, periodic review of user access rights, tied to the organization's own risk assessment rather than a fixed universal intervalNIS2 (EU)Requires access control and identity management as part of baseline cyber-hygiene measures for in-scope entities, typically implemented by mapping to ISO 27001/27002 controls — see Gart's NIS2 compliance overview for how this applies beyond obviously regulated sectorsPCI DSS / HIPAABoth mandate documented periodic review of user access to cardholder data or protected health information, typically at minimum every six months for standard access and more frequently for privileged accounts The consistent thread across every framework: a policy stating that access reviews happen is not evidence. Auditors ask for the actual review — reviewer name, date, decision, and the resulting action — which is exactly what a spreadsheet struggles to preserve reliably across cycles and what an automated process generates as a natural byproduct of running. Where Access Review Projects Go Wrong Most failed access-review programs don't fail because a tool was missing — they fail on process and ownership problems that a new platform alone won't fix: No clear owner per system. If it's unclear whose job it is to review a given system's access, the review either doesn't happen or defaults to IT rubber-stamping decisions they don't have the business context to make. Reviewing everything with equal weight. Treating a read-only wiki account the same as a production database admin role burns reviewer attention on low-risk items and increases the odds that high-risk access gets the same fifteen-second glance. Automating collection but not remediation. Some teams automate the data pull and routing, then let "revoke" decisions sit in a ticket queue for weeks. The review only reduces risk once the access is actually removed and that removal is verified. Treating the review as a compliance checkbox rather than a security control. Programs built purely to satisfy an auditor tend to under-invest in the parts — usage data, anomaly flags — that make the review actually catch something. Gart's SOC 2 preparation guide covers this distinction in more depth: passing the audit and reducing real access risk are related but not identical goals. Access Governance & Compliance Audit Still running access reviews out of a spreadsheet? Gart Solutions audits your current access review process, maps every system that needs to feed it, and designs the automated workflow — API-driven entitlement collection, risk-based routing, and audit-ready evidence capture — so your next SOC 2, ISO 27001, or NIS2 review is a formality instead of a fire drill. IT Audit Services Compliance Audit Security Audit Infrastructure Audit DevSecOps Consulting IT Infrastructure Consulting Talk to an audit specialist Explore our IT audit services → Roman Burdiuzha Co-founder & CTO, Gart Solutions · Cloud Architecture Expert Roman has 15+ years of experience in DevOps and cloud architecture, with prior leadership roles at SoftServe and lifecell Ukraine. He co-founded Gart Solutions, where he leads cloud transformation and infrastructure modernization engagements across Europe and North America. In one recent client engagement, Gart reduced infrastructure waste by 38% through consolidating idle resources and introducing usage-aware automation. Read more on Startup Weekly.