A vulnerability disclosure policy (VDP) is a public statement that tells outsiders how to report a security weakness in your systems or products. It covers what's in scope, promises that you won't pursue people who report in good faith, and sets out what reporters can expect from you. It can be a single web page. Writing it takes a few days. The harder part is having a working process behind it. This post covers the elements every VDP needs, the standards and templates worth borrowing from, how a VDP differs from a bug bounty and why regulation is starting to require one.
What is a vulnerability disclosure policy?
A VDP is the public face of coordinated vulnerability disclosure (CVD). In CVD, the person who finds a flaw reports it privately, the organization fixes it, and details are published only once users can protect themselves. The policy sets the ground rules for that exchange.
People find weaknesses in your systems whether you invite them or not. They include independent researchers, customers who notice something odd, students and engineers at partner companies. Without a clear channel, their reports land in a sales inbox, get closed by a support desk that doesn't understand them, or never arrive at all. Some finders give up and publish instead.
Why does your organization need one?
A VDP gives finders a route that works, and it gives your team a predictable way to handle what arrives. It also:
- Reduces legal uncertainty for researchers, who are more likely to report when they know they're authorized
- Signals to customers and partners that you take security reports seriously
- Moves your organization in the direction regulators and standards bodies are already heading
US federal civilian agencies have had to publish VDPs since CISA issued Binding Operational Directive 20-01 in September 2020, which gave them 180 days to do so. In the EU, the Cyber Resilience Act will make a coordinated vulnerability disclosure policy mandatory for manufacturers of products with digital elements (more on that below).
What should a vulnerability disclosure policy include?
Most good VDPs share the same five building blocks.
Scope
List the systems, domains, applications or products the policy covers, and say clearly what is out of scope. Services hosted by third parties usually belong on the out-of-scope list, because you can't authorize testing of systems you don't own.
Spell out which testing activities are not allowed. Typical exclusions are:
- Denial-of-service testing or anything that degrades availability
- Physical testing of offices or data centers
- Accessing, modifying or deleting data beyond the minimum needed to demonstrate the issue
- Installing persistent access or moving further into the network after confirming a flaw
- High-volume automated scanning that affects other users
If you're nervous, start with a narrow scope, such as your main website, and expand it over time. BOD 20-01 took this approach: agencies started with at least one internet-accessible system and had to bring all of them into scope within two years.
Authorization and safe harbor
This is the section researchers read first. State plainly that research carried out in good faith and in line with the policy is authorized, and that you won't recommend or pursue legal action over it. CISA's template puts it directly: if you make "a good faith effort to comply with this policy," the organization "will consider your research to be authorized." It also promises to make that authorization known if a third party takes legal action against a researcher who followed the policy.
Define what good faith means in practice. Researchers should stop once they've confirmed the issue, avoid privacy violations, keep what they found confidential until it's fixed and report promptly.
Have your legal counsel review this section. Computer misuse laws differ between countries. In the United States, the Department of Justice revised its policy in May 2022 so that federal prosecutors should not charge good-faith security research under the Computer Fraud and Abuse Act. That helps, but it doesn't cover civil claims or other jurisdictions. The open-source disclose.io project publishes safe harbor language you can adapt.
How to report
Give reporters one clear channel. A web form or a dedicated mailbox such as security@yourdomain both work. Offer an encryption option if you can, and don't require reporters to create an account, sign a non-disclosure agreement or give their real name. CISA's template allows anonymous reports.
Tell reporters what a useful report contains:
- The affected system, URL or product version
- A description of the weakness and its potential impact
- Steps to reproduce, with any proof-of-concept code
- How to reach them, if they're willing
What reporters can expect
Set out your side of the bargain. That usually means a prompt acknowledgment, an initial assessment, regular updates until the issue is resolved and public credit if the reporter wants it. Say explicitly whether you pay rewards. Most VDPs don't, and saying so avoids awkward conversations later.
Timelines
Commit to timeframes you can actually meet. Here's a starting point:
| Stage | Example target |
|---|---|
| Acknowledge receipt | Within 3 business days |
| Initial triage and validation | Within 10 business days |
| Status updates | At least every 30 days until resolved |
| Remediation | Based on severity, in line with your internal patching SLAs |
| Public disclosure | Coordinated with the reporter, commonly up to 90 days after the report |
The three-day acknowledgment matches CISA's template. The 90-day window is a widely used convention among researchers, not a rule. If a fix will take longer, tell the reporter why and agree a new date. Silence is the fastest way to lose a researcher's patience.
How do you publish a security.txt file?
A security.txt file is a small text file that tells people and automated tools where to send security reports. It was standardized in RFC 9116, published in April 2022, and belongs at /.well-known/security.txt on your website.
Only two fields are required. Contact gives a way to reach you, and Expires sets when the file should be considered stale. The RFC recommends keeping the expiry date less than a year in the future. Optional fields include Policy (a link to your VDP), Encryption, Acknowledgments, Preferred-Languages, Canonical and Hiring.
A minimal file looks like this:
Contact: mailto:[email protected]
Contact: https://example.com/security/report
Expires: 2026-03-24T23:00:00.000Z
Policy: https://example.com/security/disclosure-policy
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt
Set a calendar reminder to update the Expires date. An expired file tells researchers nobody is looking after it.
What do ISO/IEC 29147 and ISO/IEC 30111 cover?
Two international standards describe the process a VDP sits on top of:
- ISO/IEC 29147:2018 covers vulnerability disclosure: how an organization receives reports from outside and publishes information about fixes. It is the outward-facing half.
- ISO/IEC 30111:2019 covers vulnerability handling processes: how you investigate, triage and fix a reported vulnerability internally. It is the back office.
You don't need certification to benefit from them. Use them as a checklist when designing your intake, triage, remediation and advisory steps. A VDP without a handling process behind it only produces reports nobody acts on.
What can you learn from CISA's VDP template?
When CISA issued BOD 20-01, it required each agency's policy to cover scope, the types of testing allowed, how to submit reports, a commitment not to pursue legal action against good-faith research and when reporters could expect acknowledgment. CISA also published a vulnerability disclosure policy template for agencies to adapt.
The template was written for federal agencies, but it suits almost any organization. Its sections cover the introduction, authorization, guidelines, test methods, scope, how to report and what to expect. The language is plain and reporter-friendly. Swap in your own names and scope, have counsel review the authorization section, and you'll have a solid first draft within an afternoon.
What does the EU Cyber Resilience Act require?
The Cyber Resilience Act, Regulation (EU) 2024/2847, entered into force on 10 December 2024. It applies to manufacturers of hardware and software products with digital elements placed on the EU market. Among its vulnerability handling requirements, manufacturers must put in place and enforce a policy on coordinated vulnerability disclosure, and provide a contact address for reporting vulnerabilities.
The obligations phase in. Reporting of actively exploited vulnerabilities and severe incidents will apply from 11 September 2026, and most other obligations, including the vulnerability handling requirements, will apply from 11 December 2027. The European Commission's CRA page summarizes the timeline. If you sell connected products or software into the EU, a VDP and a working handling process are worth building now rather than in 2027.
VDP vs. bug bounty: what's the difference?
The two are often confused. A bug bounty is a VDP with financial rewards attached, usually with tighter rules and more active promotion.
| Vulnerability disclosure policy | Bug bounty program | |
|---|---|---|
| Rewards | None, or public credit only | Cash payments based on severity |
| Participants | Anyone who finds something | Often invited researchers at first, sometimes public |
| Purpose | Give finders a safe, clear reporting channel | Actively encourage people to go looking |
| Report volume | Usually modest | Can be high, including many low-quality reports |
| Resources needed | A triage process and a remediation path | The same, plus budget and more triage capacity |
Start with a VDP. A bug bounty makes sense once you can handle VDP reports reliably, fix issues within your SLAs and absorb a jump in volume. Launching a bounty before then mostly pays people to find problems you can't fix in time.
Frequently asked questions
Do small organizations really need a VDP?
Yes. Size doesn't change whether people will find flaws in your website or product. A one-page policy, a monitored mailbox and a security.txt file cost very little and prevent reports from being lost.
Should we pay people who report through our VDP?
You don't have to, and most VDPs don't. Be explicit about it in the policy. Some organizations send a thank-you or public credit instead.
What if a reporter goes public before we've fixed the issue?
Stay professional, focus on the fix and publish your own advisory if users need to act. Clear timelines and regular updates make early disclosure much less likely.
Can we require reporters to sign a non-disclosure agreement?
We don't recommend it. It discourages reporting and undermines the safe harbor you're offering. Ask for coordinated disclosure in the policy instead.
Next steps
- Decide who owns incoming reports and how they reach the people who can fix them.
- Draft your policy from CISA's template, adjusting scope and timelines to what you can deliver.
- Have legal counsel review the authorization language.
- Set up a reporting channel and publish a security.txt file that links to the policy.
- Map your handling process against ISO/IEC 30111, from triage to fix to advisory.
- If you make products for the EU market, check your process against the Cyber Resilience Act's vulnerability handling requirements.