First time running access reviews? Start with our User Access Review Process: 5 Key Steps guide. This article is for organizations that have completed their first 1-3 reviews and are ready to scale, handle complexity, and optimize their process.
Beyond the First Access Reviews
You've done your first access review. It took three weeks, involved two dozen people, and revealed dozens of apps you didn't know existed. You've done your second. Same three weeks, same coordination chaos, same apps reappearing outside your scope.
Now you're staring at Q3, and the question isn't "how do I run a review." You know the steps. The question is whether this is sustainable every quarter without burning out your team.
The numbers say most teams are stuck here. In our survey of 215 security and IT leaders, 38% spend five to seven days on every review cycle, 43% of fully manual organizations pull 21 to 50 people into each one, and 41% of manual organizations regularly overshoot their deadlines. You've proven you can execute user access reviews. Now you need to evolve them from painful quarterly events into efficient, scalable governance. In this guide, we cover how: expanding coverage, cutting effort per cycle, handling the edge cases that break basic workflows, and building remediation that actually closes violations.
Why Your Current Process Is Breaking
Most organizations hit the same wall after two or three cycles. The problem isn't execution. It's foundation: you're scaling a process built on incomplete visibility, manual coordination, and hope-based remediation.
The visibility gap compounds every cycle. Your first review covered the apps in your IdP and felt complete. Then finance data and broader discovery methods revealed the real footprint: typically close to double what the IdP shows. If you're still doing quarterly exports, apps adopted in week two of the quarter stay unmanaged until week thirteen.
Remediation delays create accumulating debt. Q1 identifies violations; tickets go out to each app's owner. By Q2, dozens are still "in progress," and Q2 adds its own. The backlog compounds until reviews are re-certifying access that a previous review already denied.
Approval fatigue destroys accuracy at scale. In the first review, managers evaluate carefully. By the third, approval rates creep upward because reviewers have stopped reading: 500 decisions with zero context about usage, risk, or role fit makes "approve all" the rational move. The confidence data reflects it: 49% of manual-process leaders say their policies are enforced very effectively, versus 68% of leaders with fully automated reviews.
The 7-Phase Advanced Review Model
This framework integrates discovery, intelligence, routing, and remediation into one process. You don't need all seven phases at once; most organizations start with visibility, scoping, and remediation (Phases 1, 2, and 6), then layer in intelligence and automation. Modern access review platforms like Zluri provide these capabilities out of the box, so the work is choosing what to enable, not building it.
Phase 1: Continuous multi-method discovery with reconciliation
Basic reviews export the IdP before each cycle. Advanced reviews run discovery continuously across multiple methods, because each method sees what the others miss:
These are the same eight sources Zluri's discovery engine runs simultaneously, with CSV import layered on top for the legacy systems nothing else can reach.
Multiple sources will disagree about the same app: your SSO shows 487 Slack users, the Slack API shows 523, finance shows 500 licenses. All are correct for different questions, so establish a hierarchy of truth per question. The app's own API answers "who should we review" (actual accounts). SSO answers "who is authorized." Usage detection answers "who actually uses it." Finance answers "who is paying."
Then classify every gap the comparison exposes:
- In the API but not SSO: shadow access; review immediately
- In SSO but not the API: provisioned but never activated; cleanup opportunity
- More licenses than users: wasted spend
- More users than licenses: a compliance problem with the vendor
Platforms run this reconciliation daily, normalize identities across sources (john.smith@ versus jsmith@), apply a grace period for source lag, and maintain a registry for legitimate exceptions like shared and service accounts.
Two disciplines keep discovery from backfiring: don't try to govern all 200 discovered apps at once (that's what Phase 2 scoping is for), and maintain exclusion rules so personal-domain noise doesn't flood the review queue.
Done right: near-complete application coverage, new apps surfaced within 48 hours, reconciliation automated with exceptions documented.
Phase 2: Risk-based scoping with dynamic classification
Most reviews either cover everything (overwhelming) or hand-pick 20 apps (incomplete). Classify instead, and let the tier set the frequency:
Layer event-driven reviews on top, regardless of tier: termination triggers immediate review, role change within five business days, contractor project completion within ten days, a security incident or privilege escalation immediately.
Three discipline rules. Keep Critical under roughly 15% of your landscape or quarterly cycles collapse under their own weight. Inherit criticality: an app that receives data from a Critical app is at least High. And reclassify quarterly; a tiering done once is a tiering that drifts.
Done right: roughly 40% less review workload, with effort concentrated where the risk is and low-risk apps monitored instead of manually certified.
Phase 3: Distributed ownership with intelligent routing
Basic reviews assign one owner to everything. Advanced reviews route each decision to the person with authority and context:
Routing needs a fallback chain, because managers leave: direct manager, then manager's manager, then department head, then a default reviewer, with daily HRMS sync so the chain reflects reality. Set SLAs (manager reviews in seven days, security reviews in three) with auto-escalation on misses, and cap any single owner's queue by distributing app ownership before one person receives 500 items. For the four workable models of splitting review work without diluting accountability, see our guide to access review delegation.
Done right: per-reviewer workload drops sharply, decision quality rises because deciders have context, and IT stops being the bottleneck.
Phase 4: Context-rich review intelligence
Basic reviews present user, app, last login. That interface guarantees rubber-stamping. Advanced reviews layer intelligence onto every line:
Core data: identity and employment status, permission level, grant date, last activity, license type and cost.
Behavioral intelligence: usage classification (daily active through dormant through never-used), risk scoring (external admin with financial data access ranks Critical), cost analysis (dormant license equals wasted spend), and peer comparison ("2 of 15 Marketing Manager peers have admin" flags an outlier; "8 of 12 have it" signals normal).
The difference on one review line: instead of "John Smith, Salesforce, last login 15 days ago, approve or revoke," the reviewer sees an active marketing manager holding admin that only 2 of 15 peers hold, with a recommendation to downgrade rather than revoke, because usage shows real need but admin exceeds the role. The decision becomes obvious in seconds.
Two quality controls matter: flag unreliable data sources in the interface (some apps return poor login data, and a false "dormant" label destroys reviewer trust), and allow documented overrides when a reviewer knows better than the data.
Done right: seconds per decision instead of a minute, approval accuracy up, false positives down sharply.
Phase 5: Bulk operations and intelligent automation
Nobody should click approve 500 times. Split the queue by confidence.
Auto-approve when every condition holds: active employee, logged in within 30 days, standard (non-admin) permission, access matches peer patterns, no anomalies. Log the criteria with each auto-approval and send reviewers a summary they can inspect.
Flag for human review when any condition trips: dormant 90+ days, admin or elevated permissions, external user or contractor, access unusual for the role, granted within the last 30 days, policy violation, or high-risk app with sensitive data.
Bulk actions then handle the patterns humans do decide: approve all active standard users in a group, revoke dormant accounts across productivity apps, downgrade a team's admin rights with named exceptions, and request justification from all external contractors. Guard them with three safeguards: a preview of exactly what will execute, explicit typed confirmation, and default scoping to the current context so one click can't fan out across 50 apps.
Calibrate thresholds empirically: start conservative, measure the false-approval rate over two cycles, target under 2%, and loosen or tighten from there.
Done right: a review that took four hours takes under one; roughly 70% of items auto-approve safely and humans spend their judgment on the 30% that need it.
Phase 6: Integrated remediation with proof of completion
Basic reviews export denials and hope. Advanced reviews run closed-loop remediation: the platform that captured the decision executes it, verifies it, and evidences it. This phase matters most; in our survey, modifying access app by app after the review ranked as the second-biggest challenge overall, and remediation is the least-automated step even among organizations that have automated everything else.
Three execution tiers cover every app. Full-API apps get automatic revocation with verified confirmation (Zluri supports 300+ direct integrations). Limited-API apps get guided workflows with evidence captured in-platform. No-API apps get tracked manual tasks with required proof and SLA follow-up.
Set SLAs by risk: emergency revocations (terminations, incidents) within 1 hour, critical access within 24 hours, high within 72, standard within five business days, each with a named escalation path on a miss.
Verification is a step, not an assumption. For API remediations: the removed user's authentication fails, the user object is gone, the app's audit log shows deactivation. For manual ones: status screenshots, vendor confirmations, before-and-after lists. And expect failures as routine, not exceptions: expired API tokens, "cannot delete last admin" dependencies, abandoned manual workflows. Each needs detection, classification, an exception queue, and a weekly report, or failed remediations silently become next quarter's findings.
Done right: denials remediated within SLA, API removals complete in minutes, zero backlog accumulating quarter over quarter.
Phase 7: Automated evidence with indefinite retention
Basic reviews compile evidence when auditors ask, which takes days. Advanced reviews generate it as a byproduct of every action: scope definitions, reviewer assignments, every decision with timestamp and justification, auto-approvals with their criteria, remediation logs with before-and-after state, sign-offs, and cycle-over-cycle metrics, all in an immutable append-only trail retained indefinitely.
Two design details prevent audit-day surprises. Test evidence completeness with a mock audit before a real one finds the gap. And plan for the GDPR-versus-audit-retention tension with redaction capability, replacing personal identifiers with anonymized IDs rather than deleting records auditors will need.
Done right: an auditor's Monday-morning request produces a complete package by Monday afternoon, with report templates (per-framework, per-user, per-app, per-cycle remediation) generated in seconds.
Handling Complex Scenarios
Apps without SSO or APIs. Skipping them leaves a quarter of your risk ungoverned. Each type has a workable path into the review:
- Legacy database apps: extract user tables via read-only DB connection or CSV import, review normally, route remediation to the DBA as a tracked task with proof
- Vendor portals: request user exports, flag as vendor-managed, remediate via a tracked removal request to the vendor with their confirmation as evidence, and report vendor SLA misses separately
- Personal-account usage (Notion, Figma, ChatGPT discovered via browser signals): the review decides migrate-to-corporate or prohibit, with user confirmation as proof
- Custom internal tools: integrate via SDK or API against the app's own auth, review alongside SaaS
Where legacy apps lack login data, substitute alternative activity signals or manager attestation.
Shared, service, and break-glass accounts. Standard reviews assume one user per account; these break that assumption, and each needs its own review pattern:
- Shared accounts: a named owner, a registry of authorized users, owner-attested review, and credential rotation as the remediation (rotation also cures shadow sharing, since new credentials only reach the authorized list)
- Service accounts: tie each to an owning application and owner, who attests the service still operates and credentials rotate within policy; auto-flag orphaned service accounts when the owning app is decommissioned, and disable after 30 days
- Break-glass accounts: every use triggers an automatic review requiring an incident ticket and sign-off, followed by rotation
- Default vendor accounts (admin, root): scan for them everywhere; any still enabled require documented justification or disabling
Contractors with project-based access. Annual cycles miss most contractor expirations, so make access time-bound at the moment of grant:
- Project end date becomes the access expiration; sponsors get notified 30 days out
- Unextended access auto-revokes on the date and is verified gone a week later
- The project tracker integration triggers immediate review when a project closes
- A dedicated quarterly contractor validation runs at higher scrutiny than employee reviews
- Weekly reconciliation against HRMS end dates catches zombie contractors whose access outlived their contracts
Allow overlapping access periods for contractors moving between projects, and a documented grace period for projects that slip.
Acquired companies. You inherit 200 employees and 80 unknown apps with a 90-day audit clock. The sequence that works:
- Week 1: discover before you plan. Deploy discovery across the acquired environment (their IdP, their finance system, their HRIS export) before integration planning finishes.
- Weeks 2-3: map and phase. Assess app overlap, redundancy, and their access governance maturity; critical systems get reviewed inside 90 days, the rest during normal integration, decommission candidates last.
- Weeks 4-8: accelerated certification. Acquired managers review their reports, parent IT validates admin access, parent security reviews external users.
- Months 3-12: integrate. Migrate to the parent IdP, consolidate duplicate tools, fold surviving apps into standard cycles, and use identity resolution to merge duplicate users across the two directories.
Scaling from 500 to 5,000 Employees
At 1,000 employees, user-based review stops being math that works: 1,000 users times 200 apps is 200,000 decisions. Reviewing 50 SSO groups against the same 200 apps is 10,000 decisions, a 95% reduction, which is why group-based access reviews become mandatory rather than optional at this size.
Three prerequisites make group-based review trustworthy:
- A consistent group taxonomy (Function-Department-Level, or role-based names), with no ad-hoc groups, no overlapping duplicates, and no empty shells
- A named owner per group who knows what it grants and who belongs in it
- Monthly group hygiene: delete empty groups after 30 days, assign or remove orphaned ones, consolidate duplicates
The review itself becomes one question, "should this person be in this group," asked of the group owner with the platform surfacing exactly what needs attention: recent membership changes, dormant members, contractors whose projects ended, members whose roles changed. An owner clears a 47-member group in minutes instead of making 47 separate app-level decisions.
Keep 30 to 60 groups total; 300 groups for 1,000 users rebuilds the problem you were escaping. And user-level review still applies to the exceptions: privileged access, external users, and any direct app assignments that bypass groups. Platforms flag these automatically, and log all group membership changes so additions outside the review process surface in weekly reports.
Choosing Your Implementation Path
A workable arc: two foundational phases in the first quarter, intelligence or automation in the second, the rest as needed, then optimize toward continuous governance. The key is progress, not perfection; platforms provide most of this out of the box, so you're enabling capabilities, not building them.
Get Started
You've done the hard part: proving reviews can work. The evolution from "we survived" to "this is sustainable" runs through complete visibility, intelligent routing, closed-loop remediation, and permanent evidence.
If you want a 1-minute self-serve look → Check the access reviews product tours
If you want to see comprehensive automation → Explore Zluri's Access Review Module
If you want to start with a pilot → Book a demo
Frequently Asked Questions
How do I scale access reviews past 1,000 employees?
Switch the unit of review from users to SSO groups. Reviewing 50 well-owned groups instead of 1,000 individual users cuts decision volume by roughly 95%, provided your group taxonomy is clean, every group has a named owner, and privileged or ungrouped access still gets user-level review.
What should I automate first in an access review?
Whatever your biggest pain is, remediation deserves priority attention: in our research it's both the second-biggest challenge organizations report and the step least likely to be automated. Automating decisions while executing removals manually leaves the backlog that makes every next cycle harder.
How do I review apps that have no API or SSO integration?
Bring them in through the data you can get: database extracts or CSV imports for legacy systems, vendor-provided user exports for portals, and browser-detected usage for personal accounts. Review them alongside everything else, and run remediation as tracked tasks with captured proof so the audit trail stays complete even when execution is manual.
.svg)
