SSDF RV.1.3 asks you to have a policy covering vulnerability disclosure and remediation and to put the roles, responsibilities and processes behind it in place. A one page version names how to report, who receives reports, how you respond and how you tell affected customers.
What RV.1.3 says
The task: have a policy that addresses vulnerability disclosure and remediation, and implement the roles, responsibilities and processes needed to support that policy. NIST's examples include a vulnerability disclosure program that makes it easy for researchers to find and report issues, a product security incident response team with communication plans, a playbook for common cases and periodic exercises of the response process.
Note the phrase "implement the roles." A policy that nobody operates does not meet the task.
Outline for the policy
| Section | Contents |
|---|---|
| Scope | Which products and services the policy covers |
| How to report | A contact address or form and what to include |
| Acknowledgment | How quickly you confirm receipt |
| Handling | Who triages, how severity is judged |
| Fix and notice | How you remediate and tell customers |
| Researcher expectations | What you ask of reporters, in plain terms |
Avoid promising specific deadlines you cannot meet. A stated target you miss is worse than a plain statement of intent. Your legal team should review the wording, since this post is not legal advice.
Roles to name
- Intake owner reads the inbox and acknowledges reports
- Triage lead assesses validity and impact
- Engineering owner per product, who ships the fix
- Communications owner who drafts the advisory
In a small company one person may fill several of these. Name a backup for each.
Playbooks worth writing
The NIST examples mention a generic reported vulnerability, a report of a zero-day, a vulnerability exploited in the wild and a major incident involving open-source components. Write a short checklist for each: first hour, first day, communications, closure. Run a practice scenario once a year and save the notes.
Evidence to keep
- The published policy and its revision history
- The role list and contact paths
- Ticket history showing reports handled, with sensitive details redacted
- Advisories issued
- Notes from the last exercise
Where RV.2 picks up
Once a report is confirmed, RV.2 covers analysis and the response plan. RV.1.3 is the front door and the machinery behind it.
Keeping the policy readable
Researchers and customers read these policies quickly, often under stress. Use short sentences, put the contact method near the top and avoid legal jargon where you can. Test it by asking someone outside security to find out how to report a problem in under a minute. If they cannot, move the information. Also make sure the address you list is monitored every working day, because an unread inbox defeats the whole policy.
Quick check
Do we need a bug bounty to satisfy RV.1.3?
No. NIST's example is a disclosure program that is easy for researchers to find and use. A bounty is a separate choice.
Where should the policy be published?
On a public page linked from your website, and optionally through a security.txt file so researchers can find it quickly.
Safeguard offers compliance and evidence automation, which can help keep the records in one place. 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.
