🧾 Policy Exception Governance Pack
Intro: Exceptions are not evidence of failure. Uncontrolled exceptions are. This page explains how to make temporary risk acceptance visible, reviewable, and short-lived.
The rule
Every exception should have:
- an owner
- a reason
- a scope
- an expiry date
- a compensating control if needed
- a reviewer
Exception fields
| Field | Why it matters |
|---|---|
| exception_id | lets you track and discuss a specific risk decision |
| control | shows what standard or rule is being bypassed |
| asset / service | makes scope explicit |
| owner | creates accountability |
| justification | explains why the exception exists |
| expiry | prevents silent permanence |
| compensating controls | shows what reduces risk in the meantime |
| approver | documents decision authority |
Good reasons for exceptions
- platform dependency not yet ready
- vendor constraint
- migration in progress with committed retirement date
- release-critical business event with defined fallback controls
Weak reasons
- “it breaks the app”
- “we did not have time”
- “the scanner is annoying”
- “the team said it is fine”
Governance rhythm
- weekly review for new critical exceptions
- monthly review for aging exceptions
- quarterly review for exception volume and repeat classes
Metrics
- total open exceptions
- exceptions older than policy
- average exception age
- exceptions by business-criticality
- repeat exceptions by control