A risk acceptance is a recorded decision to leave a known vulnerability unfixed for a stated period, with a named approver and a review date. Explain it in five sentences: what, why, who is exposed, what limits the harm, and when it ends.
The five sentences
- What: "We have a known flaw in [system] that we are not fixing right now."
- Why: "Fixing it would cost [effort or disruption], and the fix is blocked by [reason]."
- Exposure: "If it is exploited, [concrete consequence], and it applies to [scope]."
- Limits: "In the meantime we have [mitigation or monitoring], which reduces the likelihood or impact."
- End: "This decision expires on [date], when we will review it, and it is owned by [name]."
An executive who can say yes to those five has made an informed decision. One who cannot should ask for the missing sentence.
What makes an acceptance legitimate
| Element | Why it matters |
|---|---|
| Named approver with authority | The person who owns the business impact decides, not the person who finds it convenient |
| Expiry date | Without one, an acceptance becomes permanent by accident |
| Stated reason | Records why fixing was not possible now |
| Compensating control | Shows the exposure is being managed |
| Evidence | Links to the scan finding and the exposure analysis |
What not to accept quietly
Be wary of accepting a flaw when exploitation is known. CISA's Known Exploited Vulnerabilities catalog lists vulnerabilities known to be exploited in the wild and says organizations should use it as an input to prioritization (CISA). A listed vulnerability on an exposed system is a different conversation from an unlisted one in an isolated service.
Also be wary of leaning on the score alone. FIRST says a CVSS base score should not be used alone to assess risk (FIRST), which cuts both ways: a high score does not prove high risk, and a low one does not prove safety.
Acceptance versus a not-affected statement
They are different. A risk acceptance says "we are affected and have chosen to live with it." A not-affected statement says "the flaw does not apply to us." Do not let a team convert the first into the second to make a report cleaner. See also risk acceptance versus VEX not affected.
Keep a register
List every active acceptance in one place with approver, expiry and status. Review the register on a fixed schedule. Expired acceptances should force a decision: fix, renew with a new reason, or escalate.
Wording for a renewal
If the date arrives and the flaw remains, the renewal should be a new decision with fresh facts, not a silent extension. Ask: has exploitation evidence changed, has exposure changed, has a fix become cheaper?
Try it yourself
Click through it at your own pace, or open it full screen. See how reachability evidence separates findings the code can hit from those it cannot. That evidence belongs in the exposure sentence of an acceptance.
Where Safeguard fits
Safeguard supports policies and gates that can record exceptions with owners and dates, and reachability analysis that provides evidence for the exposure statement. The free scan is at gold.safeguard.sh/scan.
Quick check
Who should approve a risk acceptance?
The person who owns the business impact and has authority over the system, not only the security team.
Can an acceptance be open ended?
It should not be. Always set an expiry and a review.
Sources
Last reviewed: 19 October 2026.
