Governance Economics, Part 1: The Hidden Cost of Security Governance
A security budget can show what an organization spends on tools, outside support, and headcount. It is harder to see how much of that paid time goes into coordinating the work around a security decision. Reviews, follow-up, and evidence collection may be spread across several teams without anyone seeing the whole process.
Much of this effort is already included in salaries and contracts. The difficulty is understanding how that time is being used. A manager’s access review, an administrator’s follow-up, and a compliance team’s search for evidence may all relate to the same issue, yet appear as separate tasks in different departments.
That is the part of security economics I think deserves more attention. Following a decision from the initial finding through the final check gives us a way to see work that a budget alone cannot explain.
Governance is work
Governance is often discussed in terms of policies, oversight, and accountability. In practice, it also involves people gathering information, deciding what should happen, and checking the result. Those tasks serve a purpose, but they can become difficult to coordinate when the evidence, authority, and record of the work live in different places.
Consider a routine access review. The identity platform contains account information, a manager understands the person’s responsibilities, and an internal policy describes the access expected for that role. A ticket tracks the review while an administrator controls the system where a change would occur. Someone has to connect those pieces before the organization can make and carry out an informed decision.
The work is spread across teams
Each team sees a different part of the process. Security may track investigation time while IT tracks administration. Managers fit access reviews around their other responsibilities, and compliance may become involved only when someone needs evidence. No single view necessarily captures everyone’s contribution.
Following the issue across those teams makes the effort easier to understand. Look at how many people handled it, which systems they consulted, and where they needed more information. Include the follow-up after a change and any later work required to explain the decision. Those activities belong to the same process even when different departments perform them.
A simple access decision can become expensive
Imagine a reviewer notices that an account has privileged access. Before deciding whether anything should change, they need to understand who owns the account and why the privilege was granted. The person’s current responsibilities, recent activity, and any applicable policy or approved exception may also matter. Finding those answers can require several systems and conversations with people outside the security team.
Once the reviewer reaches a decision, there is still work to do. A change may require authorization before an administrator carries it out. Someone needs to check the source system afterward, and the record should show what was decided and what actually happened.
The judgment itself may be quick once the necessary context is available. Getting to that point, carrying out the decision, and preserving the evidence can take considerably more effort. Looking only at the time spent making the decision leaves much of the work unaccounted for.
Rework is part of the cost
Imagine an access review completed in March. Six months later, an auditor asks why the user held a particular permission. Someone locates the old ticket, another person checks logs, and a manager searches email for the original reasoning. The organization may have made an appropriate decision but left the information needed to explain it scattered across several places.
The missing record can also make it difficult to establish whether an approved change occurred. A closed ticket may show that work was requested without preserving the state observed afterward. People then spend time investigating an issue they believed was already finished.
Keeping the review evidence, decision, authorization, and result connected gives later reviewers something they can examine. It does not remove the need for audits or questions, but it can reduce the effort of rebuilding the history from messages and memory.
Waiting has a cost too
Some waiting is necessary. A consequential access change deserves appropriate review, and an exception may need discussion before anyone approves it. The time required for that judgment should be distinguished from delays caused by missing information or unclear responsibility.
An issue might sit because nobody knows who owns it. A reviewer may be ready to decide but unable to find the relevant policy. A request may move back and forth because the information needed for approval was never included. These situations call for different improvements than a review that genuinely needs more careful consideration.
Track waiting separately from the time people actively spend on the work. That makes it easier to see whether the next improvement should address capacity, the quality of information reaching a reviewer, or the way responsibility is assigned.
More reviews do not always solve the problem
When a security process fails, another approval or report can seem like a reasonable response. Sometimes an additional control is needed. In other cases, it adds another handoff while leaving the original difficulty unresolved.
Before adding a step, examine what prevented the existing process from working. A reviewer who could not find the necessary evidence may need a better way to access it. An issue that had no owner needs an explicit assignment of responsibility. Difficulty locating records does not, by itself, establish whether the organization has enough oversight or whether another review would help.
Make the work easier to coordinate before automating decisions
Before asking software to make a consequential decision, look at the work required to prepare for it. Bringing relevant evidence together and keeping the review context attached to the finding can make the task easier for the person responsible. The workflow should also make clear what was authorized and what needs to happen next.
A manager should be able to evaluate whether access is appropriate without first discovering which system contains the relevant permissions. An administrator needs a clear instruction tied to an authorization. A later reviewer should be able to examine the record without rebuilding it from several sources.
These are useful improvements to investigate before expanding automation. Once the process is understood, the team has a better basis for deciding which tasks software should perform and which decisions still require human judgment.
Verification can reveal unfinished work
Suppose a remediation task is marked complete without anyone checking the resulting state. Months later, the same condition appears and another investigation begins. If the original change never took effect, the organization now has both an unresolved security issue and duplicated work.
Checking the source system can reveal that the intended result was not achieved. An account intended for disablement should be checked for its disabled state. A role assignment intended for removal should be checked to confirm the assignment is gone. When the result does not match the decision, the issue can remain open for follow-up.
Verification does not carry out the missing change. It gives the team evidence about whether the work succeeded and whether more action is required. Preserving that result also helps a later reviewer distinguish an incomplete earlier change from a genuinely new occurrence.
Start measuring the work you already have
The cost of operating these workflows depends on the environment. A company with a small set of applications will have different review needs from an organization where access decisions involve several teams and complex permissions. Claims about savings need to be tested against the work the organization actually performs.
Start with a few recurring workflows and establish a baseline. Look at active working time, where the process waits, and how often people repeat an investigation or reconstruct evidence. Keep verification visible so a closed task is not automatically counted as a confirmed result. Governance Economics, Part 2 explains how to measure those stages and use the results to choose a specific improvement.
Where TPZ is starting
This operating problem is part of why Trust Player Zero is beginning with identity and access. When configured for live access, TPZ can read supported Microsoft Entra and Azure identity and access information, subject to permissions and current coverage limits. This starting point is read-only and 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 reading the resulting state back from Entra and retaining the evidence. The target also includes an authorized re-enable process with verification of the restored state. These are Beta targets, not capabilities TPZ already performs today.
The program is intended to help us understand the work around an identity finding. We want to learn what information helps a reviewer decide and where responsibility becomes unclear. Testing authorization, verification, and recovery is also intended to establish what evidence needs to remain. Those questions give us a basis for evaluating the workflow before making claims about its economic value.
Follow one recent review
Choose one recent access review and ask everyone involved what they had to do. Separate time spent evaluating the access from time spent locating information, finding an approver, following up, or reconstructing the record. Include work that happened after the ticket was closed.
Use that review to identify one coordination task worth improving while preserving the judgment and authorization the decision requires. The next time a similar issue appears, compare what people had to do. That gives the team a concrete way to assess whether the change helped.
