Exception and Waiver Management
The formal process for permitting a deviation from a standard, with a named risk owner, a stated expiry and a remediation plan.
Every standards regime needs an exception path, because a standard with no exceptions is either trivial or ignored. The quality of the exception process determines whether standards mean anything.
The elements that make a waiver legitimate rather than a permanent hole. A named accepting owner at a level appropriate to the risk — the accountability must sit with someone who can be asked about it later, not with the team that wanted the deviation. A stated risk in specific terms rather than "does not meet standard 4.2". Compensating controls where available. An expiry date, and a real one. And a remediation plan with an owner.
The pathology to watch for is waiver accumulation. Organisations reach a state with hundreds of open exceptions, most expired, none tracked, and the standard has quietly become optional. At that point the register is a catalogue of accepted risk that nobody has aggregated, which is the exposure the governance function exists to prevent.
Two disciplines prevent it: expiry that actually triggers review rather than lapsing silently, and periodic aggregate reporting — the total count and the risk-weighted picture, reported upward. The individual waivers are each defensible; the aggregate is frequently not, and only the aggregate prompts the investment that fixes the underlying cause.
The signal worth acting on: when the same exception is requested repeatedly, the standard is wrong or the paved road is missing a capability. That is a backlog item, not a waiver.