Exception Register

Every control eventually meets a case where it is genuinely wrong: a legacy system that cannot support the required authentication, a workload whose latency budget cannot absorb the mandated encryption, a team whose regulatory deadline precedes the standard's rollout.

How the organisation responds to that case determines whether the control survives. With no exception path, the control is deleted, worked around, or routinely overridden — and the deviation becomes invisible, which is strictly worse than an approved one.

Exceptions are therefore not a weakness in a control regime; they are what makes it possible to have controls that bind at all.

Why it matters

The aggregate is the most valuable diagnostic a governance function produces. A control with forty exceptions across forty teams is not being violated — it is a control that does not fit reality, and the correct response is to fix the control rather than to keep granting relief. A control with none may be too weak to bind, which is equally worth knowing.

Without a register, neither signal exists. Deviations are granted verbally, inherited through copied configurations, and accumulate until the exceptions are the practice and the documented control describes a system nobody is running.

Implementation patterns

• A stated scope: exactly what is exempted and nothing broader, since a vague exception becomes a general one.
• A named owner in the team carrying the risk, and a named approver with authority proportionate to it — not whoever was available.
• A compensating control where one exists, because an exception need not mean an unmitigated risk, and recording the compensation is what makes the acceptance defensible.
• A mandatory expiry, with renewal requiring a fresh decision rather than being automatic. An exception with no expiry is a permanent change to the control that nobody decided.
• A linked remediation item with a date, or the underlying reason never gets fixed and the exception is renewed indefinitely.
• Recorded in the same system as the control, so coverage figures are honest rather than flattering.
• Detected rather than only declared: automated checks should identify deviations that were never registered, since the unregistered exception is the one that matters.
• Reviewed in aggregate on a cycle, looking for the many-teams-same-exception pattern.

Industry example

The practice is standard in regulated environments and increasingly in platform engineering, where the same structure appears as override tracking on automated gates. The signal is treated identically: a gate overridden routinely should be fixed or demoted to a warning, and a rule with no override path is deleted the first time it is genuinely wrong.

The connection is worth making explicit. Automated policy enforcement and formal exception management are the same mechanism at different levels of formality — a rule, a way to deviate, a record of who deviated and why, and an expectation that the aggregate is examined. Organisations that do the first without the second discover that their compliance figures describe a system where deviation is invisible rather than absent.

Failure scenarios

• No expiry, making exceptions permanent by default.
• Granted informally, so they are unrecorded and uncountable.
• Approved by whoever was available, rather than by someone accountable for the risk.
• No remediation attached, so the reason persists and the exception renews forever.
• No aggregate review, so the many-teams-same-exception signal is never seen.
• Inherited silently through templates and copied configurations, spreading without any decision.
• Renewal as a formality, which is the same as no expiry.
• Unregistered deviations undetected, so the register describes only the honest teams.

Trade-offs

A rigorous exception process adds friction at exactly the moment a team is already blocked, and a slow or bureaucratic one is routed around — producing unregistered deviations, which is the outcome it exists to prevent. The process must be genuinely fast, or it defeats itself.

There is also a real risk of exceptions becoming an alternative compliance path: a team that finds the exception easier than the control will take it, and the register grows while the control's coverage falls. Expiry and remediation requirements are the defence, and they must actually be enforced.

The trade is process overhead and the risk of an easier path in exchange for deviations that are visible, owned and time-bounded. For any control that binds, the alternative is not full compliance — it is invisible non-compliance, which is worse in every respect including the audit.

Interview question

"Forty teams have an exception to our mandatory encryption standard. Tell me what that tells you, what you would do about it, and what you would change so that the next control does not end up in the same place."