A vulnerability disclosure policy tells outside researchers exactly how to report a flaw in your systems and tells your own team exactly how fast to respond — get the scope, the safe harbor language, or the response timelines wrong and you either scare off good-faith researchers or leave the company exposed to legal risk. Most policies fail on specifics: vague scope, no legal protection, no committed response window.
- A vulnerability disclosure policy needs five parts: scope, safe harbor language, a reporting channel, response timelines, and a disclosure window.
- The industry-standard coordinated disclosure window is 90 days from report to public release.
- CISA's Binding Operational Directive 20-01 required every federal civilian agency to publish a VDP starting in 2020.
- security.txt (RFC 9116, 2022) is now the standard machine-readable way to publish your reporting channel.
- Brinqa's exposure management platform gives teams one queue for triaging externally reported and internally discovered vulnerabilities.
Why this matters
A researcher who finds a bug in your product has two options if you have no published policy: email a random inbox and hope, or post it on Twitter. Neither ends well for you.
A written vulnerability disclosure policy is what turns that into a predictable process instead of a crisis. It's also increasingly a compliance checkbox — auditors reviewing SOC 2 and ISO 27001 programs in 2026 routinely ask whether a public reporting channel exists, separate from whether you run a paid bug bounty.
How do you write a vulnerability disclosure policy
Build the policy in this order — skipping steps is what produces the vague, unenforceable policies most companies end up with:
- Define scope. List which domains, products, APIs, and mobile apps are in scope, and explicitly call out anything that's off-limits (third-party vendor systems, physical offices, social engineering).
- Write safe harbor language. State plainly that good-faith security research conducted within scope will not result in legal action against the researcher. This single clause is what gets your policy taken seriously by the researcher community.
- Publish a reporting channel. A dedicated security email address is the minimum; a machine-readable security.txt file at /.well-known/security.txt, per RFC 9116, is now the expected standard as of 2026.
- Commit to a response timeline. State how fast you'll acknowledge a report and how fast you'll deliver an initial triage assessment. Vague policies say "promptly" — specific ones name a number of business days.
- Set a coordinated disclosure window. The industry norm, used by Google Project Zero and most CERT/CC coordinated cases, is 90 days from initial report to public disclosure, with room to extend for complex fixes.
- Define how you'll triage severity. Reference CVSS scoring so researchers know how you'll classify what they send in, and connect that triage step to your internal vulnerability management program so external reports don't sit in a separate silo from everything else.
- Publish it and keep it current. A VDP that references outdated product names or dead email addresses is worse than no policy — researchers test the channel before they use it.
The reporting channel and response commitment
| Element | What to include | Why it matters |
|---|---|---|
| Reporting channel | Dedicated email + security.txt file | Gives researchers one obvious place to send reports |
| Acknowledgment window | Business days to first response | Sets researcher expectations, reduces public disclosure pressure |
| Safe harbor clause | Explicit no-legal-action language for good-faith research | Encourages responsible reporting instead of silent exploitation |
| Disclosure window | 90-day coordinated norm, extendable | Balances fix time against public risk |
Once reports start arriving, the volume adds up fast, and treating them as one-off emails breaks down within a quarter. A platform like Brinqa's exposure management platform pulls externally reported findings into the same queue as internally scanned vulnerabilities, so triage happens against one prioritized list instead of two separate ones.
Why vulnerability disclosure policies vary company to company
No two published VDPs look identical, and they shouldn't — the details depend on:
- Regulatory obligations — healthcare and financial services teams often add stricter timelines to satisfy audit requirements.
- Whether a bug bounty runs alongside it — paid programs add payout tiers and eligibility rules a plain VDP doesn't need.
- Engineering bandwidth — teams with slower patch cycles commit to longer acknowledgment windows rather than promise a number they'll miss.
- Public sector requirements — U.S. federal civilian agencies have operated under a VDP mandate since BOD 20-01 in 2020.
- Third-party and vendor exposure — companies with heavy vendor integrations often scope those systems out explicitly to avoid taking on liability for someone else's code.
- Legal review cycles — safe harbor language gets rewritten as case law around good-faith security research evolves.
What's the difference between a vulnerability disclosure policy and a bug bounty program?
A vulnerability disclosure policy is the baseline: a legal and procedural framework for accepting reports, with no payment implied. A bug bounty program sits on top of that framework and adds payout tiers, eligibility rules, and often a private invite-only researcher pool. You can run a VDP with zero bounty budget; you can't run a responsible bounty program without a VDP underneath it.
Do you need a vulnerability disclosure policy if you don't pay researchers?
Yes — a vulnerability disclosure policy costs nothing to publish and it's the only thing standing between an unpaid researcher and a public Twitter thread about your unpatched flaw. Safe harbor language and a clear reporting channel work the same whether or not money changes hands.
What is safe harbor language and why does it matter?
Safe harbor language is the clause in a vulnerability disclosure policy stating that good-faith security research conducted within the defined scope won't trigger legal action against the researcher. Without it, researchers reasonably assume you might pursue them under computer fraud statutes, and many will simply stay silent or go public instead of reporting privately.
See how exposure data flows into one queue
Brinqa unifies externally reported and internally scanned vulnerabilities in one workflow.
Once the policy is drafted, run it past whoever owns your response SLAs — a policy that promises response times your team can't hit in 2026 undermines the whole document. If you haven't formalized remediation timelines yet, set remediation SLAs by severity before you publish a public-facing response commitment you can't keep.
FAQ
What's the best format for a vulnerability disclosure policy?
The best format is a short public webpage plus a machine-readable security.txt file at /.well-known/security.txt, per RFC 9116. The webpage covers scope and safe harbor language in plain terms; security.txt gives automated tools and researchers a standard place to find your reporting contact.
Is a vulnerability disclosure policy legally required?
For most private companies, no federal law mandates a vulnerability disclosure policy, but U.S. federal civilian agencies have been required to publish one since CISA's Binding Operational Directive 20-01 took effect in 2020. Regulated industries often face indirect pressure through audit frameworks that expect a documented reporting channel.
How long should a coordinated disclosure window be?
90 days from initial report to public disclosure is the widely used industry norm, matching the standard Google Project Zero applies to its own reports. Complex vulnerabilities requiring architectural fixes sometimes extend that window by mutual agreement with the reporting researcher.
Is a vulnerability disclosure policy different from a bug bounty program?
Yes, a vulnerability disclosure policy is the baseline reporting framework with no payment attached, while a bug bounty program adds payout tiers on top of that same framework. A company can run a VDP alone without ever paying a researcher.
Who should own the vulnerability disclosure policy internally?
Security engineering or the PSIRT function typically owns the policy and the triage response, with legal reviewing the safe harbor language before publication. Whoever owns it needs authority to commit to the acknowledgment and disclosure timelines stated in the document.
Does ISO/IEC 29147 matter for writing a VDP?
ISO/IEC 29147 is the international standard specifically covering vulnerability disclosure practices, and ISO/IEC 30111 covers the internal handling process that follows. Referencing both signals to auditors and researchers that the policy follows an established structure rather than an ad hoc one.
What is security.txt and do small companies need one?
security.txt is an IETF standard (RFC 9116, published 2022) for a machine-readable file that points researchers and automated scanners to your security contact. Small companies benefit from it as much as large ones — it costs nothing and removes the "who do I email" guesswork entirely.
Do you need a vulnerability disclosure policy without a bug bounty budget?
Yes, a vulnerability disclosure policy works with zero budget attached since safe harbor language and a reporting channel don't require payment. Many companies publish a plain VDP for years before ever adding a paid bounty tier on top of it.
One last thing
Most companies treat the vulnerability disclosure policy as a one-time legal document and forget it. In 2026, the ones that actually work are treated as living operational documents — tied to the same SLA tracking and triage workflow as internally discovered vulnerabilities, reviewed whenever product scope changes, and checked against BOD 20-01-style mandates if any part of the business touches government contracts.
