How is this different from what Okta or Microsoft Entra offers in their access reviews?

Okta and Entra access reviews work on the apps they govern, which is the SCIM-supported portion of your stack. They route to a reviewer, the reviewer clicks approve or remove, and the action runs in the apps Okta or Entra reaches. Two limits: they don't extend to the apps SSO can't provision (most of the average stack), and they review at group level rather than per-entitlement. Iden runs across the whole stack, including non-SCIM apps and internal tools, at per-resource granularity, and pushes evidence to your GRC platform.

We have Drata. Does Iden replace it?

No. Drata is the GRC platform that owns the audit framework, control evidence, and the auditor-facing portal. Iden is the access governance layer that produces the access-control evidence Drata needs. Native push from Iden to Drata maps each action to the relevant control. Same for Vanta and Secureframe.

What evidence does Iden produce for SOC 2 specifically?

For SOC 2 Common Criteria 6.2 (logical access provisioning): a timestamped record of every access grant, the policy that authorized it, the system that executed it. For CC6.3 (deprovisioning): the same record for every removal, plus the trigger. For CC6.6 and CC6.7 (where applicable): authorization, monitoring, and review records. Each record links to the user, system, and policy. Exportable as CSV or JSON, pushed to GRC automatically.

Our managers rubber-stamp the reviews because they don't know what the entitlements do. Does Iden help with that?

This is the most common failure mode, and yes. Iden surfaces per-entitlement context for the reviewer: when access was granted, who granted it, what activity (if any) the user has had recently, what the entitlement actually permits. Reviewers stop seeing flat lists. They see 'this person had admin on the staging database, last used six weeks ago' and decide on that.

Can we run reviews continuously instead of quarterly?

Yes. Most teams move to continuous after two or three quarterly cycles. Continuous reviews changes as they happen: new grants get reviewed at grant time, dormant access surfaces automatically, expiring exceptions trigger their own micro-review. The audit looks at the running log instead of a quarterly snapshot.

What if a reviewer goes on vacation or leaves mid-cycle?

Each reviewer role has a backup configured at setup. If the primary doesn't act within the policy window, routing moves to the backup. If the primary leaves permanently, ownership of their reviewer responsibilities transfers as part of the offboarding sequence.

What if an approval turns out to be wrong?

Every action in Iden is reversible from the audit log, including a review approval. If approval should have been a removal, an admin can replay the intended outcome. The audit log captures the correction with reason, preserving both the original decision and the fix.

What about ad-hoc reviews after a security incident?

Triggerable from the dashboard. Scope it to a specific user, a specific app, a specific entitlement, or a population (everyone who had access to a specific resource in the last 30 days, for example). The same routing and evidence machinery applies. The artifact is the same shape, just out of cycle.

How long does the first review cycle take to set up?

For most teams: a week. Connecting the HRIS, SSO, and the first batch of apps takes a couple of days. Configuring reviewer routing and policy is another day or two. The first cycle runs as the team is finishing setup, which is intentional. The review work happens at human speed. The system catches up.

What if the auditor wants something we don't have?

Tell us before the audit, not after. Iden ships in two- to four-week sprint cycles. If a control evidence requirement is missing from the standard mapping, we add it. Same for app-level evidence: if the auditor wants something specific from a system we connect to, we extend the connector.

User access reviews and access certifications: how to automate evidence collection for SOC 2 and ISO 27001

The spreadsheet shows up two weeks before the audit. Forty-three apps, two hundred and thirty users, twelve thousand individual entitlements. Twenty-eight managers get an email. Most reply "looks good" within an hour. A handful raise a flag. The IT team chases down the rest, exports CSVs from admin panels nobody else has logged into in years, and assembles the evidence packet by Friday.

The auditor leaves. The next quarter, the spreadsheet shows up again.

Most companies call this an access review. The auditor calls it adequate. The reviewers, if pressed, call it what it is: a quarterly performance of governance that doesn't change much. The orphaned account from last June is still there. The contractor who left in March kept their SAP access until someone noticed. Nobody is lying. The process just wasn't built to actually find these things.

What "with teeth" means

A review with teeth produces three things the spreadsheet review cannot.

Specific decisions. Not "looks good" across a hundred entitlements. A reviewer sees what a person actually does in an app, has a baseline to compare against, and approves or removes per entitlement. The decision is meaningful because the context is meaningful.

Actions that fire. The approve or remove decision translates into a revocation in the app. Not a follow-up Jira ticket. Not an IT manager logging into thirteen admin panels at midnight. The action happens.

Evidence that assembles itself. The full timeline, with timestamps, with the reviewer's identity, with the policy that triggered the review, with the action and its outcome. Exportable. Mapped to SOC 2 CC6.2, ISO 27001 A.5.18, HIPAA §164.308(a)(4). When the auditor asks, you click export, not "give me until Tuesday."

If a review produces all three, it bites. If only the first one fires (decisions with no follow-through), it's theater. Worse is the third one alone: evidence that says reviews happened, without proving they meant anything. That's the configuration most companies have right now.

Why most access reviews fail

The structural reason is that the tooling was built around the audit, not around the work.

The scale problem. A growing company with 800 people on 40 apps generates tens of thousands of entitlements. The honest way to review that volume is per-entitlement, per-quarter, with context. Nothing about the typical access-review workflow makes that possible. The reviewer gets a flat list, no context about what the entitlement does, no signal about whether the person uses it, and a deadline. The rational behavior in that situation is to rubber-stamp. The system is producing the rubber stamps.

The evidence problem. Evidence in most companies is scattered. The CSV from Okta with group memberships. The Slack thread where someone mentioned an exception. The Jira ticket that documented a contractor's elevated access. The screenshot the IT team took to prove the offboarding ran. None of it is structured. None of it ties to a policy. The week-before-audit work is reconstructing a story from artifacts that were never written to be evidence.

Both problems compound. Scale produces rubber-stamp decisions, which produce evidence that says reviews happened without proving they meant anything. Auditors catch this. So do internal compliance teams who care about the outcome.

What it takes to make a review bite

Four conditions. All four, or you're closer to theater than governance.

One source of truth for access

The HRIS knows who works there, in what role, in what status. SSO knows who can authenticate. Iden knows what each person can actually do, per app, per resource. When a review starts, it pulls from one place. Not five.

Reviewer routing tied to ownership

The right person to review someone's GitHub repository access is their engineering manager, not the IT team. The right person to review a finance-system grant is whoever owns that system, not the people-manager. The mapping has to live in the system, and it has to update when ownership changes. Otherwise reviewer routing decays into "whoever was in that role two years ago."

Decisions that translate to action

"Remove" in the reviewer view means the access is removed. Not flagged for removal. Not added to a Jira queue. Removed. The mechanism that handled provisioning handles deprovisioning at the same granularity. Channel-level, repository-level, project-level, wherever the original grant sat.

Continuous evidence assembly

The evidence isn't built the week before the audit. It's built every time a review action runs, in a structured format that maps to the control. SOC 2 CC6.2 (logical access provisioning), CC6.3 (deprovisioning). ISO 27001 A.5.18 (access rights review). HIPAA termination procedures. The mapping is in the system. The export is one click.

Patterns that break access reviews

Five failure modes, named so you can spot them.

The rubber stamp. Manager opens the review, sees thirty entitlements, has no context for what most of them do, and approves all of them in ninety seconds. This is the default outcome of any review that doesn't give reviewers anything to look at besides a flat list.

The spreadsheet. Reviews run by exporting access lists from each app into a CSV, consolidating manually, sending to managers as Excel files, collecting replies, reconciling, and then doing revocations by hand back in each app. Multiple steps, multiple handoffs, multiple places for the chain to break.

Group-level only. The review says "is this person still in the Engineers group?" Manager: "yes." But the person has eight individual repo grants, three database roles, and an admin permission in the staging environment that no group represents. None of those get touched.

The reviewer who left. The reviewer for an entitlement is hardcoded as a specific person. That person quit two quarters ago. The review keeps going to their old email. Nothing happens. Nobody notices until the auditor asks who reviewed what.

The exception that became the rule. Someone needed elevated access for one project. It got approved with a note. The note didn't have an expiry. Two years later the elevated access is still there and nobody remembers why.

What a working quarterly cycle looks like

The HRIS, SSO, and connected apps push their current state into one system. The system assembles per-reviewer views: for each person they manage or each system they own, here's what was granted, when, by whom, and what's actually being used. Reviewers approve or remove per entitlement. Removals fire automatically across the relevant apps within minutes. Exceptions are captured with an expiry. The audit trail writes itself in the format the auditor will ask for.

At the end of the cycle, the IT manager runs an export. That is the evidence packet. The next cycle inherits the state of the last one, so reviewers only see what changed and what's overdue, not the full list again. Most teams move from quarterly to continuous within a few cycles. The same mechanics support either.

Where Iden fits

Iden is built around this model. The HRIS feeds joiner-mover-leaver. SSO and Iden together produce the entitlement view per person, per app, per resource. Reviewer routing follows ownership. Decisions translate to action through the same provisioning layer that handled the original grant. Audit evidence lands in your GRC platform (Drata, Vanta, Secureframe) automatically, mapped to the relevant controls.

"Access reviews finally have teeth. Employees, security, GRC, auditors. Everyone's happy."

Director of IT, 580-employee fintech

The teeth aren't a metaphor. The gap is between a process that collects signatures and one that produces revocations. That's the gap this layer closes.

User access reviews, finally with teeth