An exception is a decision to accept a known deviation for a stated period. It is not an absence of a control and it is not a backlog item. Recorded properly it is a sign of a governed programme; recorded loosely it is how an organisation grants its way into a false appearance of compliance.
The record
| Field | Entry |
|---|---|
| Rule or clause | The specific clause identifier being excepted. Not a policy name. |
| Linked finding or risk | The record carrying the exposure. An exception is not a replacement for it. |
| Scope | Which systems, people or business units. An exception without a boundary is a policy change. |
| Owner | The person accountable for the exposure while it stands. |
| Rationale | Why the deviation is being accepted. Cost and inconvenience are legitimate reasons; they just have to be written down. |
| Compensating measure | What reduces the exposure meanwhile, or explicitly: none. |
| Compensating-measure evidence | How its operation will be checked, by whom and when. |
| Current appetite position | Within · in breach · cannot be assessed. Approval does not change this state. |
| Approver | Who accepted it. A named person, not a committee. |
| Granted | Date. |
| Expiry | Date. Mandatory. See below. |
| Review | Date, ahead of expiry. |
| Renewal count and cumulative age | Preserved across successor records. |
Expiry is mandatory, and this is the whole point
An exception without an expiry date is not an exception. It is an unrecorded policy change with better paperwork.
The expiry date does one thing that nothing else does: it forces the exposure back in front of a named person on a known date. Everything else in this record is documentation. The expiry is the control.
Lapse behaviour must be decided when the exception is granted, not when it expires. On the expiry date, one of three things happens, and which one is chosen in advance:
- the deviation is remediated
- the exception is renewed, as a new record with a new approver and a new expiry
- the exception lapses and the deviation becomes a finding again
An exception that quietly persists past its expiry is worse than one never recorded, because the record makes it look governed.
Renewal is not a reset. A renewed exception creates a successor record and retains the original grant date, prior approvers, total elapsed age and reasons for each renewal. Repeated short renewals must not disguise a permanent deviation.
Approved exceptions stay in the denominator
This is the rule most likely to be argued with, so it is stated plainly.
When maturity is computed, approved exceptions remain inside the eligible population. They are not removed from the denominator, and they do not improve any score.
The reason: if exceptions were excluded, an organisation could raise its measured maturity by granting itself more of them. The instrument would reward exactly the behaviour it exists to surface. So an exception is visible, governed, and counted, which is the correct treatment of a decision to accept risk.
The same rule applies to appetite reporting. An approved exception does not automatically place its underlying risk within appetite. The risk retains the appetite state supported by its measured residual; acceptance of the exception is a separate governance decision.
What this record is currently missing in the platform
Stated honestly rather than hidden.
Exceptions are presently held as risk records carrying a free-text category. The fields above exist, but there is no first-class exception entity, and there is no automatic expiry or lapse behaviour. An exception that passes its expiry date will not currently raise anything on its own.
Until that is built, the expiry date works only if someone reviews the list. If you are relying on exceptions in a regulated context, review them on a calendar rather than trusting the platform to prompt you.
Industry basis and IO position
Risk-acceptance and exception processes are normal parts of ISO/IEC 27001, NIST-based governance and enterprise risk management. IO does not treat an exception as failure by definition; the distinctive rule is that approval does not erase the exposure, improve maturity or manufacture an appetite result. The exception governs the deviation while the linked risk and evidence remain visible.
References: NIST CSF 2.0 (opens in a new tab) · ISO/IEC 27001 (opens in a new tab) · ISO 31000 (opens in a new tab)