Every risk acceptance needs an expiry date

A risk ac­cep­tance is one of the most hon­est doc­u­ments in a con­trol en­vi­ron­ment. Some­one looked at a gap, weighed the cost of fix­ing it, and made a de­ci­sion on the record. The trou­ble starts when that de­ci­sion out­lives the con­di­tions it was made under, and no­body no­tices.

What I’m seeing

In au­dits I have led, open risk ac­cep­tances were rarely the prob­lem. Old ones were. An ex­cep­tion ap­proved for a sys­tem that was “being de­com­mis­sioned next quar­ter” is still ac­tive long after that quar­ter. A com­pen­sat­ing con­trol that jus­ti­fied the ac­cep­tance was changed or re­moved. The ap­prover moved to an­oth­er role, and the ac­cep­tance now has no liv­ing owner.

The com­mon thread is that ac­cep­tance was treat­ed as an event rather than a sta­tus. It was signed, filed, and closed in the track­ing tool, when in fact it should have stayed open as a de­ci­sion that needs to be re­newed.

Some signs that ac­cep­tances have drift­ed:

• No end date, or an end date that rolls forward automatically. If renewals happen without anyone reconsidering the risk, the expiry date is decoration.
• The original rationale no longer holds. The acceptance cites a migration, a vendor fix, or a budget cycle that has already come and gone.
• Compensating controls that are named but not tested. The acceptance depends on a control that no one has evidenced since the day it was approved.
• Acceptances that are invisible in reporting. The control dashboard shows green because the exception removed the gap from the count.

That last one de­serves at­ten­tion. An ac­cept­ed risk is still a risk. If it dis­ap­pears from the pic­ture lead­ers see, the or­ga­ni­za­tion has ef­fec­tive­ly de­cid­ed to stop look­ing at it.

Why it matters

Risk ac­cep­tance is a le­git­i­mate and nec­es­sary tool. Not every gap can be fixed im­me­di­ate­ly, and pre­tend­ing oth­er­wise just dri­ves ex­cep­tions un­der­ground. The point is not to ac­cept less. The point is to make sure every ac­cep­tance is still a de­ci­sion some­one would make today.

An ex­piry date does that work. It forces a mo­ment when the owner has to look again: Is the risk the same size? Is the com­pen­sat­ing con­trol still work­ing? Is the re­me­di­a­tion plan still real? If the an­swer is yes, re­new­al is quick. If the an­swer has changed, you find out on a sched­ule rather than dur­ing an in­ci­dent or an exam.

It also pro­tects the per­son who signed. An ap­prover who ac­cept­ed a risk for twelve months, with stat­ed con­di­tions, made a de­fen­si­ble de­ci­sion. An ap­prover whose ac­cep­tance has silent­ly run for years is now at­tached to a de­ci­sion they may not re­mem­ber mak­ing.

Frame­works such as NIST CSF 2.0 treat risk man­age­ment as an on­go­ing cycle, with risk ap­petite and tol­er­ance re­vis­it­ed as con­di­tions change. A risk ac­cep­tance with no ex­piry falls out­side that cycle by de­sign.

What to do this week

1. Pull the full list of active risk acceptances and sort by age. Include anything labeled exception, waiver, or deviation. Flag every item with no end date and every item past its original end date.
2. Re-test the compensating controls on the five oldest. For each, ask for current evidence that the compensating control operated, not the evidence from the original approval. If none exists, the acceptance rests on an assumption.
3. Make expiry a required field going forward. Set a maximum duration in your policy, require a named owner and the conditions that would trigger early review, and have renewals come back to the approver with the original rationale attached.

A question for your next meeting

“Which risk ac­cep­tances are older than the peo­ple who ap­proved them have been in their cur­rent roles?”

The an­swer shows you quick­ly which de­ci­sions are still owned and which ones are sim­ply still on file.

Until next time,

Nath

---

The Ev­i­dence Brief shares prac­ti­cal per­spec­tives on tech­nol­o­gy risk, audit, and AI gov­er­nance. It is gen­er­al in­for­ma­tion, not legal or reg­u­la­to­ry ad­vice.