June 2026 · 13 min read · AppSec Strategy

Vulnerability Disclosure Program (VDP): A Complete Setup Guide

Every week, security researchers find vulnerabilities in systems they don't own. Most of the time, the hardest part isn't finding the bug — it's figuring out how to report it without getting sued. If you don't have a Vulnerability Disclosure Program, researchers face a choice: go public and embarrass you, sell it, or just stay silent. None of those outcomes are good for you.

A VDP removes that friction. It tells researchers exactly how to reach you, what they're allowed to test, and — critically — that they won't face legal consequences for doing the right thing. This guide covers everything from the legal foundation to the triage process to when it makes sense to graduate to a paid bug bounty program.

VDP vs Bug Bounty: What's the Difference

These two terms get conflated constantly. They're related but structurally different.

A Vulnerability Disclosure Program (VDP) is a policy and a process. It defines how researchers can report vulnerabilities, what's in scope, and what safe harbor protections they have. There is no monetary reward. The value exchange is entirely reputational: researchers get acknowledgment, maybe a hall of fame mention, and the knowledge that they helped without legal risk.

A bug bounty program adds financial rewards on top of that structure. Researchers get paid based on severity — typically using CVSS scores and a payout table. The scope is usually tighter, the triage SLAs are stricter, and the operational overhead is significantly higher because you're running a financial incentive program with all the audit and tax implications that come with it.

The practical takeaway: a VDP is the foundation. Every bug bounty program is built on top of a VDP-like policy. If you don't have a VDP yet, don't jump straight to bug bounty — you'll drown in report volume before you have the processes to handle it.

Why You Need a VDP Even If You Run Penetration Tests

Penetration tests are point-in-time assessments. A pentester works against a defined scope for a fixed window — typically two to four weeks — then writes a report. By the time you've remediated half the findings and deployed three new features, the test is already stale.

A VDP operates continuously. It captures what changes between tests: new endpoints you forgot to include in scope, third-party integrations your dev team added last sprint, configuration drift in production. Independent researchers are testing against your live environment, not a staging snapshot.

There's also a coverage argument. A single pentesting firm — even a good one — brings a limited set of researcher perspectives and tool sets. A VDP opens you up to dozens of researchers with different specializations: some focus on mobile APIs, some on authentication flows, some on business logic. The collective coverage is broader than any single engagement.

Finally, there's the legal exposure question. Without a VDP, a researcher who finds a critical vulnerability in your application has no clear signal that reporting it is safe. Some will report anyway and hope for the best. Others will go to a vulnerability broker. A VDP eliminates ambiguity and creates a documented good-faith channel.

The Legal Foundation: Safe Harbor Language

Safe harbor is the most important part of a VDP. Without it, you have a contact form — not a program. Safe harbor is a statement from you, the organization, that you will not pursue legal action against researchers who act in good faith within your defined scope.

The legal risk for researchers without safe harbor is real. In the US, the Computer Fraud and Abuse Act (CFAA) has historically been interpreted broadly. In the EU, the Directive on Attacks Against Information Systems carries similar risks. Researchers have been prosecuted under these laws for actions that were clearly well-intentioned. Your safe harbor language needs to be explicit and unconditional within scope.

A solid safe harbor clause covers these elements:

• No CFAA/equivalent claims — explicitly state you won't invoke computer fraud statutes against in-scope, good-faith research.
• No DMCA 1201 claims — relevant if researchers encounter obfuscated code or anti-circumvention measures during testing.
• No breach of terms of service claims — researchers often need to create test accounts or interact with systems in ways that technically violate ToS.
• Third-party pass-through — commit to not pursuing legal action through third parties (suppliers, hosting providers) either.
• Coordination before disclosure — your expectation of coordinated disclosure in exchange for safe harbor, with a defined embargo period.

Here's a minimal safe harbor clause you can adapt:

We consider security research conducted under this policy to be
authorized. We will not pursue civil action or refer matters to law
enforcement for researchers who make a good faith effort to comply
with this policy. We also will not bring a claim against you under
the Computer Fraud and Abuse Act (CFAA) or equivalent legislation.
If legal action is initiated by a third party against you in
connection with activities conducted under this policy, we will
take steps to make it known that your actions were conducted in
compliance with this policy.

Note what's not in there: vague language like "we'll try not to prosecute" or "we may consider" safe harbor. It has to be a commitment, not a hedge. Researchers read these policies carefully. Hedged language reads as a threat.

What a VDP Policy Should Include

A VDP policy is a public document. It needs to be unambiguous enough that a researcher can read it in five minutes and know exactly what they can and can't do, and what happens after they report.

Scope — what's in: List specific assets explicitly. Domains, subdomains, IP ranges, mobile apps, APIs. Don't write "all internet-facing assets" unless you mean it — researchers will test things you didn't intend to include. Be specific.

Out-of-scope: This is as important as the scope definition. Common out-of-scope items include: social engineering attacks against employees, physical security testing, denial of service attacks, automated scanning above a defined rate, and third-party services you don't control. Also explicitly call out any systems that are production-critical where even passive testing could cause disruption.

Prohibited activities: Even within in-scope assets, some techniques are off-limits. Accessing or modifying user data beyond what's needed to demonstrate the vulnerability. Exfiltrating data. Pivoting from a discovered vulnerability to other systems. Make this list concrete.

Disclosure timeline: Specify your expected response time (acknowledgment within X business days) and your remediation target. Also define your coordinated disclosure window — typically 90 days is the industry standard, aligned with Google Project Zero's policy. Researchers will hold back public disclosure for that period, after which they can go public regardless of whether you've patched.

Safe harbor language: As covered above — explicit, unconditional within scope.

Contact information: A dedicated email address (security@yourdomain.com) and optionally a PGP key for encrypted submissions. If you're using a platform like HackerOne, the submission form there.

What you will and won't do: State clearly that you will acknowledge receipt, keep reporters informed of remediation status, credit researchers who want acknowledgment, and not share their personal information without consent.

Setting Up Your Disclosure Channel

The channel is how researchers actually reach you. You have a few options, ranging from dead simple to fully managed.

security.txt

security.txt is a standardized file format (RFC 9116) that lives at /.well-known/security.txt on your domain. Security researchers and automated scanners check this file to find your disclosure contact. It's the minimum viable disclosure channel and takes about 20 minutes to set up.

Contact: mailto:security@yourdomain.com
Expires: 2027-01-01T00:00:00.000Z
Preferred-Languages: en
Policy: https://yourdomain.com/security/vdp
Acknowledgments: https://yourdomain.com/security/hall-of-fame

Generate and sign one at securitytxt.org. The Expires field is required — a stale security.txt with an expired date signals organizational neglect, which is the wrong message.

Dedicated security email

security@yourdomain.com should exist as a monitored inbox, not an alias that routes to a support ticket queue. Set it up with PGP support if you can — some researchers will only submit via encrypted channel, and if you can't receive PGP mail, you're cutting off a segment of the researcher community that cares most about OpSec.

HackerOne free plan

HackerOne offers a free tier specifically for VDPs. You get a public policy page, a structured submission form, a basic triage inbox, and automatic report deduplication. The free tier doesn't include triaged reports or the full researcher network, but it's a significant operational upgrade over email alone. It also lends credibility — researchers recognize the HackerOne platform and trust that submissions won't disappear into a void.

Bugcrowd and Intigriti

Bugcrowd offers a similar free VDP option. Intigriti is popular in the European market and worth considering if your user base is primarily EU-based (relevant for GDPR-adjacent credibility signals). Both platforms provide submission management, researcher profiles, and basic analytics. The paid tiers add managed triage, which is where the real operational value kicks in once you're handling volume.

Triage and Response Process

A VDP without a triage process is a black hole. Researchers submit reports, hear nothing for weeks, and conclude either that you don't care or that their report was buried. Both interpretations kill your program's reputation in the researcher community — and that reputation travels fast.

Who owns it

Assign a named owner for VDP operations. This doesn't have to be a full-time role, but someone needs to be accountable for the inbox. In most AppSec teams this is the AppSec engineer or security lead. At smaller companies it's often the CISO or a senior engineer with security responsibilities. The critical thing is that it's not a shared responsibility — shared responsibility means no responsibility.

SLA targets

Publish your SLA targets in the policy and then actually hit them. Industry-standard targets:

• Initial acknowledgment: 2 business days from submission
• Triage decision (valid/invalid/duplicate): 10 business days
• Remediation target for Critical/High: 30 days
• Remediation target for Medium: 90 days
• Remediation target for Low/Informational: best effort, no hard commitment

If you can't hit those targets, say so in the policy and publish realistic ones. A policy that says 5 days but delivers 30 days is worse than a policy that says 15 days and delivers in 12.

Severity tiers

Use a consistent severity framework. CVSS v3.1 is the standard and most researchers are familiar with it. Map your severity tiers to CVSS score ranges:

• Critical: CVSS 9.0–10.0 — RCE, authentication bypass, mass data exposure
• High: CVSS 7.0–8.9 — privilege escalation, SSRF with internal access, SQLi
• Medium: CVSS 4.0–6.9 — stored XSS, CSRF on sensitive actions, IDOR with limited data
• Low: CVSS 0.1–3.9 — reflected XSS with limited impact, information disclosure of non-sensitive data
• Informational: No CVSS — best practices deviations, missing headers, hardening recommendations

Duplicate handling

Duplicates are common once your program has any volume. The researcher who submits second doesn't get credit but deserves acknowledgment that their finding was valid and already known. Don't just mark as duplicate and close — tell them when it was first reported (without identifying the other researcher) and whether it's been remediated. That's basic professional courtesy and it keeps duplicate reporters from assuming their report is being ignored.

How to Respond to Researchers

Your response quality determines whether researchers bother submitting to you again. Template communication is fine — it's expected at volume — but templates should be warm, specific, and informative. Here are three core templates.

Acknowledgment (within 2 business days)

Subject: Re: [VDP] Your security report — received

Hi [Name],

Thank you for submitting this report. We've received it and it's
now in our triage queue. You can expect an update within
[X] business days with our initial assessment.

We take security reports seriously and appreciate researchers
who take the time to report responsibly.

[Your name]
Security Team, [Company]

Status update (on milestone changes)

Subject: Re: [VDP] Update on your report

Hi [Name],

Quick update on the vulnerability you reported on [date]:

Status: [Confirmed valid / In remediation / Remediated]
Severity: [Critical / High / Medium / Low]
Expected fix: [Date or sprint]

We'll follow up once the fix is deployed. Thank you for your
patience while we work through our remediation process.

[Your name]
Security Team, [Company]

Resolution notification

Subject: Re: [VDP] Report resolved — thank you

Hi [Name],

The vulnerability you reported on [date] has been remediated
and deployed to production as of [date].

[If hall of fame exists:] With your permission, we'd like to
add your name to our security acknowledgments page. Let us know
if you'd prefer to remain anonymous.

The coordinated disclosure window has now closed. You're free
to publish research about this finding. We'd appreciate a
heads-up before publication so we can be prepared to respond
to any customer questions.

Thank you for making [Company] more secure.

[Your name]
Security Team, [Company]

Common VDP Mistakes That Alienate Researchers

These patterns destroy program reputation and dry up the flow of good-faith reports.

Vague or overly restrictive scope. Writing "all our services" without listing them is useless. Writing a scope list so narrow that it excludes 90% of your attack surface means researchers won't bother — they can't test without risking going out of scope. Be specific and be generous with scope where you can safely be.

No safe harbor, or weak safe harbor. Phrases like "we'll try to work with researchers" or "we consider good faith testing" are not safe harbor. They're hedges that signal you might still come after researchers legally. Hard pass from any experienced researcher.

Slow or silent acknowledgment. If a researcher doesn't hear back within a week, they will either assume the report is lost, go public out of frustration, or both. Two-day acknowledgment is not a stretch goal — it's the minimum.

Challenging validity aggressively. Not every report will be valid or severe. But dismissing reports with "this is not a vulnerability" without explanation, or marking things as informational just to avoid remediation work, teaches researchers that your program is not worth their time.

Retroactive scope restriction. Adding something to the out-of-scope list after a researcher has already tested and submitted on it is bad faith. If you need to tighten scope, grandfather in anything already submitted before announcing the change.

No disclosure path. Researchers operate under coordinated disclosure norms. They hold findings for a defined window, then publish. If your VDP says "we don't allow public disclosure," full stop — you're not running a VDP, you're running a gag order. Researchers will route around it. Define a disclosure window (90 days is standard) and respect it.

Graduating from VDP to Bug Bounty: When and How

A bug bounty program is an amplifier. If your triage process is broken, adding money makes it more broken faster. The prerequisites for a healthy bug bounty launch:

• Your VDP has been running for at least 6 months with consistent SLA performance
• You have dedicated triage bandwidth — at minimum, someone who can spend 25–30% of their time on report handling
• Your remediation pipeline is functional — reports are actually getting fixed, not accumulating in a backlog
• You have legal sign-off on payout terms and tax implications for researcher payments
• You've defined your payout table and can afford the expected volume at that table

When you do launch, start private. Invite 10–20 vetted researchers from the HackerOne or Bugcrowd community rather than opening publicly. A private program lets you validate your triage process under controlled load before you're exposed to the full researcher market.

Your payout table should reflect actual business risk, not just CVSS scores. An SSRF that only hits an internal metadata endpoint is CVSS 8.6 on paper but Low business impact if you're already blocking the dangerous metadata paths. Calibrate severity to actual exploitability in your environment.

Platform fees on HackerOne and Bugcrowd run roughly 10–20% of payout amounts for managed programs. Factor that into your budget. Intigriti runs competitive fee structures and is worth comparing for European-focused programs.

VDP Compliance: CISA VDP Directive, ISO 29147, EU CRA

VDPs have moved from best practice to regulatory expectation in several jurisdictions and sectors.

CISA BOD 20-01

Binding Operational Directive 20-01 mandates that all US federal civilian executive branch agencies implement a VDP for internet-facing systems. It established the framework that influenced much of the current VDP guidance from CISA. If you sell to US federal agencies, your VDP program and its maturity will be evaluated as part of procurement risk assessments.

ISO/IEC 29147

ISO 29147 is the international standard for vulnerability disclosure. It defines the process and responsibilities for receiving and handling vulnerability reports. ISO 29147 pairs with ISO 30111 (vulnerability handling processes) — together they form the standards framework for mature disclosure programs. If you're pursuing ISO 27001 certification, a VDP aligned with 29147 strengthens your information security posture documentation significantly.

EU Cyber Resilience Act (CRA)

The EU CRA, which entered into force in 2024 with a phase-in through 2027, requires manufacturers of products with digital elements to have a process for handling reported vulnerabilities. For SaaS products sold in the EU market, this effectively mandates a VDP or equivalent. The CRA requires acknowledgment of vulnerabilities without undue delay and remediation within defined timelines. A documented VDP policy directly satisfies this requirement.

NIS2 Directive

The EU's NIS2 Directive requires essential and important entities to implement coordinated vulnerability disclosure policies. If your organization falls under NIS2 scope (which covers a broad set of sectors including digital infrastructure and digital service providers), a VDP is not optional — it's a compliance requirement. ENISA's EUVD (European Union Vulnerability Database) is the coordinating body for EU-level disclosure.

Beyond compliance, a published VDP signals organizational maturity to enterprise buyers. Security questionnaires increasingly ask whether you have a VDP and what your response SLAs are. A link to your policy is a faster answer than a 300-word explanation of your informal process.

Setting up a VDP is a one-time investment that pays compounding returns: continuous coverage between penetration tests, legal clarity for researchers, and a documented process that satisfies an expanding set of compliance requirements. The operational overhead is manageable — a monitored inbox, a public policy page, and the discipline to respond within your stated SLAs. Start simple. Iterate. Graduate to bug bounty when your triage process can handle the load. The researchers who report responsibly are doing you a service — make it easy for them to do it safely.