Where Governance Gets Expensive
Seven sources of security work that are easy to underestimate
An access review might involve a manager deciding what someone needs and an administrator checking a role assignment. Later, a security lead follows up on an exception, or a compliance analyst looks for evidence of the decision. Each person handles part of the work, but the total effort can be hard to see.
Some of that effort is necessary review. Some goes into locating information, finding the right approver, or reconstructing what happened afterward. These seven examples offer places to examine how the work is organized. They can overlap, so use them to investigate a process rather than treating them as separate costs to add together.
1. Gathering context before anyone can decide
Consider an access review. Before deciding whether a permission is appropriate, the reviewer may need to understand who owns the account, the person’s current responsibilities, and why the access was granted. Privileged roles, account activity, and any applicable policy or approved exception may also need attention.
That information can be spread across the identity platform, business applications, and records held by a manager. Some of it may exist only in a ticket or spreadsheet. The reviewer has to locate those pieces and work out how they relate before evaluating the access.
This is worth examining separately from the decision itself. When someone spends most of a review collecting information, improving how that information reaches them may be more useful than changing the approval process.
2. Proving work that already happened
An access review can create another round of work when someone later asks for evidence of the decision. An auditor might ask why a user held privileged access six months ago, or leadership might want to know whether an approved change occurred. The original review may have been handled correctly, while the information needed to explain it remains scattered.
Someone finds the ticket, another person checks logs, and a manager searches old messages for the reasoning. Looking at the current configuration may not answer what the system showed when the work was completed. The team now has to reconstruct a record from whatever remains available.
Keeping the evidence connected to the decision gives later reviewers something to examine. The record should identify who reviewed the issue, what informed the decision, and what action was authorized. It should also preserve the result of checking the source system afterward. That can reduce the amount of reconstruction needed when a question arrives months later.
3. Waiting because ownership is unclear
A consequential access decision deserves appropriate review. Some questions need discussion, and a request should not be rushed simply to close a ticket. It helps to distinguish that deliberate review from time spent waiting because nobody knows who is responsible.
An issue may move between security and an application owner while each assumes the other will decide. A reviewer may be waiting for information without knowing whom to ask, or an administrator may have a request without a clear authorization. In each case, the work is stalled before the person responsible can proceed.
Look at what an item is waiting for and who owns the next step. A process that makes those responsibilities explicit gives people a way to move the issue forward without repeatedly asking where it belongs.
4. Exceptions that outlive their reason
A contractor may need temporary access, or a project may require elevated privileges for a defined period. An unusual permission can have a legitimate business purpose that is not obvious from the technical configuration alone. The exception needs enough context for someone else to understand that purpose later.
Problems arise when the context changes without another review. The project ends, the approver moves into a different role, or the original business requirement no longer applies. Access can remain in place while the reason for it becomes harder to establish.
Keep the exception connected to its owner, its rationale, and the date or condition that should trigger another review. Age alone does not determine whether an exception is wrong. It does help identify cases where someone needs to confirm that the original justification still holds.
5. Treating “complete” as the end of remediation
Suppose an access review determines that a permission should be removed. The work is assigned, an administrator attempts the change, and the ticket is closed. Unless someone checks the source system, the record may establish only that an action was attempted.
A request could fail or target the wrong account. Even when a change succeeds, another process may alter the state later. Reading the source system after the action lets the team compare the observed result with what was intended. Recording when that check occurred helps a later reviewer interpret the evidence.
If the observed state does not match, or the check cannot establish the result, the issue needs further attention. Verification can identify unfinished work, but it does not perform the missing change or guarantee that the state will never change again. Keeping that distinction clear can help a team investigate a returning condition without assuming the earlier work succeeded or failed.
6. Asking people to decide with incomplete information
There is a difference between spending time gathering context and being asked to decide before the necessary context is available. A reviewer may receive a username and a permission without knowing why the access was granted or whether an exception applies. They then have to pause, request more information, or risk relying on an assumption.
The process should make those gaps visible. A reviewer needs to distinguish what is known from what still requires confirmation. They also need enough explanation to understand why the access deserves attention, without having to sort through every available data point.
Software could help by presenting the relevant evidence and keeping unanswered questions attached to the review. The eventual decision should remain connected to the information used to make it. That is a practical way to support human judgment without giving software authority to make the decision.
7. Complexity growing faster than the team
When an organization adds applications, identities, and permissions without changing how reviews are coordinated, the existing process has more work to carry. Security staffing may not increase at the same pace. The team may respond with another spreadsheet, a new ticket queue, or an additional review step.
Those adjustments can help with an immediate need while creating more places to maintain information. A growing share of the process may depend on particular people knowing which records to compare and whom to contact. Every new review then requires some of that knowledge to be assembled again.
Look at whether the effort required for each decision is increasing. Where people repeatedly retrieve the same information or explain the same handoff, there may be an opportunity to improve the process before adding another layer of reporting.
A clearer identity workflow
The workflow TPZ is working toward connects an identity or access finding with the decision about what to do next. When a change is appropriate, it needs authorization, execution, and a check of the resulting state. We describe that sequence as Find → Decide → Fix → Verify.
In that workflow, the finding should remain attached to its evidence so the reviewer can understand it. The decision should identify what was approved, and the person carrying out the change should be able to refer to that authorization. The verification record should show what the source system returned afterward. These are the connections to examine when an issue repeatedly requires manual follow-up.
Where TPZ fits today
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 in Entra, followed by read-back verification and retained evidence. The target also includes an authorized re-enable process with verification of the restored state. These are Beta targets, not capabilities the current product already performs.
The program is intended to help us understand what information supports a review and where responsibility becomes unclear. Testing the action and recovery process is also intended to establish what evidence needs to remain. That work gives us a basis for evaluating the workflow before making claims about time savings or broader automation.
Choose one recurring source of work
Choose one of the seven examples that looks familiar and examine a recent case. Follow what each person had to do, including any follow-up after the ticket closed. Separate the review itself from time spent locating information, finding an owner, or reconstructing the record.
Use that case to identify one change worth testing while preserving the review and authorization the decision requires. Governance Economics, Part 2 explains how to establish a baseline and measure whether the process improves.
