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 team running a disparate identity stack for their Mean Time to Revoke, and watch what happens. Not the estimate, the actual number: average elapsed time from HR termination event to completed deprovisioning across every application, for the last quarter.
Usually the answer involves a pause, then a description of a project. Someone would need to pull termination timestamps from the HRIS, workflow execution logs from the provisioning tool, per-app account status from wherever that lives (often nowhere central), and join them on identities that don't share a common key across systems. It's doable. It's a data engineering sprint. And by the time the report exists, it describes last quarter.
That pause is the diagnosis. The stack executes governance, tool by tool, step by step. What it cannot do is observe governance end to end, because no single component sees the whole chain. Measurement isn't a missing feature in any one tool. It's a property the architecture doesn't have.
Every Governance Metric Is a Join
The metrics that actually describe governance outcomes were covered in depth in how to measure an IGA program; what matters here is what those metrics are made of. Look at the data each one requires:
Not one of these metrics lives inside a single tool's boundary. Each is a join across systems that were never designed to share a data model. The certification tool knows a reviewer clicked "revoke"; it doesn't know whether the revocation completed in Salesforce. The provisioning tool knows a workflow fired; it doesn't know the HR timestamp that should start the clock, and it often doesn't know about the six apps that aren't connected to it at all.
Each tool reports honestly on its own slice, and the slices don't add up to an answer. This is why disparate-stack reporting gravitates toward activity metrics: campaigns completed, tickets closed, workflows triggered. Those are the only numbers each tool can produce alone.
The BI-Project Trap
The standard response is to build the join anyway: export from each system into a warehouse, hire or borrow an analyst, and construct governance reporting as an internal data project. Teams that go down this road hit the same three walls in the same order.
The identity-resolution wall comes first. The HRIS knows an employee ID, the IdP knows a UPN, each SaaS app knows its own account name, and the certification tool knows whatever was imported into it last. Joining governance data means first solving identity resolution across all of them, which is a genuinely hard problem, and one your identity platform was supposed to be solving in the first place.
The staleness wall comes second. Batch exports produce point-in-time snapshots. The resulting metrics describe the state of governance as of the last export run, which means the report answers "how were we doing three weeks ago?" while the risk question is always "where are we exposed right now?" A stale MTR number isn't a slightly worse MTR number; a departed employee's live account either exists at this moment or it doesn't.
The trust wall comes last, and it's the one that kills these projects. When the warehouse number disagrees with what a tool's own console shows, and it will, every review meeting becomes an argument about whose data is right instead of a decision about what to fix. Metrics that have to be defended before they can be used stop being used.
The pattern to notice: in a disparate stack, measurement is a project with a budget, an owner, and a decay rate. In a converged platform, measurement is a byproduct of the system doing its normal work.
Why Convergence Changes the Arithmetic
The alternative isn't a better reporting tool on top of the same stack. It's an architecture where the chain each metric describes runs through one system to begin with.
When discovery, access requests, reviews, and workflow execution operate on a single data layer, the joins that make governance metrics possible already exist as a side effect of operation. The platform that received the HR termination webhook is the same platform that executed the deprovisioning workflow and the same platform that tracks per-app account state through its integrations. MTR isn't computed from an export; it's the elapsed time between two events the system itself recorded. Offboarding success rate isn't reconstructed from tickets; the system knows which of its own workflow steps completed and which failed, because completing them was its job.
This is the measurement corollary of the broader argument in the disparate vs converged IGA model: one system runs requests, reviews, and workflows, so one system can measure all of them. The same convergence that makes governance faster to operate is what makes it possible to observe. You cannot retrofit that observability onto a stitched stack, because the gaps between tools are exactly where the metrics live.
There's a second-order benefit that's easy to miss. Because the metrics come from live operational data rather than periodic exports, they stay updated in real time, always reflecting the state you can act on. A failed offboarding workflow appears as a failed workflow now, not as a discrepancy in next month's warehouse refresh. Measurement and remediation collapse into the same motion.
The Question That Sorts Vendors
This gives evaluation teams an unusually clean test, and it works better than any feature checklist. Ask any identity vendor: show me my Mean Time to Revoke and my offboarding success rate, for my environment, out of the box.
A converged platform demonstrates it from live data. A disparate-stack component will, entirely reasonably, explain which slice of the chain it covers and what else you'd need to integrate. Neither answer is dishonest, but the difference between them is the difference between buying governance you can verify and buying governance you'll have to take on faith. Zluri's answer to that test is its governance dashboards, which surface these metrics from the same data layer that executes the underlying work; what's inside Zluri's governance intelligence dashboards walks through them in detail.
Frequently Asked Questions
Can't a SIEM or data warehouse solve governance measurement for a disparate stack? Partially, at real cost. A SIEM sees events and logs, not governance state: it can tell you a login happened, not whether an entitlement should exist or whether a review decision was enforced. A warehouse can host the joins, but someone has to build and maintain identity resolution, export pipelines, and metric logic across every tool, and the result is periodic snapshots rather than live state. Both approaches turn measurement into an ongoing engineering commitment.
Is this an argument against best-of-breed identity tools? It's an argument about what best-of-breed costs that rarely appears in the evaluation. Individual tools can be excellent at their slice while the stack as a whole remains unobservable. If end-to-end measurement matters to your program, and for audit and board reporting it increasingly does, treat measurability as a first-class requirement rather than assuming it can be added later.
We already run a disparate stack. What's the pragmatic first step? Attempt to compute one metric, Mean Time to Revoke, manually for last month's leavers. The exercise costs a few hours and tells you precisely where your data gaps are: which timestamps don't exist, which apps' account states nobody can see, which identities can't be joined. That map of gaps is more useful than any tooling decision, because it shows what any future architecture has to close.
Does a converged platform mean replacing every identity tool at once? No. Convergence describes where the governance chain runs, not how many tools exist around it. HRIS, IdP, and ITSM systems keep their roles; the requirement is that discovery, requests, reviews, and workflow execution share one data layer so the chain between them is observable. Migration to that model is typically incremental, starting with the leaver path where measurement matters most.
.svg)
