Grant an exception to an architecture standard
Draft
Grant an exception to an architecture standard, within the delegated band
Grant an exception to an architecture standard, at or above the delegated band
Allocation
| L2-06 | L2-07 | |
|---|---|---|
| Decides | Head of Enterprise Architecture | Head of Risk |
| Consulted | Architecture Review Board | Head of Enterprise Architecture and CISO |
| Executes | Engineering | Engineering |
| Evidence | Time-bounded exception record with expiry and named remediation owner | Risk acceptance record in the risk register, not the exception register |
| Delegated band | Delegated | Delegated |
In plain terms
Permit a departure from an architecture standard. Below the band it is an architectural decision. At or above it, the same departure is a risk acceptance and leaves the layer.
What is being judged
Whether the departure is temporary and contained, and on which side of the band it falls.
The band is defined by the control catalog, not by a number. An exception routes to the Head of Risk where it removes, defers or weakens a control the catalog marks required for the affected system’s consequence class. Everything else stays with architecture. The band therefore moves automatically when the catalog changes, which is a property worth knowing when editing the catalog.
Three things make an exception survivable. An expiry that is real, meaning a date by which the departure ends rather than a date by which it is reviewed. A named remediation owner, a person rather than a team. A stated reason, because an exception whose justification is unrecorded cannot be reassessed when circumstances change.
What this decision does not cover
It does not change the standard. An exception granted repeatedly for the same reason is evidence the standard is wrong, and that belongs at L2-03.
When it fires
On event. When a design cannot meet a published standard and the work is proceeding anyway. At expiry, where continuation is sought. When a control catalog change moves a previously in-band exception above the band.
On cycle. Register reviewed monthly, reported to Layer 4 quarterly.
What you need before deciding
Which standard and which specific requirement. Whether a control in the mandatory catalog is affected, which decides the side of the band. The consequence class of the affected system. What remediation requires and by when.
How this goes wrong
Architecture as a risk channel: exceptions granted at a level that materially accepts risk, recorded in an architecture artifact, never reaching the risk register. Layer 4 believes the catalog is being applied. The Layer 2 anti-pattern, and the reason the band exists. The permanent exception: entries years old with expiry dates in the past and no remediation owner. The exception has become the standard without anyone deciding it should. Expiry as review date: a date on which someone will look, which produces indefinite extension by default.
Related decisions
Band defined by L4-POL-03 control catalog.
Threshold Layer 4 §5A architecture exception risk band.
Upstream L2-03 technology selection.
Downstream the exception register, reported to Layer 4.
Instrument references
TOGAF provides architecture governance and a compliance process including dispensations. It does not distinguish an architectural dispensation from a risk acceptance, which is the distinction this band draws.
Correction
The maintainer answers corrections. There is no service level. Responses are best-effort and opportunistic within a reasonable time: a correction raised on a Monday is answered that week or sooner.