How to Write a Vulnerability Disclosure Policy: A Practical Guide

Right now, someone on the internet knows about a vulnerability in your product. The only open question is what they do with that knowledge. A vulnerability disclosure policy (VDP) exists to make the answer "they tell you" instead of "they tweet it," "they sell it," or (the most common outcome by far) "they shrug and move on because you gave them no way to report it that didn't feel like filing a police report against themselves."

A VDP is not a bug bounty. It's a public statement that says: if you find a security issue in our stuff, here's where to send it, here's what you're allowed to do while finding it, and here's our commitment not to sue you for good-faith research. No money changes hands. That's the whole thing, and it takes an afternoon to draft.

VDP vs bug bounty: the actual difference

People conflate these constantly, so let's be precise:

A VDP is a fire escape. A bug bounty is hiring people to stress-test the building. You need the fire escape either way, and regulators increasingly agree: CISA's Binding Operational Directive 20-01 mandates VDPs for US federal civilian agencies, the EU's NIS2 and CRA push coordinated disclosure obligations onto a wide swath of companies, and ISO 29147 has documented the practice since 2014. "We have no way to receive vulnerability reports" is rapidly becoming a compliance finding in its own right.

The essential elements of the policy

A workable VDP fits on one page. It needs five sections.

1. Scope

State which assets the policy covers. *.example.com, your mobile apps, your public API. Just as important: state what's out. Third-party services you don't control, corporate IT (unless you mean it), physical security, social engineering. Ambiguity here produces reports about your Zendesk instance's password policy. If you want the full treatment on writing scope that doesn't invite garbage, we've written a dedicated guide. The principles transfer directly.

2. Rules of engagement

Tell researchers what good faith looks like in practice:

• Don't access, modify, or exfiltrate other users' data. Use test accounts you created.
• Stop and report once you've demonstrated impact; don't pivot deeper to "prove" it.
• No denial of service, no spam, no social engineering of staff or customers.
• Automated scanning: state your tolerance explicitly. "Low-throughput scanning permitted" or "no automated scanning": either is fine, silence is not.

3. Safe harbor

This is the part researchers actually read. Safe harbor language says that research conducted in good faith and within the policy will not be met with legal action under the CFAA, DMCA, or their local equivalents, and that you'll consider such research "authorized" for the purposes of those laws.

The usual caveat applies: we triage vulnerabilities, we don't practice law, and this is not legal advice. But some practical observations from reading a lot of these policies:

• Don't draft it from scratch. disclose.io maintains widely adopted boilerplate; the US DOJ has published a framework; HackerOne, Bugcrowd, Intigriti, and YesWeHack all provide vetted templates. Start there and have counsel adapt it.
• Weasel-worded safe harbor ("we reserve the right to pursue any remedy") is worse than none, because it signals you thought about it and chose hostility. Experienced researchers will notice and route around you.
• Address third parties. You can't authorize research against infrastructure you don't own, so say what happens when scope boundaries blur: typically a commitment that you won't refer good-faith researchers to third parties for legal action.

4. Reporting channel and what to include

Give one unambiguous intake path and describe a good report: affected asset, steps to reproduce, impact, and any proof-of-concept material. You'll still get two-line reports with a screenshot of a dig command, but you'll get fewer.

5. Your commitments

State what the researcher gets: acknowledgment within N business days, a triage decision within M, and a good-faith effort at remediation timelines. Say whether you allow public disclosure after a fix (you should, with coordination) and whether you offer credit. Then actually hit those numbers, because a VDP with a 40-day first-response time is just a honeypot for goodwill. Track them like you would any other triage SLA.

Setting up the intake channel

The classic minimum is security@yourdomain plus a /.well-known/security.txt file (RFC 9116) pointing at your policy and contact. security.txt costs you ten minutes and is the first thing a competent researcher checks. Do both regardless of what else you build.

Beyond that, you have three options:

• A web form on your own site. Cheap, structured, and lets you require the fields you need. Downside: you own spam filtering and workflow.
• A platform-hosted VDP on HackerOne, Bugcrowd, Intigriti, or YesWeHack. You inherit their submission flow, researcher identity, deduplication tooling, and disclosure coordination. Most platforms price VDP hosting well below bounty programs; some offer it free.
• Email only. Fine at low volume, miserable the moment volume arrives. PGP keys published for the purpose have a way of being expired at the exact moment someone needs them.

Whichever you pick, decide before launch who reads the queue, who validates reports, and where confirmed vulnerabilities go in your engineering workflow. A VDP report is still a vulnerability report: it needs real triage: validation, reproduction, severity assignment, and routing. The volume is lower than a bounty program's, but the worst-case report (an unauthenticated SQL injection from a stranger, no NDA, no platform mediation) is exactly as urgent.

What actually shows up in a VDP inbox

Setting expectations honestly: a typical VDP inbox is mostly noise with occasional lightning. You'll see SPF/DKIM/DMARC configuration reports by the dozen, "clickjacking on the login page" with a template PoC, beg bounty emails asking for payment the policy explicitly doesn't offer, and increasingly, LLM-hallucinated reports describing endpoints you don't have.

But mixed into that: real subdomain takeovers from people who monitor dangling DNS at internet scale, exposed .git directories and credentials in public repos, the occasional legitimately serious auth bypass from a researcher who just doesn't care about money. The signal rate is low and the signal value is high: a good trade at the price of zero dollars in bounties.

Why VDP-first is the right on-ramp

If you're planning a bug bounty eventually, launch the VDP first anyway. Six months of running a VDP teaches you, cheaply:

1. Your baseline noise profile: what garbage arrives unprompted, so you can write bounty scope that excludes it.
2. Whether your remediation pipeline works: if unpaid reports at VDP volume sit unfixed for 90 days, paid reports at bounty volume will bury you.
3. Whether your triage muscle exists: response times, severity consistency, engineering handoff, all rehearsed at low stakes.
4. What your attack surface actually is: VDP reports have a habit of mentioning subdomains and acquisitions your asset inventory forgot.

Bug bounty amplifies whatever operational reality it lands on. A VDP is how you find out what that reality is before you attach money to it. When the VDP runs smoothly (reports acknowledged fast, triaged consistently, fixed on schedule), you're ready to graduate to a private bounty program, and not before.

Drafting the one-page policy is the easy part; the real commitment is staffing the queue behind it.

Whether it's a trickle of VDP reports or a full bounty queue, someone still has to validate, reproduce, and rate every submission. TRIAGERS™ provides on-demand triage teams that handle exactly that, billed per report, so a VDP doesn't quietly become someone's second job. Get in touch and we'll help you size it.