A risk register lists risks the organisation is managing, with likelihood, impact and treatment. An exception register lists approved departures from a specific policy or standard, with an expiry. An exception usually creates or increases a risk, so the two should be linked, but they are not the same document.
Two questions, two registers
The risk register answers: what could go wrong, how bad, and what are we doing about it? The exception register answers: where are we knowingly not following our own rule, who approved it and until when?
For example, a policy says critical findings close within 15 days. A team cannot meet that for a legacy service. The exception register records the deviation. The risk register may hold an entry for the underlying exposure of that service.
Side by side
| Aspect | Risk register | Exception register |
|---|---|---|
| Unit | A risk | A deviation from a named rule |
| Triggered by | Assessment, incident, change | A request that cannot meet a policy |
| Key fields | Likelihood, impact, owner, treatment | Rule, reason, approver, compensating control, expiry |
| Lifetime | Until risk is closed or retired | Short, with a hard end date |
| Reviewed | Periodically | At expiry and when conditions change |
| Audience | Leadership, auditors | Policy owners, auditors |
How they link
- Each exception references the policy it deviates from.
- Each exception points to a risk entry, or creates one when the exposure is material.
- The risk entry shows the exception as part of its treatment, with the approval date.
- When the exception expires, the risk is re-scored.
Why keep them separate
Policy owners need to see how often a rule is being bypassed, since many exceptions to one rule suggest the rule is wrong. Risk owners need to see exposure regardless of why it exists. Merging both into one list makes it hard to answer either question.
Starter fields for the exception register
- ID and date
- Policy or standard reference
- Scope: assets or teams
- Reason
- Compensating controls
- Approver and date
- Expiry date
- Evidence links
- Status: active, renewed, expired, closed
Reporting
Show leaders the count of active exceptions, those expiring within 30 days, those expired and not closed, and the policies with the most exceptions. The last list is where you improve policy.
Quick check
Can one spreadsheet serve as both registers?
It can start that way, but keep separate tabs or views, since the fields and review cycles differ.
Does every exception need a risk entry?
Not every one, but any exception that leaves material exposure should link to one.
Safeguard supports this with policies, gates and compliance evidence automation, and you can run a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.