Governance Economics, Part 2: Measure the Work, Not Just the Spend

In Part 1, we looked at governance as an economic problem.

The cost is not limited to a compliance budget. It shows up in the time security teams spend reviewing access, the hours engineering teams spend waiting for approvals, the work required to gather evidence, and the effort it takes to determine whether a decision was actually carried out.

That raises a more useful question:

How do you know whether governance itself is working well?

Cost matters, but cost alone does not tell you much about the health of the operating process.

A company could spend less on governance and still have an enormous backlog of unresolved access issues. It could automate part of a workflow while creating more exceptions for people to investigate. It could close tickets faster while failing to verify that the underlying problem was actually fixed.

If we want governance to improve, we need to measure more than spend.

We need to measure the work.

Governance Has an Operating Cost

Consider something as ordinary as an access review.

A user has access that may no longer be appropriate.

Someone has to identify it.

Someone needs enough context to determine whether it matters.

A reviewer has to decide whether the access should stay or go.

If it should be removed, somebody has to make the change.

Then someone should confirm that the access actually changed.

None of those steps is particularly complicated on its own.

The cost comes from coordination.

The relevant information may be distributed across an identity platform, a ticketing system, a spreadsheet, an email thread, and the knowledge of the manager responsible for the user.

Every handoff adds time.

Every missing piece of context creates another question.

Every unclear owner creates another delay.

Multiply that across hundreds or thousands of identities, systems, controls, exceptions, and security findings, and governance becomes a significant operational workload.

That is why measuring governance only by the cost of a compliance team misses much of the problem.

Start With Simple Questions

Before creating sophisticated metrics, organizations should be able to answer some very basic questions.

How much work is waiting for review?

How long does a decision usually take?

How many issues are sitting without an owner?

How often does remediation need additional follow-up?

How many exceptions remain open?

When something is marked complete, how often is the resulting state actually verified?

These are not abstract governance concepts.

They are operating questions.

They tell you whether work is flowing through the system or accumulating inside it.

A growing backlog, for example, may tell you that the organization is identifying issues faster than people can resolve them.

A long review cycle may indicate that reviewers do not have enough context when the work reaches them.

Repeated follow-up may mean ownership is unclear.

A high number of unresolved exceptions may show that temporary decisions are quietly becoming permanent.

Those signals can be more useful than another dashboard showing that a control exists.

The Cost of Waiting

Governance also affects teams that do not think of themselves as governance teams.

Engineering is a good example.

A new system may require security review, architecture approval, risk review, identity configuration, and compliance validation before it can go live.

Those controls exist for good reasons.

But the way those controls are operated matters.

If every review begins with someone gathering the same information again, if ownership is unclear, or if decisions disappear into email and meetings, the process gets slower than it needs to be.

The goal should not be to eliminate review.

The goal should be to remove unnecessary coordination around the review.

There is an important difference.

Strong governance should make it easier to understand what needs approval, who has authority to approve it, what information they need, what they decided, and what happened afterward.

When those pieces are clear, teams can move faster without lowering the standard.

Better Evidence Changes the Economics

Evidence is another area where governance cost hides.

Organizations often perform the work correctly but fail to preserve enough context while the work is happening.

Months later, somebody has to reconstruct it.

Who approved this access?

Why was this exception allowed?

Was this user actually removed?

Which version of the policy applied?

Was the remediation verified?

At that point the organization is paying for the same work twice.

The first cost was doing the work.

The second cost is proving later that the work happened.

A better operating model keeps evidence connected to the decision as the work moves forward.

That can be as simple as preserving the reviewer, the decision, the reasoning, the owner, the remediation status, and the verification result together.

You do not need a futuristic autonomous system to begin improving this.

You need a better record of the work.

Where TPZ Starts

This is one of the reasons Trust Player Zero is starting with identity and access governance.

The current Beta connects to supported identity systems and pulls the information required for identity-governance workflows.

TPZ can help a team organize identity and access information, surface conditions that require attention, assign ownership, record review decisions, track remediation, and verify outcomes.

The current Beta is human-governed.

People still decide what should happen, and changes to the underlying customer environment remain under human control.

That gives us a practical starting point for understanding the economics of governance.

Instead of beginning with a promise to automate everything, start by making the existing process easier to see and operate.

How much work is open?

Who owns it?

What was decided?

What is waiting for remediation?

What was verified?

Where does work repeatedly stall?

Once those questions become easier to answer, the organization has a much better foundation for deciding what should be automated next.

Automation Should Follow Understanding

There is a temptation in security to treat automation itself as the outcome.

It is not.

Automating a poorly understood process can simply make bad decisions happen faster.

Before an organization gives a system authority to act, it should understand the boundaries around that action.

Who authorized it?

What can the system change?

Under what conditions?

What happens if the action fails?

How do we verify the result?

Can the organization recover?

Those are governance questions before they are automation questions.

This is why the TPZ roadmap moves in stages.

The Beta begins with Identity Governance.

The next stage expands into Security Decision Support, bringing more context together so teams can better understand what deserves attention and what actions should be considered.

The longer-term direction is Governed Security Automation, including approved write-back, bounded automation, verification, and recovery.

The point is not to automate governance out of existence.

It is to make governance strong enough to support more automation safely.

What Should We Eventually Measure?

As governance becomes more structured, organizations can begin asking better questions about system behavior.

For example:

Backlog: How much governed work is waiting for attention?

Time to decision: How long does it take to move from identifying an issue to reaching a decision?

Time to remediation: Once a decision is made, how long does it take for the environment to change?

Verification rate: How often is completed remediation checked against the actual environment?

Exception age: How long do temporary exceptions remain open?

Rework: How often does a task return because the original action did not resolve the issue?

Ownership gaps: How much work enters the process without a clearly responsible person?

These measures are useful because they tell us where governance is creating friction and where software can help.

They also create a much more credible basis for discussing ROI.

Instead of saying, “automation saves money,” an organization can ask:

Did the backlog shrink?

Did review times improve?

Did fewer issues require repeated follow-up?

Did the team spend less time reconstructing evidence?

Did remediation become easier to verify?

Those are outcomes a security leader can actually evaluate.

The Economics Get More Important as AI Expands

This becomes even more important as organizations introduce more AI into security and enterprise operations.

More systems will be capable of recommending actions.

Some will eventually be allowed to execute them.

That increases the importance of knowing who authorized an action, what authority the system had, what actually happened, and whether the result matched the intent.

AI does not remove the governance problem.

It makes the cost of weak governance more visible.

The organizations that handle this well will not necessarily be the ones with the most automation.

They will be the ones that know where automation belongs, what boundaries it operates within, and how to tell whether it worked.

Governance Should Become Easier to Operate

The economics of governance ultimately come back to a simple idea.

Security teams should not have to spend more and more human effort simply because their environments become more complex.

The first step is not removing people from governance.

It is removing the unnecessary work around them.

Bring the right information together.

Make ownership obvious.

Keep decisions attached to their reasoning.

Track what happens after the decision.

Verify the result.

Then automate the parts of the process that are understood well enough to deserve it.

That is the direction we are building toward at Trust Player Zero.

Good governance should not slow an organization down because people are struggling to connect the process. It should give the organization enough structure to move with confidence.