Governance Economics, Part 2: Measure the Work, Not Just the Spend
In Governance Economics, Part 1, I wrote about the operating cost of security governance. People gather context, reviews wait for decisions, administrators carry out changes, and compliance teams reconstruct the evidence later. That work consumes time even when nobody has labeled it “governance spend.”
Spending alone cannot tell you whether the process is improving. A company could spend less while unresolved access issues accumulate. It could close more tickets without checking whether the underlying state changed, or automate one stage while creating exceptions that people have to investigate afterward.
To understand whether governance is getting easier to operate, we need to look at how the work moves. That means following an issue through review, identifying where it waits, and checking what happens after someone decides it is finished.
Start with how the work moves
Take a common identity and access issue. A condition is identified, and a reviewer needs enough context to decide whether anything should change. An appropriate change needs authorization before an administrator or system carries it out. The result should be checked, and a useful record should remain.
Before tracking these stages, agree on when each one begins and ends. Record when a finding is identified, when a decision is made, when an approved change is carried out, and when the result is verified. Keep those definitions consistent when comparing the work over time.
The following measures give you places to look for delays, unclear responsibility, and repeated effort. You can start with the ones that answer a question about a workflow you already need to improve.
1. Measure how much work is waiting
Start with the findings, reviews, exceptions, and remediation tasks waiting for someone. An open item is not automatically a problem. Some work should remain open while people gather information or make a careful decision, so the reason it is waiting matters.
Separate work waiting for review from work waiting for context, an owner, approval, remediation, or verification. For example, imagine a backlog of 143 open items, 60 of which have no clear owner. The total shows the amount of unfinished work, while the ownership gap gives you a specific place to investigate.
2. Measure time to decision
Time to decision captures the interval between identifying a condition and deciding what to do about it. This is where a reviewer needs to understand the evidence, establish who has authority, and determine an appropriate response.
When that interval grows, look at what is happening during the wait. A reviewer might be overloaded or missing information. The issue may be moving between security, IT, management, and an application owner because responsibility is unclear. If each person has to reconstruct the same context, the delay may have little to do with the decision itself.
3. Measure handoffs
An access issue might begin with security, pass to a manager for review, and reach IT for execution. Security may then check the result, while compliance asks for the evidence later. Each transfer creates another point where information can be lost or work can sit without a clear next step.
For a recurring workflow, count the people and systems involved and look at what happens between them. Several reviewers may be appropriate for a consequential change. The question is whether each handoff serves a purpose and leaves the next person with enough information to continue.
4. Measure ownership gaps
Track how many open issues have a clearly responsible person, how long assignment takes, and how often work moves between teams because nobody knows who should decide. An ownership gap is easier to address when it is visible before an item has been waiting for weeks.
Several people can see the same finding without agreeing who is responsible for it. The workflow should make that responsibility explicit so people know who owns the next step and where to take a question.
5. Measure remediation time separately from decision time
A team can make decisions quickly and still take a long time to carry them out. Another team may execute changes promptly but spend days deciding what should happen. Combining those intervals makes it difficult to tell which part of the process needs attention.
Keep time to decision separate from time to remediation. The first measures the wait until the organization decides what should happen. The second measures the time from that decision to the intended change being carried out. Record authorization as part of the workflow so any approval wait remains visible.
Slow decisions may point to missing context or unclear authority. Slow remediation may involve administrative queues, tooling limitations, or a complicated execution path. Those problems need different responses.
6. Measure verification
Verification is one of the measures I think deserves more attention. A task marked complete does not establish that the environment now reflects the intended result. When an account is supposed to be disabled, someone still needs to check its state in the source system. The same principle applies to removing access or changing a role assignment.
For consequential changes, track the percentage checked against the source system and whether the observed result matches the decision. A record that a change was requested or attempted is useful, but it cannot substitute for checking the resulting state. Keeping verification separate makes unfinished follow-up visible even after an execution task has been closed.
7. Measure rework
Suppose a team investigates an issue, makes a change, and encounters the same condition three months later. It could be a new occurrence, or the original change may never have taken effect. An exception may have gone unreviewed, or the underlying cause may still be present.
Track returning work and the reason it returned. That distinction helps you separate new conditions from unresolved earlier work. Otherwise, the team may repeatedly spend time investigating what appears to be a fresh issue without recognizing the connection.
8. Measure exception age
Track how many exceptions are open, how old they are, who owns them, and when they are due for review. It also matters whether the original reason still applies and how many exceptions have passed their intended review date.
An old exception can still be justified. The concern is an exception that remains in place without anyone checking its rationale or accepting responsibility for the next review. Looking at age alongside ownership and review dates makes those cases easier to identify.
9. Measure evidence reconstruction
Some of the work appears long after the original decision. An auditor asks a question, a customer sends a security questionnaire, or leadership wants to understand a past access change. Several people may then have to reconstruct what happened.
For recurring requests, track how often the existing record provides an answer and how often someone must search old tickets, email, or Slack. Notice when the explanation depends on finding screenshots or asking someone to remember why a decision was made. That effort is part of the workflow’s cost, even if it occurs months later.
Keeping useful evidence during the work can reduce the need to rebuild the history afterward. Measuring reconstruction helps show which information is missing from the original record.
Keep the measurements manageable
It is possible to create so many metrics that reporting becomes another burden. Start with a small set that helps you understand a specific workflow, and expand only when another measure answers a useful question. The nine measures above can be summarized this way:
| Measure | Question it answers |
|---|---|
| Open work | How much is waiting, and why? |
| Time to decision | How long until someone decides what should happen? |
| Handoffs | How many people and systems does the issue pass through? |
| Ownership gaps | How much work has no clearly responsible person? |
| Time to remediation | How long until the intended change is carried out? |
| Verification | Is the resulting state checked against the source system? |
| Rework | How often does resolved work return, and why? |
| Exception age | Which exceptions need another review? |
| Evidence reconstruction | How much effort does it take to explain past work? |
Measurement should explain the workflow
An increase in time to decision tells you where to investigate, but it does not explain the cause. Reviewers may be receiving incomplete information. An issue may require several approvals, or it may sit unnoticed before anyone begins reviewing it. The same elapsed time can reflect very different problems.
This is why I would be cautious about collapsing governance into one score. It can hide the difference between work waiting for a decision and work waiting for a change to be checked. Keep enough detail to understand what the team needs to do differently.
Use measurement to decide where automation could help
Suppose a review shows that most of the delay comes from gathering the same context across three systems. That gives you a specific place to investigate whether software could help. You can assess the repeated work before deciding how to change it.
An administrative queue creates a different problem. Decisions may already be clear, while approved changes wait to be carried out. If execution is prompt but completed changes are rarely verified, making execution faster would leave that gap unresolved.
Understanding the bottleneck gives an automation proposal a concrete purpose. It also gives the team something to measure afterward, rather than assuming that faster activity in one stage improved the whole process.
Where TPZ is starting
Identity and access gives TPZ a practical starting point for this work. When configured for live access, TPZ can read supported Microsoft Entra and Azure identity and access information, subject to permissions and current coverage limits. That starting point is read-only; it does not include changing a customer’s Entra environment.
The Design Partner Beta is designed to begin with an evidence-backed Microsoft Entra identity and access audit. It is intended to progress toward a customer-authorized account-disable action, followed by read-back verification and retained evidence. The target also includes an authorized re-enable and recovery process, with verification of the restored state. These are Beta targets, not capabilities TPZ already performs today.
That sequence gives us a way to investigate the operating process around an identity finding. We want to understand which context helps a reviewer decide, where responsibility needs to be clearer, and what evidence should remain after an action. The program is intended to produce evidence about those questions before we make claims about workflow improvement.
The same principle applies to AI
When AI is used to summarize evidence, recommend an action, or help identify a condition, it becomes part of a workflow that still needs to be understood. If software is authorized to carry out a change, the record should show who authorized it, what informed it, and what the software was allowed to do.
The team also needs to know what actually happened, whether the result was verified, and whether recovery was necessary. Those questions remain useful regardless of whether a person or software carried out the action. They give the organization a way to examine the outcome rather than relying on the amount of activity recorded.
Start with one workflow
Choose one recurring identity or access workflow and establish a baseline. Look at where work waits, who owns the next step, and whether completed changes are verified. Use consistent definitions so the team can compare the process over time.
Then choose one improvement and compare the same measures after the change. Did the delay decrease? Did work stop returning for the same reason? Use the results to decide whether to keep the change, adjust it, or address the next bottleneck.
