How to Write a Vulnerability Disclosure Policy (with Template)
Sooner or later, someone outside your company will find a vulnerability in your product. A vulnerability disclosure policy (VDP) tells them how to report it, what to expect, and that they will not be punished for reporting in good faith. Without one, reports go to the wrong inbox, get ignored, or end up on social media.
Why you need a VDP
- Researchers need a safe, clear channel. Many will not report without assurance they will not face legal threats.
- Customers and regulators expect it. VDPs are recommended by standards bodies and increasingly expected in vendor reviews and government contracts.
- It costs almost nothing. Unlike a bug bounty, there is no reward budget required.
What to include
- Scope: which domains, apps and APIs are covered, and what is out of scope.
- How to report: a dedicated email address or form, and what details to include.
- What you ask of researchers: test only within scope, avoid privacy violations, data destruction and service disruption, and give you reasonable time to fix before disclosure.
- What researchers can expect: acknowledgement within a set time, updates, and credit if they want it.
- Safe harbour: a statement that you will not pursue legal action for good-faith research that follows the policy.
- Disclosure timeline: how long before public disclosure, commonly around 90 days, or by agreement.
- Rewards: state clearly whether you offer bounties or not.
Add a security.txt file
security.txt, standardised as RFC 9116, tells researchers where to report. Place it at /.well-known/security.txt:
Contact: mailto:[email protected]
Expires: 2027-10-29T00:00:00.000Z
Policy: https://example.com/security/disclosure
Preferred-Languages: enA simple template
Vulnerability Disclosure Policy
We welcome reports of security vulnerabilities in our products. If you believe you have found one, please email [email protected] with a description, steps to reproduce and potential impact.
Scope: example.com, app.example.com and api.example.com. Out of scope: third-party services, denial of service, social engineering and physical attacks.
Please: only test accounts you own, stop and report if you access other users' data, avoid degrading our services, and give us reasonable time to fix issues before disclosure.
We will: acknowledge your report within 3 business days, keep you informed, and credit you if you wish. We will not take legal action against research conducted in good faith under this policy.
We do not currently offer monetary rewards.
Handling reports well
- Respond quickly and politely, even to low-quality reports.
- Triage within a defined time, and reproduce the issue.
- Fix according to severity timelines.
- Thank and credit researchers.
- Track reports so recurring patterns inform your testing.
Prepare before you publish
Publishing a VDP invites reports. Run a penetration test first so common issues are already fixed, and make sure someone owns the inbox. SecurityInfinity can give you a baseline in about ten minutes. Start free.
Frequently asked questions
Does a VDP mean we must pay for bugs?
No. A VDP can explicitly state that there are no monetary rewards. Bug bounties are separate.
What if a researcher demands payment?
Follow your policy. Demands for payment in exchange for not disclosing are extortion, not good-faith research, and should be handled carefully.
Where should the VDP be published?
On your website, typically at a /security page, linked from security.txt and your footer.