SSDF RV.2.2 asks you to plan and implement a risk response for vulnerabilities, deciding for each whether to remediate or address the risk another way, such as acceptance. Record the decision, who made it, the reason, any temporary mitigation and a date to look again.
What RV.2.2 says
The task text: plan and implement risk responses for vulnerabilities. The NIST examples include a risk-based decision on whether each vulnerability is remediated or handled through other means such as risk acceptance or transference, a temporary mitigation when no permanent one exists, security advisories for acquirers, remediation delivered through an automated and trusted mechanism and updates to your records of design decisions and approved exceptions.
The four common responses
| Response | When it fits | What to record |
|---|---|---|
| Remediate | A fix exists and the risk justifies it | Ticket, fix version, release date |
| Mitigate temporarily | No fix yet, or fix not deployable | The workaround and its expiry |
| Accept | Low exposure, cost outweighs benefit | Approver, reason, review date |
| Transfer | Another party takes on the risk | The agreement and scope |
Which response applies depends on exploitability, impact and exposure. RV.2.1 covers the analysis that feeds the choice.
A decision record template
Keep each record to a few lines:
- Finding and affected release
- Analysis: is the vulnerable code reachable, is it exposed, what is the impact
- Decision and approver
- Temporary controls, if any
- Review date
- Link to the advisory sent to customers, if one was needed
Acceptance needs discipline
An accepted risk without a review date becomes a permanent blind spot. NIST's PW.1.2 examples say to periodically re-evaluate approved exceptions and RV.2.2 says to update the exceptions record. Put a calendar trigger on each acceptance, and reopen it when a new exploit appears or the component's use changes.
Tell your customers when it matters
When a vulnerability affects your customers, an advisory should say what it is, how to find affected instances, and how to fix or work around it. If you accept a risk that does not affect customers, no advisory is needed, but keep the internal record.
Linking to the analysis
A decision is as good as the analysis behind it. Link each record to the RV.2.1 notes: how exploitable the issue is, what impact it has and how exposed the component is in your product. When a later reviewer asks why a finding stayed open, the linked analysis answers the question without a meeting. It also makes review dates meaningful, since a reviewer can check whether the facts changed.
Try it yourself
Click through it at your own pace, or open it full screen. See how checking whether a flaw is actually exploitable in context changes which response makes sense.
Quick check
Can we accept a risk on a known exploited vulnerability?
That is a decision for your risk owners. Document the reasoning, add compensating controls and set a short review date.
Who should approve acceptances?
Someone with authority over the risk, named in your role map. The right level depends on your organization.
Safeguard's reachability analysis can help show whether a vulnerable function is actually called, and its autonomous remediation can propose fix pull requests, off by default. Try the free scan 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.
