Sometimes a project genuinely can't follow a standard. The question is whether that deviation is visible and time-boxed — or quietly becomes permanent technical debt. That's what an exception process is for.
Sooner or later a project will have a genuine reason it cannot follow a standard. A regulatory deadline, an acquired system, a vendor constraint, a commercial reality. The standard was still right; this case is still an exception.
The question is not whether deviations happen — they always do. It is whether they are visible and time-boxed, or invisible and permanent. Without a sanctioned route, teams do not stop deviating. They stop telling you, and each undocumented deviation becomes technical debt that nobody has recorded, costed or scheduled.
An exception process is therefore not a weakening of governance. It is the mechanism that keeps governance honest about reality.
Worth separating the two, because they carry different obligations.
| Exception | Waiver | |
|---|---|---|
| Meaning | Temporary permission to deviate, with a plan to converge | Permanent acceptance that this case will not comply |
| Requires | A remediation plan and target date | An accepted, owned residual risk |
| Typical use | "We will fix this in the next release" | "This legacy system will never comply and will be retired in 2029" |
| Approval level | Design authority | Design authority plus risk owner, often executive |
Most requests should be exceptions. A waiver should feel like a significant act, because it is: you are permanently accepting a risk on behalf of the organisation.
Sparse registers are why exception processes decay. The minimum useful record: unique reference; the standard or principle deviated from; the requesting project and a named individual; business justification; the risk created and its rating; approved date; expiry date; remediation plan; risk owner; current status.
The two fields most often left blank are expiry date and risk owner — which is unfortunate, because they are the two that do the work. An exception with no expiry is a waiver nobody admitted to granting. An exception with no named risk owner is a risk the organisation has accepted without anyone accepting it.
Every exception gets an expiry date, without exception. Twelve months is a reasonable default; align it to a release or programme milestone where you can.
What happens at expiry matters more than the date itself. The exception either closes because remediation happened, gets re-approved with fresh justification, or converts into a formal waiver with explicit risk acceptance. What must not happen is silent rollover, because that is how a temporary deviation becomes permanent architecture without anyone deciding it should.
Standing item on every design authority agenda, before new business. Three questions: what has expired, what is approaching expiry, and what has been extended more than twice.
The third is the most revealing. An exception repeatedly extended is usually telling you something structural — either the standard is unrealistic and should change, or remediation was never genuinely resourced. Both are worth knowing.
The register is also one of the more useful governance metrics. Trend of open exceptions, average age, and proportion overdue say more about whether governance is functioning than almost anything else you could report — see governance KPIs.
The Architecture Practice Setup Kit includes an exception & waiver process and a tracking register, as part of a complete governance operating model.
