A platform team introduces time-boxed waivers so that teams can ship against a policy exception with a stated expiry rather than waiting for a fix. Delivery speeds up. What has the organisation given up, and when does that bill arrive?

What is gained

A policy that can be temporarily unmet stops being a policy that gets deleted. Before waivers, a control that blocks delivery has two outcomes: the team waits, or the control is weakened for everyone. The waiver adds a third — this team, this exception, until this date — which lets the standard stay strict.

It also converts invisible non-compliance into a register. The exceptions were always there; now they have an owner, a reason and a date.

What is paid

• A queue of expiries nobody funded. Each waiver is a commitment to do work later, and the later work competes with whatever is urgent then. A hundred waivers is a hundred future interruptions with no allocated capacity.
• Expiry becomes a bluff that gets called. The first time a waiver lapses and nothing happens — no block, no escalation — every subsequent expiry date becomes advisory. The mechanism's credibility is spent in one event.
• Renewal as the default path. Renewing is cheap and fixing is not, so a waiver register left alone converts into a permanent exceptions list with dates on it.
• Aggregate risk nobody owns. Each waiver is individually defensible; forty simultaneous waivers against the same control mean the control is not in force, and no single approval decision ever considered that.

When the bill arrives

At about the second or third renewal cycle, when the register is large enough that nobody reads it end to end and the expiry dates cluster. It also arrives at audit, where a register of expired waivers is worse evidence than no register, because it documents known non-compliance that was not acted on.

How to keep the option to reverse

• Make expiry mechanical. The waiver is a configuration with an end date, and at that date the gate blocks. If expiry requires a human to act, it will not happen.
• Cap the number of concurrent waivers per control, which forces the aggregate question at grant time rather than at audit time. When the cap is hit, the honest conclusion is usually that the control is wrong.
• Require a named remediation and a funded slot, not an intention. "We will fix this in Q3" without a Q3 commitment is a renewal with extra steps.
• Report waivers by control rather than by team, because the signal that matters is a control with forty exceptions, not a team with three.

When not to introduce waivers at all

Where the control protects against an irreversible harm — money movement, personal-data disclosure, safety — a waiver is a decision to accept that harm for a period, and it should be escalated as such rather than processed. Some controls should simply have no waiver path, and saying so in advance is cleaner than relying on an approver's judgement under delivery pressure.

And where a control has many waivers, do not improve the waiver process. Forty exceptions is evidence about the control, not about the teams. Fix the control, and the waivers disappear along with the process that managed them.

The failure to watch for while the register is young is quiet expiry: a waiver lapses, the gate does not block, and nobody notices for 90 days. That single event costs the mechanism its credibility and is the reason mechanical expiry matters more than the approval workflow around it. Exception registers have been a standard requirement in security certification schemes since 2005, and the register that documents unremediated expiries is worse audit evidence than no register at all.