From Spreadsheets to Continuous Certification: A 90-Day Access Review Transformation Plan

Every quarter, the ritual plays out the same way. Someone exports tens of thousands of rows of entitlements into a spreadsheet, emails it to a hundred managers, and waits. ^[1] The managers, already buried in other deadlines, do the only rational thing: Select All -> Approve. The spreadsheet comes back 95% green. The compliance box gets checked. And nothing actually changed.

This isn't a people problem. It's a structural one - and it's getting harder to hide from auditors.

In a 2024 SailPoint survey, 58% of identity leaders reported their access reviews were ineffective, while 42% said reviewers lacked the context to make informed decisions. ^[2] That's not a governance program. That's governance theater.

The good news: you don't need a 12-month transformation project to fix it. A focused 90-day plan - built around three phases - can take you from manual spreadsheet chaos to continuous, evidence-generating certification that actually satisfies a 2026 auditor. Here's exactly how.

---

Why Spreadsheet Reviews Fail (And Why Auditors Are Noticing)

Before the plan, it's worth being precise about why the current approach breaks down. There are four structural failures, not one.

1. They're point-in-time - stale before the ink dries

A spreadsheet captures a moment in time and immediately becomes outdated. In SaaS environments, access changes continuously. ^[3] The moment you export the data, someone gets promoted, a contractor's project ends, or a developer gets added to a sensitive repo. By the time reviewers finish certifying, the dataset no longer reflects reality. Reviewers are signing off on a ghost.

2. They produce rubber stamps, not decisions

Studies consistently show that reviewers approve over 95% of access during certification campaigns, with the average reviewer spending fewer than 10 seconds per decision. ^[1] When a manager faces 200 entitlement rows with no usage data, no peer comparison, and no risk context, they can't make a meaningful decision. So they don't. They approve everything to meet the deadline. ^[4] The result is a certification that satisfies a completion metric while doing nothing to reduce actual access risk.

3. They miss the non-SCIM long tail - where the real risk hides

Most IGA tools govern the apps that speak SCIM. But fewer than 7% of applications support SCIM, meaning the vast majority of your stack - Notion, Figma, Linear, internal tools, legacy systems - falls outside automated governance entirely. ^[5] Those apps get managed through flat-file uploads, shared admin consoles, and quarterly spreadsheets that nobody trusts. ^[6] That's where orphaned accounts accumulate and audit findings land.

4. They produce weak evidence

Spreadsheets can show that someone clicked "approve" - but they cannot prove that systems actually enforced those changes. ^[3] There's no immutable timestamp, no remediation trail, no link between the decision and the downstream action. In 2026, auditors increasingly expect organizations to prove that access governance processes are continuous, documented, and enforceable - and point-in-time evidence gathering is no longer sufficient for most audit engagements. ^[7] A spreadsheet with a 96% approval rate is not that proof.

---

The 90-Day Plan

The three phases below are sequenced deliberately. You can't certify what you can't see. You can't automate what you haven't defined. And you can't go continuous until you've proven the periodic model works.

Phase 1: Days 0-30 - Build a Complete Entitlement Inventory

You cannot certify access you don't know exists. The first 30 days are entirely about visibility - and critically, universal visibility, not just the SCIM-friendly slice of your stack.

What to do:

• Connect your identity sources. Pull from your HRIS and IdP to establish a single source of truth for who exists, what their role is, and when they joined, moved, or left.
• Inventory every app - not just SCIM apps. Map your full application estate: SCIM-connected apps, API-connected apps, and the long tail that supports neither. This is the step most teams skip, and it's where the audit findings live. Fewer than 4% of organizations have fully automated their core identity workflows, with the remaining 96% dependent on human-centric processes that are difficult to scale and prone to error. ^[8] The non-SCIM apps in that gap are your highest-risk blind spots.
• Normalize entitlements. Raw entitlement exports from SaaS apps are often technical identifiers that business reviewers can't interpret. Translate them into human-readable descriptions with risk classifications before any review begins.
• Assign owners. Every app needs an owner - either a technical app owner or a business data owner - who will be accountable for certifying access. Don't default everything to direct managers; a marketing manager cannot meaningfully review database entitlements.

What to measure:

• Total apps in scope vs. apps with active governance coverage
• % of entitlements normalized and risk-classified
• % of apps with a named, confirmed owner

Common pitfall: Teams that stop at their SSO-connected apps declare victory at 30-40% coverage. ^[9] The other 60-70% - the tools your engineering, finance, and ops teams use daily - remain ungoverned. That's where the next breach or audit finding is waiting.

---

Phase 2: Days 31-60 - Define Campaigns, Automate Workflows, Capture Evidence

With a complete entitlement inventory in hand, you can run your first structured certification campaigns. The goal here is not perfection - it's replacing the spreadsheet ritual with a repeatable, evidence-generating process.

What to do:

• Tier your reviews by risk. Not all access deserves the same review frequency. Privileged access, admin roles, and access to sensitive data should run monthly or on every role change. Standard SaaS access can run quarterly. Low-risk, read-only access can run semi-annually. ^[10] Matching frequency to actual risk is what separates governance from compliance theater.
• Automate reviewer workflows. Route campaigns to the right reviewer - app owner for technical entitlements, data owner for sensitive data, manager for standard access - with pre-populated context: when access was granted, last-used date, peer comparison, and risk flag. This is the single most effective way to prevent rubber-stamping. ^[1]
• Capture immutable sign-off evidence. Every decision - approve, revoke, escalate - must be timestamped, attributed, and stored in an immutable audit log. The decision and the downstream enforcement action must be linked. ^[11] Auditors need to verify who reviewed access, what decisions were made, when certifications were completed, and whether rejected access was actually remediated.
• Start handling movers. Role changes are one of the most common sources of privilege creep. When someone moves from engineering to sales, their GitHub repo access shouldn't follow them. Build mover workflows that trigger a targeted re-certification of changed entitlements within 48 hours of an HRIS update.

What to measure:

• Campaign completion rate (target: >95%)
• Average time-per-decision (flag reviewers spending <5 seconds per item)
• Revocation rate (a healthy program revokes 5-15% of reviewed access)
• Time from revocation decision to enforcement in target system

Common pitfall: Reviewer fatigue. Over 75% of organizations admit that rubber-stamping is a significant problem in their access review processes. ^[1] The antidote is not more reminders - it's smaller batches, better context, and surfacing only the anomalies that actually need a human decision. Limit review sessions to 10-15 items. Flag the outliers. Let automation handle the obvious approvals.

---

Phase 3: Days 61-90 - Shift to Continuous, Event-Driven Certification

Periodic campaigns are a floor, not a ceiling. The goal of Phase 3 is to move from scheduled reviews to event-driven certification - where access is re-evaluated whenever something meaningful changes, not just when the calendar says so.

What to do:

• Trigger certifications on identity events. A new hire, a role change, a project completion, a contractor's contract end date - each of these should automatically trigger a targeted certification of the affected entitlements. This eliminates the gap between review cycles where privilege creep accumulates silently.
• Auto-remediate revocations. When a reviewer revokes access, the enforcement action should happen automatically and immediately - not via a ticket that sits in a queue for three days. For apps with direct connectors, this means real-time deprovisioning. For non-SCIM apps, it means an automated workflow that executes the change and logs the result.
• Generate audit-ready reports on demand. By Day 90, you should be able to answer "who has access to what, and since when?" in minutes - not weeks. ^[11] Your audit evidence package should include: a complete entitlement inventory with timestamps, a campaign history showing every review decision and its outcome, a remediation log linking decisions to enforcement actions, and an exception register for any access that was approved despite risk flags.
• Close the non-SCIM loop. Continuous certification only works if it covers your full stack. For apps without SCIM or APIs, this means using a platform with universal connector coverage - one that can govern Notion, Figma, Linear, and your internal tools with the same rigor as Okta-connected apps.

What to measure:

• Mean time from identity event to certification completion (target: <48 hours for high-risk, <7 days for standard)
• % of revocations auto-remediated vs. manually ticketed
• Orphaned account count (should trend toward zero)
• Audit evidence retrieval time (target: <30 minutes for any requested artifact)

Common pitfall: Declaring continuous certification "done" while the non-SCIM long tail remains on spreadsheets. ^[5] The apps that don't support identity standards aren't an edge case - they're a permanent liability. Their resistance to automation creates the governance gaps that show up in breach investigations and audit findings, often long after access should have been removed.

---

What Good Looks Like at Day 90

After 90 days, a mature program looks like this:

---

The 90-Day Checklist

---

The Underlying Problem Most Plans Don't Solve

There's one reason most 90-day plans stall at Phase 2: they only govern the apps their IGA platform can reach. If your platform stops at SCIM, you've automated governance for a fraction of your stack and left the rest on spreadsheets - which means you've built a continuous certification program with a 60-70% coverage gap baked in.

The frameworks don't give you partial credit. Regulatory compliance frameworks including SOX, HIPAA, GDPR, ISO 27001, NIS2, and DORA mandate continuous, periodic, and well-documented access reviews. ^[12] An auditor asking "who has access to your financial data?" doesn't accept "we govern the SCIM apps" as an answer. They want the full picture - including the tools your finance team uses that never built a provisioning API.

That's the gap Iden was built to close. Universal connector coverage - SCIM, API, or neither - means your continuous certification program actually covers your continuous risk. Not just the easy 30%.

If you're building toward your next SOC 2 Type II, ISO 27001 surveillance audit, or DORA compliance deadline, the 90-day plan above gives you the structure. The question is whether your tooling can execute it across your entire stack.