How to Set Up a Vulnerability Disclosure Program in 2026

A vulnerability disclosure program (VDP) is a structured process that lets external security researchers report bugs in your product safely and legally. Unlike a bug bounty program, which pays per vulnerability, a VDP establishes a clear channel for receiving reports without requiring a financial reward. Every company with an internet-facing product needs one. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) made VDPs mandatory for federal agencies in 2020 through Binding Operational Directive 20-01, and the private sector has followed rapidly since.

Why your startup needs a VDP now

Security researchers are going to find vulnerabilities in your product whether you have a VDP or not. The question is what happens next.

Without a disclosure channel, a researcher who finds a SQL injection in your checkout flow has three options: email your generic support address and hope someone technical reads it, post it publicly on social media, or sell it. None of these are good for you. Web application vulnerabilities remain pervasive, with the OWASP Top Ten documenting the most critical security risks facing organizations. A single undisclosed vulnerability can become a data breach that costs your company its reputation and its customers.

The economics are compelling. According to IBM’s 2024 Cost of a Data Breach Report, the average cost of a data breach reached $4.88 million globally. For startups, a breach of that magnitude is often fatal. Meanwhile, setting up a VDP costs effectively nothing. You need a policy document, a secure intake channel, and someone to triage reports. Compare that to hiring a full-time penetration testing firm, which runs $15,000 to $50,000 per engagement according to SANS Institute estimates.

Regulatory pressure is accelerating too. The EU’s NIS2 Directive, effective October 2024, requires organizations operating in critical sectors to implement coordinated vulnerability disclosure. The U.S. SEC’s 2023 cybersecurity disclosure rules demand public companies report material incidents within four business days. Having a VDP is the minimum infrastructure to handle those obligations.

VDP vs. bug bounty: which comes first?

A VDP is the foundation. A bug bounty adds a financial incentive layer on top. Starting with a bug bounty before you have the triage process to handle reports is a common and expensive mistake.

Feature	Vulnerability Disclosure Program	Bug Bounty Program
Cost	Free (no payouts required)	$500-$50,000+ per valid report
Scope	All vulnerabilities	Defined scope with exclusions
Researchers	Anyone	Attracts experienced hunters
Legal safe harbor	Essential	Essential
Triage workload	Moderate	High (more volume)
Best for	Every company, starting day one	Companies with mature security teams

HackerOne’s 2024 Hacker-Powered Security Report found that 77% of organizations running bug bounties started with a VDP first. Build the process before you add the budget.

What goes into a VDP policy

Your VDP policy is a legal document, a communication tool, and a set of operational commitments. It needs to cover five areas clearly.

Scope: what researchers can test

Define exactly which assets are in scope. Be specific about domains, IP ranges, mobile apps, and APIs. Ambiguity here creates problems in both directions: researchers waste time on out-of-scope assets, and you receive reports you cannot action.

A strong scope statement looks like this:

• In scope: *.yourcompany.com, iOS app (App Store), Android app (Google Play), public API at api.yourcompany.com
• Out of scope: Third-party services (Stripe, Intercom), physical security, social engineering of employees

Safe harbor: legal protection for researchers

This is the single most important section of your policy. Without clear safe harbor language, researchers will not report to you. They will worry about prosecution under the Computer Fraud and Abuse Act (CFAA) in the U.S. or equivalent laws in other jurisdictions.

The Department of Justice’s 2022 CFAA guidance explicitly states that “good-faith security research should not be charged.” Your policy should mirror this language. A minimum safe harbor clause includes:

1. A commitment not to pursue legal action against researchers who follow the policy
2. A commitment not to pursue CFAA or DMCA claims for good-faith research
3. A statement that you will work with researchers if third parties initiate legal action
4. Recognition that research conducted within the policy is authorized

Reporting requirements: what you need from researchers

Tell researchers exactly what to include in their report. A template saves time for both sides:

• Vulnerability type (e.g., XSS, SSRF, broken access control)
• Affected URL or endpoint
• Steps to reproduce (specific, numbered steps)
• Impact assessment (what data is exposed, what access is gained)
• Screenshots or proof-of-concept (video preferred for complex chains)
• Researcher contact information (for follow-up)

Response commitments: your SLAs

Researchers have been conditioned by years of being ignored. According to HackerOne’s data, the median time to first response across all programs is 8 hours, but the top quartile responds within 1 hour. Your SLAs signal whether you take security seriously.

Define and publish these timelines:

• Acknowledgment: within 2 business days
• Triage decision: within 5 business days
• Status update: at least every 14 days until resolution
• Fix timeline: based on severity (critical: 7 days, high: 30 days, medium: 90 days)

Disclosure timeline: coordinated vs. full

Most VDPs use coordinated disclosure: the researcher agrees to stay silent while you fix the issue, and you agree to fix it within a defined window (typically 90 days, aligning with Google Project Zero’s standard). After that window, the researcher can publish.

Be explicit about this. Researchers respect organizations that commit to timelines. They distrust organizations that ask for indefinite silence.

How to write your security.txt file

The security.txt standard (RFC 9116) gives your VDP a machine-readable entry point. It is a plain text file at /.well-known/security.txt that tells automated tools and researchers where to report vulnerabilities.

A complete security.txt includes:

Contact: mailto:[email protected]
Contact: https://yourcompany.com/security/report
Expires: 2027-03-15T00:00:00.000Z
Encryption: https://yourcompany.com/.well-known/pgp-key.txt
Policy: https://yourcompany.com/security/policy
Preferred-Languages: en
Canonical: https://yourcompany.com/.well-known/security.txt

The Expires field is mandatory in RFC 9116. Set it no more than one year out and put a recurring reminder to update it. An expired security.txt signals abandonment, which is worse than not having one at all.

According to data from securitytxt.org, adoption among the Alexa Top 1 Million has grown from under 2% in 2022 to approximately 8% in 2025. Among companies that have experienced a public breach disclosure, adoption jumps to over 30%. Do not wait for a breach to publish yours.

Step-by-step: launching your VDP in one week

You do not need months of planning to launch a VDP. Here is a concrete timeline for a startup with 5-50 employees.

Day 1-2: Write the policy

Start with the disclose.io community templates. Their safe harbor language has been reviewed by legal teams at organizations including the EFF, Dropbox, and Bugcrowd. Customize the scope section for your assets and have your legal counsel review (most startup lawyers can turn this around in 24 hours).

Day 3: Set up the intake channel

You need a secure, reliable way to receive reports. Options include:

• Dedicated email ([email protected]) with PGP encryption
• Web form on your security page with TLS and access controls
• Platform (HackerOne, Bugcrowd, Intigriti) for managed intake and triage

A dedicated email works for most startups. Add a PGP key so researchers can encrypt sensitive details. If you expect more than five reports per month, a platform will save significant triage time.

Day 4: Publish security.txt and your policy page

Create your security.txt file and publish it at /.well-known/security.txt. Create a /security page on your website that contains your full policy, scope, and reporting instructions.

Day 5: Build the triage workflow

Define who receives reports, how they are prioritized, and how fixes are tracked. At minimum:

1. Intake: Security reports arrive at a dedicated channel (email, platform, or form)
2. Triage: An engineer assesses severity within 2 business days using CVSS 4.0
3. Track: Create an internal ticket in your issue tracker (do not put vulnerability details in public GitHub issues)
4. Fix: Assign to the relevant team based on affected component
5. Respond: Update the researcher at each stage
6. Close: Confirm the fix with the researcher, offer credit in your hall of fame

Day 6-7: Test and announce

Submit a test report through your own process. Verify the acknowledgment email works, the triage workflow fires, and the response templates are clear. Then announce your VDP:

• Add a link from your website footer
• Post on your engineering blog
• Notify relevant security communities

Common mistakes that kill VDP credibility

Ignoring reports

The fastest way to destroy your VDP’s reputation is to not respond. Researchers talk to each other. If three people report issues and hear nothing, your program is effectively dead. HackerOne’s data shows that programs with response times over 7 days see 40% fewer submissions over the following quarter.

Scope that is too narrow

Limiting your scope to a single marketing page while your actual attack surface includes APIs, mobile apps, and third-party integrations tells researchers you are not serious. If you are not ready to fix issues across your full surface area, be honest about it in the policy, but plan to expand.

Threatening researchers

This still happens. In 2023, a major airline threatened legal action against a researcher who reported a vulnerability through their official channel. The resulting backlash cost them far more in reputation damage than the vulnerability fix would have cost. Your safe harbor language exists to prevent this. Make sure your legal team and executive leadership understand and support it.

No feedback loop

Researchers want to know their report mattered. Send them the CVE ID if one is assigned. Tell them when the fix ships. Offer credit in your security advisories. This costs nothing and builds a relationship that generates more high-quality reports.

Severity scoring with CVSS 4.0

The Common Vulnerability Scoring System version 4.0, released by FIRST.org in November 2023, is the current standard for assessing vulnerability severity. CVSS 4.0 introduced significant improvements over 3.1, including supplemental metrics for Automatable, Recovery, and Value Density.

Use CVSS to create consistent SLA tiers:

CVSS 4.0 Score	Severity	Response SLA	Fix SLA
9.0-10.0	Critical	4 hours	7 days
7.0-8.9	High	24 hours	30 days
4.0-6.9	Medium	2 business days	90 days
0.1-3.9	Low	5 business days	Best effort

Do not invent your own severity scale. CVSS is an imperfect standard, but it is a shared language between your team and the researcher community. Deviating from it creates confusion and disputes.

Scaling from VDP to bug bounty

Once your VDP has been running for 3-6 months and you have a reliable triage workflow, you are ready to consider adding financial rewards.

When to add bounties

You are ready when:

• Your average time to first response is under 24 hours
• You have fixed at least 80% of reported vulnerabilities within your published SLAs
• You have a dedicated security contact (does not need to be full-time)
• Your engineering team has a process for prioritizing security fixes alongside feature work

Setting reward amounts

Bounty amounts should reflect the actual impact of the vulnerability, not a flat rate. HackerOne’s 2024 data shows median payouts across industries:

• Critical: $3,000-$15,000 (remote code execution, auth bypass)
• High: $1,000-$5,000 (stored XSS, IDOR with PII exposure)
• Medium: $250-$1,000 (reflected XSS, information disclosure)
• Low: $50-$250 (open redirect, verbose error messages)

For startups, starting at the lower end of these ranges is fine. Researchers care more about responsiveness and respect than maximum payouts. A program that pays $500 and responds in 4 hours will attract better talent than one that pays $5,000 and ignores reports for weeks.

Compliance frameworks that require a VDP

A VDP is not just good practice. Several compliance frameworks now explicitly require one.

SOC 2 Type II: While SOC 2 does not mandate a VDP by name, the Common Criteria related to risk assessment (CC3.2) and communication (CC2.3) are significantly easier to satisfy with a documented VDP. Auditors increasingly ask for evidence of external vulnerability intake.

ISO 27001:2022: Control A.8.8 (Management of technical vulnerabilities) requires organizations to “establish and implement rules for disclosure of vulnerabilities.” A VDP directly satisfies this control.

PCI DSS 4.0: Requirement 6.3.1 mandates that organizations identify and manage security vulnerabilities, including through external sources. A VDP demonstrates compliance with the “external source” requirement.

NIST Cybersecurity Framework 2.0: The Identify function (ID.RA-01) calls for “vulnerabilities in assets” to be “identified, validated, and recorded,” explicitly including external discovery. The framework’s new Govern function (GV.SC-05) adds supply chain risk management, where VDPs play an increasingly important role.

NIS2 Directive (EU): Article 12 requires EU member states to establish coordinated vulnerability disclosure policies. Organizations in essential and important sectors must participate.

If your startup serves enterprise customers, having a VDP often shows up in security questionnaires. According to a 2024 Whistic survey, 64% of enterprise buyers include vulnerability management in vendor security assessments. Having a published VDP shortens your sales cycle by giving procurement teams an immediate answer.

Hall of fame: recognizing researchers

A public hall of fame costs nothing to maintain and generates significant goodwill with the security research community. It acknowledges researchers who have responsibly disclosed vulnerabilities and incentivizes future reports without requiring financial rewards.

Your hall of fame should include:

• Researcher name or handle (as they prefer to be credited)
• Date of disclosure
• General category of the vulnerability (without revealing exploitable details)

Do not publish full vulnerability details, affected endpoints, or reproduction steps in your hall of fame. Keep it to names and dates. The detailed security advisory (if published) should be a separate document, released after the fix has been deployed and verified.

Some researchers build their professional reputation through hall of fame credits. For independent consultants and students, a public credit from your company can be more valuable than a small bounty. Treat it with the seriousness it deserves.

How Kit handles vulnerability disclosure

Kit includes a built-in CSIRT (Computer Security Incident Response Team) module that handles vulnerability disclosure as a first-class workflow, not an afterthought grafted onto a ticketing system.

The module ships with a customizable security portal that researchers access through your domain. You publish your VDP policy, scope, and reporting guidelines directly from Kit. Researchers submit reports through a structured form that collects the exact information your triage team needs: vulnerability type, affected assets, reproduction steps, and impact assessment. No more parsing free-text emails or losing reports in a shared inbox.

Every report flows through a defined triage pipeline with configurable SLAs. Kit tracks time-to-first-response, time-to-triage, and time-to-resolution automatically. When a deadline approaches, the assigned team member gets notified. When it passes, escalation rules fire. This is the same SLA enforcement pattern used by dedicated platforms like HackerOne, built into the same tool your team already uses for hiring.

Kit generates and maintains your security.txt file automatically, including the mandatory Expires field with a recurring check that warns you before it lapses. The security portal supports custom domains, so researchers interact with security.yourcompany.com rather than a third-party platform.

The module also includes a public hall of fame, Slack integration for real-time report notifications, and researcher communication through the portal itself. Disbursements for bug bounty payouts are tracked with a full ledger, giving you audit-ready records for SOC 2 and ISO 27001 reviews.

For startups that need both hiring and security infrastructure, Kit eliminates the need to manage separate platforms. Your CSIRT module runs alongside your ATS, using the same team accounts, the same Slack workspace, and the same billing. That means one fewer vendor, one fewer security questionnaire to fill out, and one fewer login for your team.

Checklist: launch your VDP this week

Use this checklist to track your progress. Every item can be completed by a single engineer in a week.

1. Draft your VDP policy using disclose.io templates
2. Define your scope (domains, APIs, mobile apps)
3. Write safe harbor language and have legal counsel review
4. Set up a secure intake channel (email with PGP, web form, or platform)
5. Create your security.txt file at /.well-known/security.txt
6. Publish your policy page at /security or /security/policy
7. Define severity tiers and response SLAs using CVSS 4.0
8. Build internal triage workflow (who receives, who triages, who fixes)
9. Create response templates (acknowledgment, triage decision, status update, resolution)
10. Set up a public hall of fame page
11. Submit a test report through your own process
12. Announce your VDP (website footer, blog post, security communities)

A VDP is not a one-time project. It is an ongoing commitment to your users that you take their security seriously. The setup takes a week. The credibility it builds takes years. Start now, while it is still a competitive advantage rather than a regulatory checkbox you are scrambling to satisfy.