A Cyber Risk Exception: Approve, Defer or Reject?

The request arrives just before a deadline. A business team needs to launch. A security control is not ready. The proposed exception is temporary, the revenue matters, and someone needs to say yes.

This is where risk governance becomes a decision rather than a policy. The useful question is not whether the security team likes the exception. It is whether the evidence supports a bounded exposure that someone has authority to accept.

Work through one fictional case. The business request stays the same. Change the evidence, the controls and the authority, and the right answer changes with them.

TLDR

• Approve, defer and reject are different decisions. A missing answer does not automatically mean approval or rejection.

• Urgency explains why an exception is being requested. It does not demonstrate that the remaining risk is acceptable.

• Compensating controls need evidence that they work for the exposure in question.

• Acceptance belongs to the authorized owner under the organization's policy, with clear limits, monitoring and review.

• An exception record should make the next decision easier: what must be true to continue, and what would end it?

The fictional request

A distributor wants a temporary integration that lets a supplier update delivery status in its customer portal. The preferred authentication method is not yet available. The business requests a 30-day exception to use a shared credential while the integration team finishes the change.

For this example, assume the organization's policy permits a named executive to accept a time-limited exception within defined tolerance. Assume it also prohibits this integration from accessing payment information or changing bank details. These are fictional policy conditions, not universal rules.

The proposed controls are a separate account with narrow permissions, access restricted to the supplier's approved network addresses, protected credential storage, logging of all updates, and daily review. The service owner says the account can be disabled quickly if something goes wrong.

That is the proposal. It is not yet the evidence.

Approve when the conditions are demonstrated

In the approval branch, testing shows that the account can update delivery status only. Attempts to access payment data or change bank details fail. The access restrictions are in place. The team demonstrates that logging works, assigns the daily review to a named person, and tests disabling the integration.

The authorized executive reviews the remaining exposure and accepts it for a defined window. Approval records the permitted supplier, account, data and actions. It names the control owner, the replacement work owner and the review date. A missed control check, a scope change or a failed replacement milestone triggers a fresh decision.

The logic is specific: the evidence supports a limited use under the fictional policy. It does not establish that shared credentials are a good general design.

Defer when the missing evidence could change the answer

In the deferral branch, the proposed restrictions sound reasonable, but nobody has tested the permissions. Logging exists, yet no one can show that a supplier action reaches the review queue. The integration team says disabling the account should stop access, but that has not been checked either.

The right record is not "approved pending evidence." It is a decision to defer activation until named conditions are met. Assign the tests, name the reviewer and set a decision date. Keep the existing manual process running in the meantime.

Deferral is useful when a small, bounded piece of work can resolve a material uncertainty. It becomes avoidance when the decision has no owner or return date.

Reject when the proposal cannot fit the limits

In the rejection branch, testing finds that the account can also change bank details. The product does not support narrower permissions, and the proposed daily log review would detect an unauthorized change only after it happened. The request therefore conflicts with a policy condition set for this fictional case.

The requested exception should be rejected at that authority level. The business can pursue a different design, keep the manual process, or use the organization's formal escalation route if one exists. A deadline does not expand an executive's authority.

Reject the proposal clearly enough that it cannot return unchanged with a different label.

A three-option decision worksheet

Use this as a working record for the fictional case. Replace the assumptions with your organization's policy, actual evidence and delegated authority.

Decision	Evidence position	Conditions and owner	Next review
Approve	Scope restrictions, logs and shutdown are tested. Residual exposure fits the stated policy and authority.	Named executive accepts; service owner maintains controls; integration owner delivers replacement.	Before expiry, or immediately on a failed control, scope change or missed milestone.
Defer	Permission tests or monitoring evidence are missing and could change the decision.	No activation. Test owner supplies evidence; authorized reviewer makes the decision.	Named decision date after the tests, not an open-ended promise.
Reject	The proposed access breaches a stated policy condition and cannot be narrowed in this design.	Do not activate this proposal. Business owner selects an alternative or follows formal escalation.	Only after a material design change or a decision through the authorized escalation route.

Alongside the worksheet, retain the request, the business rationale, the evidence references and the person who made the decision. Those details let the next reviewer understand what was actually accepted.

What the board should see

The board does not need every permission test. It needs to know whether exceptions are being decided within authority and whether the conditions remain true.

• Which accepted exceptions sit closest to the organization's limits?
• Which decisions are deferred because material evidence is missing, and how old are they?
• Which approved exceptions have missed a condition or replacement milestone?
• Who can stop the affected activity, and has that authority been tested in practice?
• Are rejected requests reappearing unchanged elsewhere?

NIST's enterprise risk guidance treats acceptance as a risk response within tolerance and emphasizes monitoring. It also distinguishes acceptance from mitigation and avoidance. The approve-defer-reject worksheet here is a practical decision aid, not a substitute for that broader risk process.

Sources

NIST, Prioritizing Cybersecurity Risk for Enterprise Risk Management (2025 update), risk response and risk owner sections: NIST IR 8286B-upd1. All organizations, policy conditions and events in the case above are fictional.

Frequently asked questions

What makes a cyber risk acceptance decision defensible?

A clear description of the exposure, relevant evidence, an authorized decision-maker, documented limits and a way to monitor whether the conditions remain true. The amount of detail should reflect the stakes. A signature alone does not show what was understood or accepted.

Is deferring an exception the same as approving it conditionally?

No. In this example, deferral means the proposed activity cannot start until the evidence is reviewed and approval is given. Conditional approval must state exactly when activation is permitted, who confirms the conditions, and what happens if they fail. Ambiguous wording creates an approval nobody intended.

Can compensating controls justify an exception?

They can support a decision when they address the relevant exposure and there is evidence they work. A daily review, for example, may detect a problem but cannot be assumed to prevent it. Evaluate the control against the scenario rather than counting how many controls are listed.

Who should sign a risk acceptance?

The person or body with the delegated authority to accept that exposure under the organization's policy. Technology and security teams should explain the evidence and options. The decision must stay within the approver's limits; requests beyond them follow the formal escalation route.

Closing

The same urgent request can deserve three different answers. Approve when the evidence supports the limits. Defer when a material question can be answered. Reject when the proposed design cannot fit the permitted exposure. Write down why, who owns the next step, and when the decision comes back.