Exceptions to standards are granted and accumulate indefinitely. What should the waiver process look like?

Why exceptions accumulate

A waiver is granted under deadline pressure with a genuine business reason, and nothing forces it to end. There is no expiry, no owner after the original approver moves on, and no review. Years later nobody knows why it exists or whether the underlying condition still applies.

The accumulated waiver set becomes the actual architecture, and the standard describes a system that does not exist.

What the process needs

• 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.
• Visibility of the aggregate. Individually reasonable waivers can combine into an unacceptable position, and nobody sees that without a portfolio view.
• Automatic expiry with re-approval required, so continuation is an active decision rather than the default.

The signal to act on

A standard with many waivers is a broken standard. If most teams need an exception, the standard does not fit reality and should be revised — treating the waiver rate as a defect in the standard rather than as non-compliance by teams is what keeps the framework honest.

The relationship to trust

A process that grants no exceptions gets bypassed silently, which is strictly worse: the risk is taken and nobody knows. A usable waiver path with expiry and visibility converts hidden risk into managed risk, which is the realistic objective.