Waiver Expiry

A waiver is granted under deadline pressure, for a genuine business reason, by someone with the authority to grant it. Nothing then forces it to end. The approver moves on, the context is forgotten, and the exception persists indefinitely.

Expiry inverts the default: the waiver ends unless someone actively renews it, which forces a periodic decision by someone accountable.

Why accumulation is the real risk

Individually reasonable waivers combine. The accumulated waiver set becomes the actual architecture, and the standard describes a system that does not exist — so the standard stops being a useful description of the estate and the control environment quietly diverges from its documentation.

The aggregate is also invisible without a portfolio view: each waiver was assessed alone, and nobody assessed the combination.

Implementation patterns

• An expiry on every waiver, without exception. A waiver that cannot be time-bounded is a signal that the standard is wrong and should be changed rather than waived.
• A named accepting owner at a level matching the risk, not the requesting engineer.
• A stated compensating control, so the risk is mitigated rather than merely accepted.
• A remediation plan with a date, or an explicit acknowledgement that there is none — which is a different and more honest decision than an aspirational plan nobody will execute.
• Automatic expiry with re-approval required, so continuation is active.
• Aggregate visibility, so the combined position is assessable.
• Waiver rate treated as a defect in the standard. A standard with many waivers is a broken standard — if most teams need an exception, it does not fit reality and should be revised.

Industry example

Governance frameworks that grant no exceptions produce the same outcome everywhere: teams take the risk without telling anyone. The risk is identical and the organisation has lost visibility of it, which is strictly worse than having granted the waiver.

The mature position is that a usable exception path with expiry and visibility converts hidden risk into managed risk, which is the realistic objective. It also keeps the framework honest, because a high waiver rate is measurable feedback that a standard is unfit rather than evidence that teams are non-compliant.

Failure scenarios

• Waivers with no expiry, which become permanent by default.
• The requesting engineer accepting their own risk.
• No compensating control, so acceptance is the whole response.
• No aggregate view, hiding the combined exposure.
• A process so slow that teams bypass it silently, which removes the visibility the process exists for.
• Expiry that renews automatically, which is expiry in name only.

Trade-offs

Expiry creates recurring work: every waiver must be revisited, and a large waiver population generates a continuous review burden. For long-lived legitimate exceptions — a legacy system with a funded decommissioning plan three years out — annual re-approval can feel like ceremony.

The proportionate answer is expiry periods scaled to risk rather than a uniform term, with the highest-risk waivers reviewed most often. What should not vary is that every waiver has an end date and an owner who must choose to extend it.

Interview question

"You inherit a register of four hundred open exceptions, most with no end date. What do you do first, and what does a high waiver rate on one particular standard tell you?"