Write a vulnerability disclosure policy with five parts: a promise, a scope, a safe harbor statement, a reporting process, and your preferences for response and disclosure. Keep it short and plain, publish it at a stable URL, and point to it from a security.txt file. Have counsel review the safe harbor wording before you publish.
Key takeaways
- The five-part structure comes from the NTIA Coordinated Vulnerability Disclosure template (December 2016), as summarized in a platform vendor's guide.
- CISA's BOD 20-01 requires scope, testing rules, a reporting mechanism, a legal safe harbor commitment, and response expectations for US federal agencies. It is a good checklist for anyone.
- NTIA's sample suggests a response within 2 business days and fixes usually within 120 days. CISA recommends acknowledgment within 3 business days and resolution within 90 days.
- Safe harbor is the clause that most affects whether researchers report to you. Use clear, affirmative wording.
- A policy nobody answers is worse than none. Name an owner before you publish.
What is a vulnerability disclosure policy?
A vulnerability disclosure policy (VDP) is a public statement of how outsiders can report security issues to you and what you will do in return. It is the foundation under any bounty program. For the difference, see bug bounty vs vulnerability disclosure program.
What should a VDP include?
It should include a promise, scope, safe harbor, process and preferences. The NTIA template, as described in a 2017 platform vendor guide, uses these five elements.
- Promise: a clear, good-faith commitment to customers and other stakeholders, saying why the policy exists.
- Scope: what is covered and what is not, including properties, products and vulnerability types, and any version limits.
- Safe harbor: a statement that good-faith reporters will not be unduly penalized.
- Process: how to submit a report and what details to include.
- Preferences: how reports will be evaluated, including response timing, communication, recognition and public disclosure.
CISA's BOD 20-01 asks federal agencies for a similar set: scope, allowed and disallowed testing, a reporting mechanism that allows anonymous reports, a commitment not to recommend or pursue legal action for authorized good-faith research, expectations on acknowledgment, and an issuance date.
How do you write the scope?
List what is in scope by name, and say what is not. BOD 20-01 requires at least one internet-accessible production system or service in scope at publication, and says new systems should be added as they launch. Common exclusions in published templates include social engineering, physical attacks, denial-of-service testing, high-volume automated scanning and third-party services you do not control.
Be specific about what testers must not do. BOD 20-01 asks policies to state that discovered personally identifiable information must not be disclosed to any third party.
How do you write the safe harbor clause?
Say plainly that you will not pursue legal action against good-faith research that follows your rules. The NTIA template suggests this wording: "If you follow these guidelines we will not pursue or support any legal action related to your research."
CISA's version commits not to recommend or pursue legal action against research it deems authorized. The US Department of Justice has also published a Framework for a Vulnerability Disclosure Program for Online Systems (July 2017). We list it as a resource but did not review its text. Counsel should review your final wording, especially across jurisdictions.
What should the reporting process say?
Give one channel, say what you need, and keep the ask small. The vendor guide notes that finders are unpaid, so asking for too much can reduce reports. A short list works: a description of the issue, steps to reproduce, affected URLs or versions, and any proof of concept. A secure form or an email address both work, and BOD 20-01 asks that anonymous reports be allowed.
What response times should you promise?
Promise only what you can keep. The NTIA sample suggests a timely response within 2 business days and an expected timeline for patches, usually within 120 days. CISA recommends acknowledgment within no more than 3 business days, an initial assessment within 7 days, and resolution within 90 days, and says these are targets, not mandatory remediation dates.
The vendor guide recommends keeping preferences non-binding and noting that timing may vary by severity.
What does a sample policy look like?
Here is a short example you can adapt. The address and times are examples. Replace them with your own.
Security reporting policy
We want to hear about security issues in our products. If you believe you
have found one, please tell us and give us a reasonable chance to fix it.
Scope: example.com and app.example.com. Out of scope: social engineering,
physical attacks, denial-of-service testing, and third-party services.
Safe harbor: if you follow this policy, we will not pursue or support legal
action related to your research. Do not access, change or share other
people's data. If you reach personal data by accident, stop and tell us.
How to report: email security@example.com with a description, steps to
reproduce, and the affected URL. You may report anonymously.
What to expect: we reply within 3 business days, assess within 7 days, and
aim to fix confirmed issues within 90 days. We will tell you when it is fixed
and, if you want, credit you. Please give us time to fix an issue before you
discuss it publicly.
Where do you publish it, and how do you link it?
Put it at a stable public URL such as a security page, and link it from your footer. Then add it to your security.txt file with the Policy field. RFC 9116 defines Policy as a link to the vulnerability disclosure policy. See security.txt: what it is and how to add one.
You can also use disclose.io, which describes itself as open infrastructure for safer disclosure and offers a policy generator with safe harbor language and a security.txt file.
How to write yours: a checklist
- Name an owner and a shared mailbox before you publish.
- Write the promise in two sentences.
- List in-scope assets by name and out-of-scope behavior by type.
- Add safe harbor in plain words and have counsel review it.
- Name one reporting channel and a short list of what to include.
- State response targets you can meet.
- Publish at a stable URL, link it from your footer, and reference it in security.txt.
- Test the mailbox once a quarter.
Frequently asked questions
Do I need a lawyer to write a VDP?
Counsel should review the safe harbor and disclosure wording. The rest is plain operational language you can write yourself.
Should a VDP promise a bounty?
Not unless you run a bounty. A VDP can offer recognition instead of payment.
How long should researchers wait before disclosing?
CISA recommends resolution within 90 days, and NTIA's sample says usually within 120 days. Pick a figure you can meet.
What is the difference between a VDP and a security.txt file?
The VDP is the policy. The security.txt file is a small machine-readable pointer to your contact and policy.
Does a VDP expose me to more reports?
Yes, some of them low quality. Triage rules and a template reply keep it manageable.
Sources
- CISA, BOD 20-01, Develop and Publish a Vulnerability Disclosure Policy
- Platform vendor blog, Vulnerability Disclosure Policy Basics, published 10 August 2017, summarizing the NTIA template
- US Department of Justice CCIPS documents list, listing the Framework for a Vulnerability Disclosure Program for Online Systems, July 2017
- RFC 9116, security.txt
- disclose.io
Last reviewed: 19 October 2026.
