An exception register is a table of approved departures from your own security requirements, each with a reason, approver, compensating control and review date. Several SSDF examples (PO.1.2, PO.1.3, PW.1.2 and RV.2.2) call for a process to handle exceptions and review them periodically.
Where the SSDF mentions exceptions
- PO.1.2 example: establish and follow processes for requirement exception requests, including periodic reviews of all approved exceptions.
- PO.1.3 example: a process to address risk when third-party components do not meet your requirements, with periodic review of approved exceptions.
- PW.1.2 examples: record rationales for approved exceptions and periodically re-evaluate them.
- RV.2.2 example: update records of design decisions, risk responses and approved exceptions.
One register can serve all four.
Fields to include
| Field | Notes |
|---|---|
| ID | A stable reference |
| Requirement affected | Which of your policies is not met |
| Scope | Product, service or supplier |
| Reason | Why it cannot be met now |
| Risk assessment | Brief, with exposure and impact |
| Compensating control | What reduces the risk meanwhile |
| Approver and date | Someone with authority over the risk |
| Review date | Required, with a maximum interval |
| Status | Open, renewed, closed |
Rules that keep it honest
- No exception without a review date.
- A maximum duration, so renewals need a fresh decision.
- The requester cannot be the sole approver.
- Renewals state what changed or why nothing did.
- Closing an exception links to the fix.
Review routine
Once a month, sort by review date and handle anything due in the next 30 days. Once a quarter, give leadership a short summary: count open, count overdue, oldest item. This also supports the leadership commitment in PO.2.3.
What buyers like to see
A register with a handful of well-documented entries is a sign of a working process. An empty register is suspicious, and an old register with expired dates is worse. Share a redacted extract when asked.
Avoid these traps
- Verbal approvals that leave no record
- Exceptions granted to meet a launch date that never get reviewed
- Free-text fields that just say "business need"
- Mixing risk acceptance for vulnerabilities with requirement exceptions and losing track of which is which
If you need both, use a type column.
Starting from nothing
If you have no register today, begin by asking each team lead for known departures from your security rules. Expect a handful. Enter them with honest reasons, even where the reason is that nobody got to it. Then assign owners and dates. Within a month you will have a register that reflects reality, and the open entries become a natural backlog for improvement.
Quick check
Is a spreadsheet enough?
Yes for a small team, if changes are tracked and access is limited. A ticket system with a label works too.
How long should an exception last?
Set a maximum in your policy that fits your risk. Many teams choose a short period for high-risk items and longer for low-risk ones.
Safeguard's policies and gates can help show where checks apply, and exceptions can be tracked alongside. The free scan is at gold.safeguard.sh/scan.
Sources
- NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1
- NIST CSRC publication page for SP 800-218
Last reviewed: 19 October 2026.
