How to Build a Vulnerability Disclosure Program in 2026: A Step-by-Step Guide for Security Teams

What Is a Vulnerability Disclosure Program?

A vulnerability disclosure program (VDP) is a formal process that lets external security researchers report vulnerabilities in your systems without fear of legal retaliation. It's the front door for bug reports from people who don't work for you.

Without a VDP, researchers who find vulnerabilities in your product face an uncomfortable choice: report it and risk a legal threat, sell it on the gray market, or post it publicly. None of those outcomes are good for you.

A VDP solves this by publishing three things:

1. What's in scope — which systems researchers can test
2. How to report — where to send findings
3. What happens next — your commitment to respond, fix, and not sue

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) issued BOD 20-01 requiring all federal agencies to have a VDP. The private sector has followed: as of 2026, over 60% of Fortune 500 companies operate a VDP or bug bounty program.

VDP vs Bug Bounty: Which Do You Need?

These are related but different programs:

Start with a VDP. You can always add bounties later once your triage process is proven. Launching a bug bounty without a working triage pipeline is how you end up with 200 unread reports and angry researchers.

Step 1: Write Your Disclosure Policy

Your disclosure policy is the public document that tells researchers the rules. Keep it short — one page maximum. It needs four sections:

1.1 Introduction

State that you welcome security research and commit to working with researchers who follow your guidelines. Two sentences is enough.

1.2 Scope

List exactly which domains, applications, and APIs are in scope. Be specific. "All our stuff" is not a scope definition.

1.3 Rules of Engagement

Define what researchers can and cannot do:

• No accessing other users' data
• No denial-of-service testing
• No social engineering of employees
• No physical security testing
• Stop and report if you access data you shouldn't have

1.4 Response Commitment

Set concrete SLAs:

• Acknowledgment within 3 business days
• Triage assessment within 10 business days
• Status update at least every 30 days until resolution

Don't promise fix timelines you can't keep. Researchers understand that fixes take time — what frustrates them is silence.

Step 2: Define Your Scope

Scope definition is where most VDPs succeed or fail. Too broad and you'll get reports on systems you can't fix. Too narrow and researchers won't bother.

Good Scope Example

In Scope:
- *.example.com (web applications)
- api.example.com (REST API)
- Example Mobile App (iOS and Android, latest version)

Out of Scope:
- Third-party services (Zendesk, Intercom, etc.)
- Physical security
- Social engineering
- Denial of service
- Spam or content injection without security impact

Scope Tips

• Start narrow. Launch with your main web app and API. Expand scope as your triage capacity grows.
• Exclude what you can't fix. If you use a third-party widget you don't control, exclude it explicitly.
• List vulnerability types you care about. OWASP Top 10 categories are a good starting point. See our OWASP Top 10 Testing Guide for what each category covers.

Step 3: Add Safe Harbor Language

Safe harbor is the legal commitment not to pursue action against researchers who follow your rules. This is the single most important element of your VDP. Without it, experienced researchers won't participate.

Sample Safe Harbor Clause

If you conduct security research in accordance with this policy, we consider
your research to be:

- Authorized under the Computer Fraud and Abuse Act (CFAA)
- Authorized under applicable anti-circumvention laws (DMCA)
- Exempt from restrictions in our Terms of Service that would interfere
  with security research

We will not initiate legal action against you for security research conducted
in compliance with this policy.

If a third party initiates legal action against you for activities conducted
in accordance with this policy, we will make it known that your actions were
authorized.

The DOJ's 2022 policy update on CFAA prosecutions explicitly states that good-faith security research should not be prosecuted. Your safe harbor clause aligns with this guidance and gives researchers confidence.

Step 4: Set Up Report Intake

Researchers need a clear, reliable way to submit reports. Options from simplest to most sophisticated:

Option A: Dedicated Email

security@yourdomain.com — simple, universally understood. Publish your PGP key so researchers can encrypt sensitive details.

Option B: Web Form

A simple form with fields for: vulnerability type, affected URL/endpoint, steps to reproduce, impact assessment, and file attachments. Host it on your own domain.

Option C: Platform-Hosted

Services like HackerOne, Bugcrowd, and Intigriti offer free VDP tiers that handle intake, deduplication, and researcher communication. This is the fastest path if you don't want to build infrastructure.

Intake Requirements

• HTTPS only — researchers are sending vulnerability details
• Acknowledge receipt automatically (autoresponder or platform notification)
• Support file attachments (screenshots, PoC scripts)
• Don't require researchers to create an account just to report

Step 5: Build a Triage Workflow

Triage is where VDPs live or die. A report sitting unread for 30 days tells researchers you don't care.

Triage Process

1. Acknowledge (Day 0–3): Confirm receipt, assign a tracking ID
2. Validate (Day 3–10): Reproduce the issue. Is it real? Is it in scope?
3. Assess severity (Day 10): Use CVSS or your internal severity scale
4. Route to engineering (Day 10–14): Create an internal ticket with reproduction steps
5. Update researcher (Day 14): Share severity assessment and expected timeline
6. Fix and verify (varies): Engineering fixes, security team verifies
7. Close and credit: Thank the researcher, offer credit in your hall of fame or security advisories

Triage Tips

• Assign a rotating on-call. Don't let triage be "whoever gets to it." One person owns intake each week.
• Template your responses. Write templates for: acknowledgment, needs-more-info, duplicate, out-of-scope, accepted, and fixed. This cuts response time dramatically.
• Track metrics. Measure time-to-acknowledge, time-to-triage, and time-to-fix. These are your VDP health indicators.

Step 6: Publish security.txt

RFC 9116 defines a standard file that tells researchers how to report vulnerabilities. Place it at /.well-known/security.txt on your domain.

Example security.txt

Contact: mailto:security@example.com
Contact: https://example.com/security/report
Expires: 2027-04-12T00:00:00.000Z
Encryption: https://example.com/.well-known/pgp-key.txt
Acknowledgments: https://example.com/security/thanks
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt
Policy: https://example.com/security/policy

Why This Matters

Automated security tools and researchers check for security.txt first. Without it, they may not know how to reach you — or may assume you don't want to hear from them. Google, GitHub, and most major tech companies publish security.txt files.

The Expires field is required by the RFC. Set it 12 months out and add a calendar reminder to update it.

Step 7: Researcher Communication

How you communicate with researchers determines whether they report to you again — and whether they recommend your program to others.

Do

• Respond within your stated SLA, every time
• Be specific about what you're doing with their report
• Credit researchers by name (or handle) in your security advisories
• Maintain a public hall of fame or acknowledgments page
• Tell them when the fix ships

Don't

• Ghost researchers after the initial acknowledgment
• Dispute severity without explaining your reasoning
• Ask researchers to sign NDAs before you'll look at their report
• Threaten legal action for good-faith reports that slightly exceed scope

The security research community is small and well-connected. One bad interaction gets shared widely. One good interaction brings more researchers to your program.

Tools That Support VDPs

If you're running your own intake (email or web form), pair it with your existing ticketing system. Jira, Linear, or even a dedicated GitHub repo with issue templates works fine for small teams.

Common Mistakes That Kill VDPs

1. No safe harbor language. Experienced researchers check for this first. No safe harbor = no reports from anyone who knows what they're doing.
2. Scope too vague. "Our web properties" means nothing. List specific domains and endpoints.
3. No response SLA. If you don't commit to a timeline, researchers assume you'll never respond.
4. Triage bottleneck. One person doing triage as a side job means reports pile up. Assign dedicated rotation.
5. Launching a bug bounty before VDP. Bounties attract volume. If you can't handle VDP volume, bounty volume will overwhelm you.
6. Expired security.txt. The RFC requires an Expires field. An expired security.txt signals an abandoned program.
7. Legal team overreach. If your lawyers want to add threatening language to the policy, push back. The DOJ's CFAA guidance supports good-faith research.

Frequently Asked Questions

Do we need a VDP if we already do penetration testing?

Yes. Penetration tests are point-in-time assessments by hired testers. A VDP provides continuous coverage from a global community of researchers who may find issues your pentesters missed. They complement each other. See our automated penetration testing guide for how to combine both approaches.

What if we get a report for a vulnerability we already know about?

Acknowledge it, mark it as a known issue, and thank the researcher. Don't ignore duplicates — the researcher still spent time finding and reporting it. If you have a fix timeline, share it.

How do we handle reports that are out of scope?

Respond politely, explain why it's out of scope, and thank them for the effort. If the finding has genuine security impact even though it's technically out of scope, consider accepting it anyway. Rigid scope enforcement discourages future reports.

Should we offer a bug bounty from day one?

No. Start with a VDP, prove your triage process works, then add bounties after 3–6 months. Many successful programs (including the U.S. Department of Defense's Hack the Pentagon) started as VDPs before adding rewards.

What legal protections do researchers have?

The DOJ's 2022 CFAA policy update states that good-faith security research should not be charged under the CFAA. ISO 29147 provides an international standard for vulnerability disclosure. Your safe harbor clause adds a contractual layer on top of these protections.

How do we measure VDP success?

Track: number of valid reports per month, time-to-acknowledge, time-to-fix, researcher satisfaction (repeat reporters), and unique vulnerabilities found that internal testing missed. A healthy VDP finds 5–15 valid issues per quarter for a mid-size application.