CVD Policy Template: How to Build a Responsible Disclosure Program

Every organization with an internet-facing presence will eventually receive a message from a security researcher who found something in your systems. What happens next — whether the disclosure becomes a coordinated fix or a public breach notification — depends almost entirely on whether you have a Coordinated Vulnerability Disclosure (CVD) policy in place before that message arrives.

This guide walks through what a CVD policy is, how it differs from a bug bounty program, what legal frameworks demand it, and exactly how to write one. A ready-to-use policy template is included below.

What Is Coordinated Vulnerability Disclosure — and Why Every Organization Needs It

Coordinated Vulnerability Disclosure is the practice of a security researcher privately notifying an organization about a vulnerability, giving the organization a reasonable window to develop and release a fix, and then disclosing the issue publicly once that window closes. The coordination is the key word: neither party acts unilaterally.

Without a formal CVD policy, researchers face a frustrating guessing game. Who do they email? Will reporting expose them to legal liability? Will the company simply ignore them, or worse, threaten them? Absent clear answers, many researchers default to full public disclosure, posting technical details before you have a patch ready. A well-written CVD policy removes that uncertainty on both sides.

From an organizational standpoint, the stakes are clear. Unpatched vulnerabilities disclosed publicly give attackers a ready-made exploit. A CVD program turns the researcher community into an extended, unpaid security team — directing findings to your inbox rather than to a Twitter thread or a forum post.

CVD vs Bug Bounty: The Key Differences

The terms are often used interchangeably, but they describe different things.

A CVD policy is a process document. It costs nothing to implement and requires no bounty budget. It simply tells researchers how to report, what to expect, and that you will not sue them for doing so in good faith. Any organization — a two-person startup or a national government agency — can publish a CVD policy today.

A bug bounty program adds a financial incentive layer. Valid findings receive monetary rewards according to a severity-based payout table. Bug bounty programs typically run through third-party platforms (HackerOne, Bugcrowd, Intigriti) that handle researcher vetting, triage support, and payment processing. They attract higher-volume and higher-skill researchers, but they carry ongoing cost and operational overhead.

CVD is the foundation that any organization should have. Bug bounty is an optional, paid extension that makes sense once your security team has the capacity to manage increased report volumes. Build the CVD policy first.

Legal Foundations: Why Safe Harbor Language Matters

The single biggest reason security researchers hesitate to report vulnerabilities is fear of prosecution. In the United States, the Computer Fraud and Abuse Act (CFAA) is broad enough that probing a system — even to find and report a flaw — can theoretically be construed as unauthorized access. In Europe, similar computer misuse statutes apply at the national level.

Safe harbor language in your CVD policy is a contractual statement from your organization that researchers acting within the defined scope and in good faith will not face legal action for their research activity. It does not grant unlimited immunity, but it establishes a clear expectation that you are inviting this type of research and will not respond punitively.

The Dutch government pioneered the modern CVD model starting in 2013, and the Dutch National Cyber Security Centre (NCSC-NL) published a widely referenced framework that influenced international practice. That framework is explicit: good-faith disclosure should never result in criminal charges or civil litigation.

At the EU level, NIS2 Directive Article 12 now mandates that EU member states establish national CVD policies and require essential entities — energy, transport, banking, health, digital infrastructure, and others — to accept and act on vulnerability disclosures. For organizations subject to NIS2, a functioning CVD program is no longer optional. You can read more about the broader NIS2 compliance requirements in our PSIRT guide and TISAX guide for automotive sector organizations.

What a CVD Policy Must Include

1. Scope

Define which assets researchers are authorized to test. Be specific.

In scope: your primary domain and subdomains, production web applications, public-facing APIs, mobile applications listed in app stores, and any systems you explicitly enumerate.

Out of scope: third-party services you do not control, customer data environments, physical security testing, social engineering, denial-of-service testing, and any systems not listed as in scope. Out-of-scope clarity protects both parties.

2. Safe Harbor / Good Faith Clause

This is the legal heart of the policy. State explicitly that:

• You authorize security research within the defined scope.
• You will not initiate legal action against researchers who comply with the policy.
• You will not refer researchers to law enforcement for good-faith testing activity.
• If a third party initiates legal proceedings, you will make your authorization clear.

3. Reporting Channel

Tell researchers exactly how to reach you. Options include:

• A dedicated security email address (security@yourdomain.com)
• A web-based submission form with optional anonymity
• A security.txt file at /.well-known/security.txt (see below)

Make at least one channel publicly documented and easy to find.

4. Response Timeline Commitments

Researchers need to know how long to wait before going public. Industry-standard timelines are:

• Acknowledgment: within 5 business days of receiving a report
• Initial assessment / triage: within 15 business days
• Patch or mitigation: within 90 days for standard findings; critical vulnerabilities warrant faster action
• Coordinated public disclosure: no later than 120 days from initial report, whether or not a fix is complete

If you need more time, communicate proactively. Researchers generally accept extensions when you explain the reason and maintain contact.

5. What You Will NOT Do to Researchers

State explicitly that you will not:

• File criminal or civil legal action against researchers acting in good faith
• Demand removal of published research once disclosed per the agreed timeline
• Pursue researchers through their employer or hosting provider
• Engage in public shaming or negative press activity

This list signals organizational culture as much as legal commitment.

6. Encryption

Offer a PGP public key so researchers can encrypt sensitive reports. Post the key fingerprint in your policy and in your security.txt file. Some researchers will not submit a critical finding over plain email.

security.txt: The RFC 9116 Standard

security.txt is a simple plain-text file that lives at /.well-known/security.txt on your web server. Defined in RFC 9116 (published by the IETF in 2022), it gives researchers a machine-readable and human-readable pointer to your security contact and policy.

A minimal security.txt file looks like this:

Contact: mailto:security@yourdomain.com
Expires: 2027-01-01T00:00:00z
Encryption: https://yourdomain.com/pgp-key.txt
Policy: https://yourdomain.com/security-policy
Preferred-Languages: en

The Expires field is mandatory under RFC 9116 — an expired file signals that the contact may be stale. Update it annually. The Policy field links to your full CVD policy document. Sign the file with your PGP key if possible, which allows tools to verify its authenticity.

For NIS2-regulated entities, publishing a security.txt is effectively mandatory. For everyone else, it is a low-effort signal that your organization is security-aware and researcher-friendly.

CVD Policy Template

The following template is ready to adapt. Replace bracketed placeholders with your organization's specifics.

---

Vulnerability Disclosure Policy — [Organization Name]

Effective date: [Date]

Our commitment

[Organization Name] is committed to protecting the security of our systems and our users. We welcome reports from security researchers who discover vulnerabilities in our products and services. This policy defines how to report vulnerabilities, what you can expect from us, and the legal protections that apply to good-faith research.

Scope

The following assets are in scope for security research under this policy:

• [domain.com] and all subdomains
• [mobile app name] on iOS and Android
• [API endpoints at api.domain.com]

The following are out of scope:

• Third-party services integrated with our platform (report these to the relevant vendor)
• Denial-of-service or load testing
• Social engineering of our employees or customers
• Physical security testing
• Any system not listed above as in scope

Safe harbor

We consider security research conducted under this policy to be authorized. We will not initiate or support legal action against researchers who:

1. Report findings promptly and do not exploit vulnerabilities beyond what is necessary to demonstrate the issue.
2. Avoid accessing, modifying, or deleting data beyond what is needed to confirm the vulnerability.
3. Do not disclose the vulnerability publicly before the coordinated disclosure date.
4. Act in good faith and comply with all other terms of this policy.

If a third party initiates legal action against a researcher in connection with research conducted under this policy, we will take steps to make known that the research was authorized.

How to report

Send vulnerability reports to: security@[yourdomain.com]

For encrypted submissions, use our PGP key (fingerprint: [XXXX XXXX XXXX XXXX]).

You may also submit via our web form at: [https://yourdomain.com/report-vulnerability]

Include in your report:

• Asset affected and vulnerability type
• Step-by-step reproduction instructions
• Proof-of-concept code or screenshots if applicable
• Your assessment of impact and severity
• Any CVEs or references you are aware of

Response timelines

Milestone	Target
Acknowledgment	5 business days
Initial triage	15 business days
Status update	Every 30 days
Patch / mitigation	90 days (critical: 30 days)
Coordinated public disclosure	120 days from initial report

If we require additional time beyond these targets, we will communicate proactively and negotiate an extension.

What we will not do

We will not:

• File criminal complaints or civil actions against researchers acting in good faith under this policy
• Demand suppression of published research past the agreed disclosure date
• Contact researchers' employers or hosting providers
• Publicly disparage reporters

Recognition

With your permission, we will acknowledge your contribution in our Hall of Thanks at [https://yourdomain.com/security/thanks].

---

Handling a Disclosure: From Inbox to Patch

Receiving a report is the beginning of a process, not the end. Your internal workflow should cover these stages:

Triage: Assign the report to a qualified engineer within 24 hours of acknowledgment. Confirm whether the issue is reproducible and assess severity using CVSS or an equivalent framework. Flag critical findings immediately to senior leadership.

Communication: Send the researcher a substantive update within 15 business days — not just a confirmation that you received their email. Tell them what you found, your severity assessment, and your target remediation date. Silence erodes trust and accelerates public disclosure.

Patching: Develop, test, and stage the fix. For web applications this is often fast. For embedded firmware or supply-chain components it may take longer — communicate any extensions openly.

Coordinated public disclosure: On the agreed date (or earlier if both parties agree), publish a security advisory. Credit the researcher by name unless they have requested anonymity. A clear advisory with mitigation guidance reduces downstream harm and demonstrates organizational maturity.

Post-incident review: Document what the researcher found, how long remediation took, and what process improvements would close the gap faster next time. Feed this back into your security program.

NIS2 Article 12: Mandatory CVD for Essential Entities

For organizations operating in the EU, the NIS2 Directive — which became applicable across member states in October 2024 — has direct implications. Article 12 requires that each member state establish national CVD policies and designate a single point of contact for cross-border coordination. Essential and important entities are expected to maintain vulnerability handling and disclosure capabilities as part of their risk management obligations.

In practice, this means that a functioning CVD policy, a published security.txt, and a documented internal triage process are compliance requirements, not best-practice recommendations. Supervisory authorities can request evidence of your vulnerability handling procedures during audits. Organizations building NIS2 compliance programs should treat CVD policy implementation as a near-term priority alongside other controls such as incident response planning and supply chain risk management.

If you are working through NIS2 obligations or setting up a security incident response team, our PSIRT guide covers the product security incident response function in detail, and our TISAX guide addresses the automotive-specific requirements that intersect with vulnerability management.

Putting It Into Practice

A CVD policy does not need to be long or complicated. The template above covers everything required. What matters is that it exists, that it is publicly accessible, and that your internal team is ready to act when a report arrives.

Publish the policy at a stable URL (/security or /vulnerability-disclosure). Add the URL to your security.txt. Include the security contact email in your website footer. Brief your engineering and legal teams on the process before the first report lands.

Researchers who find a welcoming, clearly defined disclosure process become long-term allies. Those who find silence or hostility become unpredictable risks. The policy is the difference.