Exception Register

A standard with no exception route is not followed; it is violated silently. Teams face legitimate cases the standard did not anticipate, and without a sanctioned route they take the unsanctioned one — after which the organisation neither knows the deviation exists nor why.

An exception register makes deviation visible and deliberate, which is a better outcome than either enforcement or unrecorded violation.

Why it matters

It provides two things nothing else does. First, an accurate picture of the estate, since the standard plus the register is the truth while the standard alone is an aspiration. Second, feedback on the standard itself: thirty exceptions means the standard describes the wrong rule, and that signal only exists if exceptions are recorded rather than improvised.

Implementation patterns

• A named approver at a level appropriate to the risk, so approval is a real decision rather than a formality.
• A written rationale, which is what a future reader needs and what makes the pattern of exceptions analysable.
• A review date, so an exception granted for a temporary reason expires rather than becoming permanent.
• Time-bounded by default. A permanent exception should be an explicit choice, and its accumulation should prompt a change to the standard.
• Reviewed in aggregate periodically, looking for clusters. A cluster of exceptions on one standard is a standard that needs rewriting, not a compliance problem.
• Fast to obtain. An exception process that takes three weeks will be bypassed, which returns the organisation to silent violation with extra ceremony.

Industry example

Identity and security-sensitive platforms such as Okta and WorkOS carry standards where deviation has real consequences and where legitimate exceptions genuinely occur — an integration with a partner whose system predates a protocol, a customer whose regulatory environment requires something unusual.

The register is what allows both the standard to be strict and the business to be served, which is the combination a strict-with-no-exceptions policy cannot achieve.

Failure scenarios

• No exception route, producing silent violation and an inaccurate view of the estate.
• A slow process, bypassed for the same reason.
• Exceptions with no expiry, accumulating until the standard describes a minority of systems.
• No aggregate review, so the standard is never corrected by the evidence that it is wrong.
• Approval by the requesting team, which makes the register a log rather than a control.

Trade-offs

An exception process is administrative overhead on a team already dealing with an awkward case, and it can become a bottleneck if the approver is scarce.

The mitigation is proportionality: exceptions for high-consequence standards need real approval; exceptions for lower ones can be self-declared with a record. The record is the essential part — the approval is the part that can be scaled down where the risk permits.

Interview question

"Your database standard has been granted twenty-two exceptions in eighteen months. What does that tell you, and what do you do about it?"