ID.RA-07 reads: "Changes and exceptions are managed, assessed for risk impact, recorded, and tracked". Keep an exception register with the reason, risk assessment, approver, compensating control and an end date, and review it on a schedule. An exception with no expiry is just a permanent gap.
Why exceptions need their own record
Every real engineering team grants exceptions: a vulnerability that cannot be patched this quarter, a service that cannot yet use single sign on, a build that ships past a failed check to fix an outage. The NIST CSF 2.0 subcategory ID.RA-07 asks that these are managed, assessed for risk impact, recorded and tracked, together with ordinary changes.
The framework does not say how. A register in a ticket system or a repository is enough, provided every entry carries the same fields and someone reviews it.
Fields for an exception entry
| Field | Why it matters |
|---|---|
| What is excepted | Names the control, check or policy |
| Scope | Which system, repository or period |
| Reason | The business or technical constraint |
| Risk assessment | Likelihood and impact in plain words |
| Compensating control | What reduces the risk meanwhile |
| Approver | A person with authority, not the requester |
| Expiry date | When it must be fixed or reapproved |
| Status | Open, extended, closed |
The approver and expiry are the fields that most often go missing. Without them, nobody is accountable and nothing forces a revisit.
Running the register
- Make the register the only route to an exception. If a pipeline check can be bypassed, require a link to an entry.
- Review open entries monthly. Close ones that are fixed, and escalate those near expiry.
- Track the count and the age of open exceptions. A rising number is a signal to look at root causes.
- When an exception is extended, record why, and require a higher level of approval for a second extension.
- Report the register to whoever owns risk at least quarterly.
This also gives you a ready answer when a customer asks how you handle findings you cannot fix right away.
Changes count too
The subcategory mentions changes along with exceptions. Normal change records, such as reviewed pull requests with an impact note for risky changes, belong in the same story. For emergency changes, record them after the fact with the same fields, and review them in a retrospective.
Try it yourself
Try the exploitability check demo to see how a finding can be judged for real risk. That judgment is the risk assessment field of your exception entry.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard supports policies, gates and guardrails on pull requests, plus compliance and evidence automation, so gate outcomes can be kept as records. You can try the free scan at gold.safeguard.sh/scan. Treat any export as input to your own review, not as a finding of compliance.
Quick check
Do accepted risks need an expiry?
The subcategory says exceptions are tracked, and an end date is a practical way to make sure tracking leads to a decision. It is good practice rather than a quoted requirement.
Who should approve an exception?
Someone with authority over the risk, who is not the person asking. Write the rule in your policy and follow it.
Sources
Last reviewed: 19 October 2026.
