Every meaningful identity governance metric spans multiple steps of a chain: an HR event, a workflow, a per-app account change, a review decision. When each step lives in a different tool, the metric doesn't exist until someone builds a data project to stitch it together. This is why most governance programs report activity instead of outcomes, and why the ability to measure governance is an architectural property, not a reporting feature.

Ask a governance program built on separate tools how it's doing, and you'll get activity numbers: campaigns completed, requests processed, workflows triggered. Ask for outcomes, how fast access actually closes after a termination, whether the same entitlements keep getting revoked every quarter, and the answer becomes a project. Someone has to export from three systems, reconcile identities that don't match across them, and stitch the chain together by hand.

That's not a reporting gap. It's a property of the architecture. This piece covers why, metric by metric, and what it costs.

Every Metric Worth Reporting Spans More Than One Tool

The metrics that prove governance works are chain measurements. Each one starts in one system and ends in another:

• Mean Time to Revoke starts with an HR termination event and ends with completed deprovisioning in every target app. HR system → workflow engine → per-app account state.
• Offboarding success rate requires knowing every step of every offboarding workflow completed, across every application, including the ones outside SSO. Workflow engine → app-level verification.
• Revocation rate trends require review decisions matched against the provisioning history that granted the access in the first place. Review tool → provisioning tool → time.
• Request cycle time spans request submission, approval routing, and fulfillment, which in many stacks are three different systems (a ticketing tool, an approval flow, a provisioning tool).

In a disparate stack, each tool holds its own fragment. The certification tool knows a review happened. The provisioning tool knows a workflow started. Neither knows whether the revocation actually completed in the target app, and nothing connects the timestamps into a duration anyone can report.

A disparate stack doesn't measure badly. It doesn't measure at all, because no single tool in it holds enough of the chain to compute the number.

What the Reconciliation Project Actually Looks Like

The standard answer is a manual reconciliation: export from each tool, match identities across formats, rebuild the chain in a spreadsheet or a BI project. Three things reliably go wrong with it.

Identity records don't match across tools. The same person appears as different records in each system, a formatting difference, a stale sync, a manually created account, and matching them is itself error-prone work. Every mismatch either drops a record from the analysis or attributes one person's access to another.

The project doesn't survive its second quarter. The first reconciliation gets done ahead of an audit or a board meeting, takes days, and produces numbers everyone distrusts slightly. The second one gets deprioritized, because the person who built the first spreadsheet has actual work to do. Measurement that requires a recurring manual project isn't measurement; it's an occasional estimate.

The figures conflict. When two tools count the same thing independently, app inventory, license counts, active identities, they disagree, and every reporting cycle starts with an argument about whose number is right rather than what the number means.

The Cost Isn't Abstract

What a program loses when it can't measure itself shows up in three specific places:

• The exposure window stays unknown. A program that can't compute MTR doesn't know how long departed employees keep working access. Not "knows it's too long", doesn't know. The single most important number in identity governance is unavailable by construction.
• Reviews can't improve anything. Without revocation trends per entitlement, there's no way to see whether reviews are tightening upstream granting or just finding the same problems every cycle. The review program runs forever at the same effectiveness because nothing feeds back.
• The budget case runs on assertion. When renewal time comes, the program defends itself with activity counts and avoided hypotheticals rather than outcome numbers, the weakest possible position, as covered in the five levers of governance value.

What Measurement Requires From the Architecture

The fix isn't a better reporting tool sitting on top of the fragments. A BI layer over disconnected sources inherits every reconciliation problem underneath it, it just automates the spreadsheet.

Measurement requires the chain to exist in one data layer to begin with:

In prose: MTR becomes computable when the HR event and the per-app deprovisioning completion sit on the same identity record. Offboarding completeness becomes verifiable when workflow steps check against actual account state instead of assuming initiation meant completion. Revocation trends become visible when the grant, the review decision, and the revocation share one history. The figures stop conflicting because there's one inventory being counted, and the effort drops from a recurring project to a generated report.

That's a converged data model, and measurement is arguably its least-discussed benefit: the same architecture that makes governance functions coordinate is what makes governance provable. On Zluri, requests, reviews, workflows, and account state already run through one platform, which is why the fourteen metrics that matter are a dashboard, covered in Zluri's governance dashboards, not an engineering roadmap. What those fourteen metrics are, and what healthy looks like for each, is its own guide: how to measure IGA.

The same architecture that makes governance functions coordinate is what makes governance provable.

Frequently Asked Questions

Can't we just build the metrics in our BI tool from exports?

You can build the first version. The problem is durability: a BI project over disconnected identity sources inherits the identity-matching and figure-conflict problems of the sources themselves, and it depends on exports staying current and someone maintaining the pipeline. In practice these projects produce one credible report and then decay. Measurement that isn't a byproduct of how the stack already works tends to stop happening.

Our tools all have reporting. Why isn't that enough?

Each tool reports accurately on its own fragment: the review tool on campaign completion, the provisioning tool on workflows triggered. The metrics that prove governance works, MTR, offboarding completeness, revocation trends, span fragments, and no individual tool's reporting can cross its own boundary. Activity metrics per tool, outcome metrics never.

Is this only a problem for large organizations?

Smaller stacks have fewer tools but the same gap: even two systems, an IdP and a separate review tool, can't jointly compute time-to-revoke across unfederated apps or verify offboarding completeness outside SSO. The reconciliation burden is smaller; the uncomputable metrics are the same.

Which metric should we test our own stack against first?

Mean Time to Revoke. Ask, for the last five departures, exactly how many hours passed between the HR termination and the last application access being closed, with evidence. If the answer requires more than pulling a report, the measurement problem applies to your stack, and MTR is just the first place it shows.

‍