Seeing Risk Is Not the Same as Governing It

A dashboard can show that a user has administrator access. To decide whether that access is appropriate, a reviewer may also need the person’s current responsibilities, the policy that applies, and any approved exception. The organization needs to establish who can make that decision and what should happen afterward.

Security visibility supplies evidence for that review. A directory shows a role assignment, logs show activity, and a scanner may identify a configuration that deserves attention. Those observations help the team understand the environment. What happens next depends on the organization’s policies, the context of the finding, and who is responsible for deciding.

Governance defines how decisions are made

The NIST Cybersecurity Framework 2.0 includes a Govern function covering risk-management direction, policies, responsibilities, and oversight. These expectations guide the organization’s security work before a particular finding appears. An access review shows how they apply to a specific account. NIST

For privileged access, a policy might define who can hold a role, who can approve it, and when it needs another review. The person evaluating the account then needs to compare the evidence with those expectations. If the access falls outside them, the organization needs a way to decide whether to change it or consider an exception.

A technical record and a documented decision serve different purposes. The record may establish that access exists. The decision explains why it should remain or change, who had authority to decide, and what follow-up is required.

Give the finding an owner

An access review can involve several people with different responsibilities. Security may identify the condition, while a manager understands the business requirement. An application owner may know what would be affected by removing access, and IT may control the system where the change would occur.

That division of work can be appropriate. It becomes difficult when responsibility is left for people to work out after every finding. A reviewer may assume an application owner is handling the issue, while the application owner is waiting for a decision from security. Both can see the finding without either owning the next step.

The process should identify who reviews the evidence and who can authorize the response. Other people may contribute context or carry out a change, but their participation should not leave the decision unassigned. When more information is needed, someone should remain responsible for obtaining it and returning the issue for review.

Read identity evidence in context

Consider a privileged account with no recent activity in the records being reviewed. That observation may justify investigation, but it does not establish that the owner has left the organization or that disabling the account is appropriate. The review needs to distinguish the activity evidence from the conclusion being considered.

The account may belong to a current employee, support an infrequent process, or hold privileges approved for a particular business requirement. A manager or application owner may have information that does not appear in the directory. An earlier review or exception may explain why the access was retained.

Record those answers alongside the finding. When an answer is still missing, leave the uncertainty visible rather than turning it into an assumption. The responsible person can then decide whether the access should remain, change, or receive further investigation.

A decision to retain access needs a record too

Access can be unusual and still meet the organization’s policy. Someone may have responsibilities that require permissions their colleagues do not need. A review should establish that reason rather than treating every difference as a risk that must be accepted.

An identified risk that the organization deliberately chooses to accept is a different decision. NIST’s framework guidance recognizes acceptance as one possible risk response. That choice needs to be made within the organization’s decision rights and risk tolerances, rather than occurring by default because an item was left unresolved. NIST

Suppose a team identifies an access condition that cannot be changed until an application migration is complete. Where policy permits a temporary exception, the authorized decision should record why the access is being retained, what risk was considered, and who owns the follow-up. A review date or a defined event should bring the decision back for consideration.

That record matters even when nothing changes in the system. It lets another reviewer distinguish access that was evaluated and deliberately retained from access that simply escaped attention.

Keep the record useful between reviews

A scheduled access review captures a decision made with the information available at that time. If someone changes roles afterward, the earlier approval may no longer answer whether the same permissions are appropriate. The team needs a way to recognize that change and revisit the relevant decision.

The record should help with that work. A later reviewer needs to understand why access was granted or retained, which policy applied, and whether a condition was supposed to trigger another review. A note saying “review complete” may leave all of those questions unanswered.

The same information can support an audit or an internal inquiry. Keeping the reasoning with the review gives people something to examine without asking the original participants to reconstruct the decision from memory.

From finding to verified outcome

We describe the intended workflow as Find → Decide → Fix → Verify. A finding identifies a condition for review. The decision establishes the appropriate response, and a change moves through authorization and execution when one is needed. The team then checks the source system to see whether the observed result matches what was intended.

Those stages should stay connected through the record. The person carrying out a change needs to know what was approved. The verification should identify what was checked, when the check occurred, and whether the result matched. An unclear or unsuccessful check needs follow-up rather than being recorded as a confirmed outcome.

A decision to retain access should be recorded as that decision, not as completed remediation. Operational Zero Trust examines how the finding, decision, authorized action, and verification record can stay connected.

Where TPZ is starting

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 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.

Review a decision where nothing changed

Choose one recent finding where the team decided to retain the flagged access. Check whether the record explains the reason, identifies who was authorized to decide, and states whether another review is needed. It should be possible to distinguish access that meets policy from an exception the organization has deliberately accepted.

Ask someone who was not involved in the original review to read that record. Note what they still need to ask before they can understand the decision. Those missing answers show what the process needs to preserve the next time a finding is closed without a technical change.