How to Set Up a Vulnerability Disclosure Program in 2026

A vulnerability disclosure program (VDP) is a structured process that gives external security researchers a safe, legal channel to report bugs in your product. Unlike a bug bounty, which pays per finding, a VDP simply establishes the intake mechanism. 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 Before Anything Else

Security researchers are going to find vulnerabilities in your product whether you invite them to or not. The only question is what happens next.

Picture this: a researcher discovers an SQL injection in your API. Without a VDP, they have three options: email your generic support address and hope someone technical reads it, post it publicly on social media, or sell it on a forum. None of those outcomes are good for you. With a VDP, the researcher has a clear path to report the finding, and your team has a structured process to triage and fix it before it becomes a breach.

The economics are stark. IBM’s 2024 Cost of a Data Breach Report puts the average breach cost at $4.88 million globally. For a seed-stage startup, that figure is existential. Meanwhile, setting up a VDP costs nothing beyond engineering time. Compare that to a penetration testing engagement, which typically runs $15,000 to $50,000 per assessment.

Regulatory pressure is accelerating too. The EU’s NIS2 Directive, effective October 2024, requires organizations in critical sectors to implement coordinated vulnerability disclosure. The U.S. SEC’s 2023 cybersecurity rules demand public companies report material incidents within four business days. SOC 2 auditors increasingly ask for evidence of external vulnerability intake, and several Trust Services Criteria (CC7.1, CC7.2) map directly to VDP capabilities. If you plan to sell to enterprise customers, having a published VDP shows up in security questionnaires. Vulnerability management questions are now standard in vendor security assessments, and a VDP gives procurement teams an immediate answer that shortens your sales cycle.

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 can handle the report volume is a common and expensive mistake.

HackerOne’s 2024 Hacker-Powered Security Report found that 77% of organizations running bug bounties started with a VDP first. The thesis is simple: build the process before you add the budget. A five-person startup cannot match Google’s triage velocity, but it can absolutely run a professional VDP.

The Four Phases of VDP Implementation

Launching a VDP is not a weekend project, but it does not require months of planning either. The process breaks into four phases that a single engineer can complete in one week.

Phase 1: Scope Definition

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

In scope: production web applications, public APIs, mobile apps, specific subdomains you control. Out of scope: internal corporate infrastructure, employee accounts, third-party SaaS tools (Stripe, Intercom), and physical security.

Overly broad scope is dangerous for a seed-stage company with limited engineering capacity. If a researcher reports a vulnerability in a staging environment you forgot you left public, you still need to respond. But overly narrow scope sends a different signal. Limiting your VDP to a single marketing page while your real attack surface includes APIs and mobile apps tells researchers you are not serious.

The sweet spot: scope everything your customers touch. That means production web apps, public APIs, and any mobile clients you ship. Exclude anything you cannot fix (third-party integrations, vendor-managed infrastructure).

Phase 2: Reporting Mechanisms and security.txt

Researchers need a secure, reliable channel to submit findings. The minimum viable approach is a dedicated [email protected] email address with PGP encryption. For startups receiving more than a handful of reports per month, a structured web form or a managed platform (HackerOne Response, Bugcrowd VDP, Intigriti) saves significant triage time.

Whichever channel you choose, the discovery mechanism is standardized: security.txt. Defined in RFC 9116, this is a machine-readable plain text file at /.well-known/security.txt that tells researchers exactly where and how to report vulnerabilities.

A complete security.txt looks like this:

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. Set it no more than one year out and put a recurring calendar reminder to update it. An expired security.txt signals an unmaintained program, which is worse than not having one. Adoption is still low. According to securitytxt.org data, only about 1.25% of the top one million websites publish a security.txt file as of 2025, up from roughly 0.5% in 2022. The low adoption means yours will stand out to researchers. Publish it before you need it.

Phase 3: Safe Harbor Policy

This is the most legally sensitive component of your VDP. 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 internationally.

The Department of Justice’s 2022 CFAA guidance explicitly states that “good-faith security research should not be charged.” Your safe harbor clause must include four commitments: a promise not to pursue legal action against researchers who follow the policy, a commitment not to pursue CFAA or DMCA claims for good-faith research, a statement that you will work with researchers if third parties initiate legal action, and recognition that research conducted within the policy is authorized.

A poorly worded safe harbor can either expose the company to liability or fail to protect researchers, causing them to avoid reporting entirely. Start with the disclose.io community templates, which have been reviewed by legal teams at the EFF, Dropbox, and Bugcrowd. Then have your own legal counsel review. Most startup lawyers can turn this around in 24 hours.

Do not draft safe harbor language from scratch. This is a legal document. The disclose.io templates exist precisely so startups do not have to pay $10,000 in legal fees to write one.

Phase 4: Internal SLAs and Triage Process

Response time is the single strongest signal of whether your VDP is real or performative. HackerOne’s Success Index consistently shows that programs with fast response times attract significantly more and higher-quality submissions. Researchers talk to each other. If three people report issues and hear nothing, your program is effectively dead.

Define and publish these SLAs, calibrated to what a small team can actually deliver:

Use CVSS 4.0 (FIRST.org specification, released November 2023) for severity scoring. Do not invent your own scale. CVSS is imperfect, but it is a shared language between your team and the researcher community.

Build a triage workflow that covers five stages: intake (reports arrive at a dedicated channel), triage (an engineer assesses severity using CVSS), tracking (create an internal ticket, never in public GitHub issues), remediation (assign to the relevant team), and response (update the researcher at each transition). When the fix ships, notify the researcher and offer credit in a public hall of fame.

Compliance Frameworks That Require a VDP

A VDP is not just good practice. Several frameworks now explicitly require or strongly incentivize one.

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

ISO 27001:2022 Control A.8.8 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 identifying and managing security vulnerabilities from external sources. A VDP demonstrates compliance with that requirement.

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

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

For a seed-stage startup, the compliance argument is forward-looking. You may not need SOC 2 today, but your first enterprise contract will ask for it. Having a VDP already running when the auditor arrives saves months of scrambling.

From VDP to Bug Bounty: When to Add Financial Rewards

Once your VDP has been running for three to six months with a reliable triage workflow, you can consider adding 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, and your engineering team has a process for prioritizing security fixes alongside feature work.

Bounty amounts should reflect actual impact. HackerOne’s 2024 data shows median payouts: Critical (remote code execution, auth bypass): $3,000 to $15,000. High (stored XSS, IDOR with PII exposure): $1,000 to $5,000. Medium (reflected XSS, information disclosure): $250 to $1,000. Low (open redirect, verbose errors): $50 to $250.

For startups, starting at the lower end 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.

How Kit Handles Vulnerability Disclosure

Kit includes a built-in CSIRT (Computer Security Incident Response Team) module that treats vulnerability disclosure as a first-class workflow.

The module ships with a customizable security portal on your domain. Researchers submit structured reports with 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 triage pipeline with configurable SLAs. Kit tracks time-to-first-response, time-to-triage, and time-to-resolution automatically, notifying assignees as deadlines approach and firing escalation rules when they pass.

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 URL.

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 when your SOC 2 or ISO 27001 review arrives.

For startups that need both hiring and security infrastructure, running both from one platform means one fewer vendor, one fewer security questionnaire, and one fewer login for your team.

Launch Your VDP This Week

You do not need months of planning. Here is what one engineer can accomplish in five days.

Day 1 to 2: Write the policy. Start with disclose.io templates. Define scope. Have legal review the safe harbor language.

Day 3: Set up the intake channel. Configure a security@ email with PGP, or set up a web form. Publish your security.txt at /.well-known/security.txt.

Day 4: Build the triage workflow. Define who receives reports, how severity is assessed, and how fixes are tracked internally.

Day 5: Test by submitting a report through your own process. Verify acknowledgment emails fire, triage workflow routes correctly, and response templates are clear. Then announce: add a link to your website footer, post on your engineering blog, and notify relevant security communities.

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