When a Cyber Risk Exception Should Expire

Every security program has exceptions: the system that cannot be patched this quarter, the vendor that missed the assessment deadline, the legacy app that stays connected a little longer. Handled well, an exception is a time-boxed, visible trade-off. Handled badly, it is a quiet, permanent acceptance of risk that nobody remembers approving.

The difference is not the risk itself. It is whether the exception has an expiry date, a named owner, and a forced decision at the end.

TLDR

• Approve no exception without an expiry date, a named accountable owner, and a compensating control.

• Expiry forces one of three decisions: renew with fresh evidence, close, or escalate. Silence is not renewal.

• Set the window from how fast the risk changes, not from the calendar. 60 or 90 days suits most cases; internet-facing and fast-changing risks need less.

• A repeated exception on the same control is a finding about the control, not a routine renewal.

• The board should see overdue and repeated exceptions and the decisions requested, not the full register.

Temporary by approval, permanent by neglect

Most exceptions are reasonable on the day they are granted. The business case is real, the compensating control is adequate, and everyone expects the fix to land next quarter. Then the quarter slips, the owner changes roles, and the exception record sits untouched. Nothing decided to keep the risk. It simply never came due.

This is why the expiry date matters more than the approval. Approval documents intent once. Expiry forces the organization to keep choosing the risk on current evidence, or to stop choosing it.

What an exception record must contain

An exception that cannot be inspected cannot be governed. Before approval, the record should carry six fields:

• Accountable owner: one named executive, not a team.
• Business rationale: the specific outcome that justifies the exposure, stated plainly.
• Residual risk: what can still happen after compensating controls, in business terms.
• Compensating controls: what is actually reducing the risk today, and who operates them.
• Expiry date: a date, not a quarter or a phase.
• Evidence required for renewal: what must be true, and shown, for anyone to extend it.

If any field is empty, the exception is not ready to approve. An owner who cannot state the renewal evidence is asking for an open-ended acceptance.

Set the expiry from the risk, not the calendar

Sixty or ninety days fits most exceptions because it matches how often the underlying facts move. Shorten the window when the exposure is internet-facing, when the compensating control is manual, or when the affected system is mid-change. Lengthen it only when the fix date is contracted and the control environment is stable.

Two tests keep the window honest. First, would you still grant this exception if it came to you new today? Second, what would have to be true for you to say no? The answers set both the expiry and the renewal evidence.

At expiry: renew, close or escalate

Expiry is a decision point, not a reminder. Renewal requires the fresh evidence named in the record: the rationale still holds, the compensating controls still operate, and the residual risk is still within appetite. Renewal by copy-paste is how exceptions become permanent with better paperwork.

Closure needs proof the underlying condition is gone, not just the passage of time. Escalation is the right outcome when the risk has grown, the controls have weakened, or the same exception is being renewed a second or third time. A repeat exception is telling you the fix is not funded or not possible. That is a decision for a more senior level, not another 90 days.

A worked example (fictional)

A mid-size manufacturer grants a 90-day exception for a legacy vendor VPN that lacks multifactor authentication. The record names the COO as owner, cites a contract renewal as the rationale, lists restricted access and enhanced logging as compensating controls, and requires a migration plan as renewal evidence.

At day 90 the migration is not done. Because the record named the evidence in advance, the review is short: the migration plan exists but is unfunded, so the exception escalates to the executive committee, which funds the migration and grants a final 60-day exception with a hard end date. The expiry turned a drifting gap into a funded decision.

What the board should see

Directors do not need the exception register. They need four things: the count of open exceptions against trend, anything past its expiry date, repeats on the same control, and the decisions management is requesting. A dashboard that shows those four lines turns exceptions from an audit footnote into a live view of where the business is choosing to carry risk.

If management cannot produce that view, the useful board question is simple: which risks are we carrying right now that nobody has chosen recently?

Frequently asked questions

How long should a cyber risk exception last?

Long enough to fix or formally accept the risk, and no longer. Sixty to ninety days suits most cases. Internet-facing exposure or fast-changing systems justify shorter windows.

Who should own a risk exception?

One named executive who owns the business outcome the exception protects. Security advises and tracks; the business owner carries the risk and the renewal decision.

When does an exception need board attention?

When it is overdue, when it repeats on the same control, when the residual risk is material, or when renewal would mean accepting a risk above appetite. Routine, in-appetite exceptions belong with management.

Is an exception the same as risk acceptance?

An exception is a time-boxed acceptance with conditions and a forced review. Without the expiry and the renewal evidence, it becomes permanent acceptance by default, which is a governance gap rather than a decision.

A Defensible Next Step

An exception register with expiry dates is a record of decisions your organization is willing to defend. One without them is a list of risks nobody is watching. If your register has entries older than their fixes, book a Decision-Clarity Call and we will turn it back into a decision tool.