Coordinated Vulnerability Disclosure Under CRA: Policy Template and Setup

A practical guide to establishing a CRA-compliant CVD policy. Includes ready-to-use templates, timeline guidance, and researcher communication frameworks.

CRA Evidence Team
Author
February 7, 2026
Updated February 25, 2026, 12:00:00 AM UTC
12 min read
Coordinated Vulnerability Disclosure Under CRA: Policy Template and Setup
In this article

The CRA requires manufacturers to implement coordinated vulnerability disclosure. This isn't optional; it's a legal obligation. Yet many organizations have no CVD policy or have one that fails to meet regulatory expectations.

This guide provides everything you need: policy templates, researcher communication frameworks, and timeline guidance.

Summary

  • CRA mandates a "policy on coordinated vulnerability disclosure" (Annex I, Part II)
  • Your policy must include: contact method, expected response times, disclosure timeline, legal safe harbor
  • Publish your policy at a discoverable location (security.txt, /security page)
  • 90-day disclosure timeline is industry standard, but be prepared to negotiate
  • Treat researchers as partners, not adversaries

What the CRA Requires

Annex I, Part II of the CRA requires manufacturers to:

"put in place and enforce a policy on coordinated vulnerability disclosure"

This means:

  • Having a policy: Written, published, accessible
  • Implementing it: Actually following the policy when reports arrive
  • Enforcing it: Consistent application across all products

The CRA doesn't specify exact policy contents, but industry standards and regulatory expectations are clear.

Essential Policy Components

Your CVD policy must address these elements:

1. Scope

Which products and services are covered?

SCOPE EXAMPLE:
This policy applies to:
- All [Company Name] products with digital elements
- Associated firmware and software
- Web applications at *.company.com
- Mobile applications published by [Company Name]

This policy does NOT apply to:
- Third-party products sold but not manufactured by us
- Services provided by partners under their own policies

2. Contact Methods

How can researchers reach you?

Required channels:

  • Email address (security@company.com)
  • Web form (preferred, with structured intake)
  • security.txt file pointing to contact methods

Optional enhancements:

  • PGP key for encrypted reports
  • Bug bounty platform integration
  • Dedicated researcher portal

3. Response Commitments

What can researchers expect?

Stage Commitment
Acknowledgment Within 3 business days
Initial assessment Within 10 business days
Status updates Every 14 days minimum
Resolution target Within 90 days

4. Disclosure Timeline

When can researchers publish?

Industry standard: 90 days from report to public disclosure

Your policy should specify:

  • Standard disclosure window (e.g., 90 days)
  • Extension conditions (complex fixes, coordinated multi-vendor)
  • Early disclosure conditions (active exploitation, vendor unresponsive)
  • Researcher's right to disclose if you fail to respond

5. Legal Safe Harbor

Protecting good-faith researchers from legal action.

SAFE HARBOR EXAMPLE:
[Company Name] will not pursue legal action against researchers who:
- Make good-faith efforts to comply with this policy
- Avoid privacy violations, data destruction, and service disruption
- Do not exploit vulnerabilities beyond necessary demonstration
- Report findings promptly and allow reasonable remediation time
- Do not publicly disclose before coordinated timeline

This safe harbor covers activities that might otherwise violate:
- Computer fraud and abuse laws
- Data protection regulations
- Terms of service provisions

6. Recognition and Rewards

How you acknowledge researchers.

Options:

  • Public acknowledgment (Hall of Fame)
  • Private thank-you
  • Bug bounty payments
  • Swag/merchandise
  • Reference letters

7. Out-of-Scope Items

What you don't want reported (or handle differently).

OUT OF SCOPE:
- Social engineering attacks against employees
- Physical security issues
- Denial of service testing
- Spam or phishing reports
- Issues in third-party services we don't control
- Previously reported vulnerabilities

Complete CVD Policy Template

Use this template as a starting point. Customize for your organization.

# [Company Name] Vulnerability Disclosure Policy

## Introduction

[Company Name] is committed to the security of our products and the safety
of our customers. We value the security research community and welcome
responsible disclosure of vulnerabilities.

## Scope

This policy applies to:
- All products manufactured by [Company Name]
- Software and firmware in our products
- Web properties at *.company.com
- Mobile applications published by [Company Name]

## How to Report

**Preferred Method:** Submit via our secure form at:
https://company.com/security/report

**Alternative:** Email security@company.com
- PGP Key: [Key ID or link to key]

**Reference:** Our security.txt file is at:
https://company.com/.well-known/security.txt

## What to Include

Please provide:
- Affected product(s) and version(s)
- Description of the vulnerability
- Steps to reproduce
- Potential impact assessment
- Your suggested remediation (optional)
- Your contact information for follow-up

## Our Commitments

| Timeline | Action |
|----------|--------|
| 3 business days | Acknowledgment of your report |
| 10 business days | Initial assessment and severity rating |
| Every 14 days | Status update until resolution |
| 90 days | Target resolution for most vulnerabilities |

We may request extensions for complex vulnerabilities requiring
coordinated fixes across multiple products or vendors.

## Coordinated Disclosure

We follow a 90-day disclosure timeline:
- Day 0: You report the vulnerability
- Days 1-90: We work on remediation
- Day 90: Coordinated public disclosure

**Extensions:** We may request up to 30 additional days for:
- Complex multi-component fixes
- Hardware vulnerabilities requiring supply chain coordination
- Multi-vendor coordination

**Early Disclosure:** You may disclose earlier if:
- We fail to respond within 14 days
- We indicate no intention to fix
- The vulnerability is being actively exploited

## Safe Harbor

We will not pursue legal action against researchers who:
- Act in good faith and comply with this policy
- Avoid accessing, modifying, or deleting user data
- Do not disrupt our services or harm our customers
- Report vulnerabilities promptly
- Allow reasonable time for remediation before disclosure

This safe harbor applies to potential violations of:
- Computer misuse laws
- Our terms of service
- Data protection requirements (for incidental access during research)

## Recognition

We maintain a Security Hall of Fame at company.com/security/thanks
recognizing researchers who have helped improve our security.

We do not currently operate a paid bug bounty program.
[OR: We offer bounties through [platform]. See [link] for details.]

## Out of Scope

The following are out of scope for this policy:
- Social engineering of employees or customers
- Physical attacks on our facilities
- Denial of service attacks
- Findings from automated scanners without demonstrated impact
- Issues in third-party services
- Previously reported vulnerabilities

## Contact

Security Team: security@company.com
Policy Questions: security-policy@company.com
PGP Key: [link]

Last Updated: [Date]

Implementation Checklist

Infrastructure Setup

CVD INFRASTRUCTURE CHECKLIST

CONTACT CHANNELS:
[ ] security@company.com configured and monitored
[ ] Web form created with required fields
[ ] PGP key generated and published
[ ] security.txt file deployed (see separate guide)
[ ] /security or /security/report page created

INTERNAL PROCESS:
[ ] Triage team identified
[ ] Escalation path defined
[ ] SLA tracking system in place
[ ] Template responses prepared
[ ] Disclosure coordination process documented

DOCUMENTATION:
[ ] CVD policy written and approved
[ ] Policy published on website
[ ] Internal handling procedures documented
[ ] Researcher communication templates ready
[ ] Hall of Fame page created (optional)

TESTING:
[ ] Test report submitted internally
[ ] Response time tracking verified
[ ] Escalation process tested
[ ] Disclosure coordination tested

Researcher Communication Templates

Acknowledgment (Day 0-3):

Subject: [Ticket #] - Vulnerability Report Received

Dear [Researcher],

Thank you for reporting a potential security vulnerability in
[Product Name]. We have received your report and assigned it
tracking number [Ticket #].

Our security team will review your submission and provide an
initial assessment within 10 business days.

Please reference [Ticket #] in future correspondence.

Questions? Reply to this email or contact security@company.com.

Best regards,
[Company Name] Security Team

Initial Assessment (Day 10):

Subject: [Ticket #] - Initial Assessment Complete

Dear [Researcher],

We have completed our initial assessment of your reported
vulnerability in [Product Name].

Assessment Summary:
- Severity: [Critical/High/Medium/Low]
- Status: [Confirmed/Under Investigation/Unable to Reproduce]
- Affected Versions: [List]
- Target Resolution: [Date, typically within 90 days]

Next Steps:
[Description of planned remediation approach]

We will provide status updates every 14 days. Current disclosure
target date: [Date].

Thank you for helping improve our security.

Best regards,
[Company Name] Security Team

Resolution Notification:

Subject: [Ticket #] - Vulnerability Resolved

Dear [Researcher],

We have resolved the vulnerability you reported in [Product Name].

Resolution Details:
- Fix Version: [Version number]
- Release Date: [Date]
- CVE ID: [If assigned]

Coordinated Disclosure:
We plan to publish a security advisory on [Date].

Would you like to be credited in our advisory?
[ ] Yes, credit me as: [Name/Handle]
[ ] Yes, credit me anonymously
[ ] No credit needed

Thank you for your responsible disclosure. Your contribution
has been added to our Security Hall of Fame at [URL].

Best regards,
[Company Name] Security Team

Handling Common Scenarios

Scenario 1: Researcher Demands Immediate Disclosure

Situation: Researcher insists on 30-day timeline instead of 90 days.

Response:

  1. Explain your standard timeline and the reason (thorough fix, testing)
  2. Offer compromise if possible (60 days with status updates)
  3. If researcher insists, escalate internally
  4. Document the disagreement and your good-faith efforts
  5. Prioritize the fix because you may need to accelerate

Scenario 2: Duplicate Report

Situation: Vulnerability already known or previously reported.

Response:

Subject: [Ticket #] - Duplicate Report

Dear [Researcher],

Thank you for your report regarding [vulnerability type] in
[Product Name].

This issue was previously reported and is currently being
addressed. Original ticket: [Reference].

Expected resolution: [Date]

While we cannot offer recognition for duplicate reports, we
appreciate your attention to our security.

Best regards,
[Company Name] Security Team

Scenario 3: Out-of-Scope Report

Situation: Report covers something not in your CVD scope.

Response:

Subject: [Ticket #] - Out of Scope

Dear [Researcher],

Thank you for your report. After review, we've determined this
issue falls outside our vulnerability disclosure policy scope.

Reason: [e.g., "Third-party service not controlled by us"]

If you believe this assessment is incorrect, please reply with
additional context.

For issues with [third-party], please contact them at [contact].

Best regards,
[Company Name] Security Team

Scenario 4: Active Exploitation Discovered

Situation: During investigation, you discover the vulnerability is being exploited.

Response:

  1. Trigger ENISA reporting (24-hour requirement)
  2. Inform researcher of situation change
  3. Accelerate remediation
  4. Consider early coordinated disclosure
  5. Prepare customer notification
Subject: [Ticket #] - Urgent Update

Dear [Researcher],

We have discovered active exploitation of the vulnerability you
reported. We are:

1. Accelerating our remediation timeline
2. Notifying relevant authorities as required
3. Preparing customer communication

We need to coordinate disclosure urgently. Please contact us at
[phone/secure channel] to discuss timeline.

DO NOT publicly disclose at this time. Doing so could increase
harm to users before patches are available.

Urgent contact: [Phone/Signal]

[Company Name] Security Team

Integrating CVD with ENISA Reporting

Your CVD process must connect to your ENISA reporting obligation:

RESEARCHER REPORT ARRIVES
         │
         ▼
    TRIAGE & ASSESS
         │
         ├── No active exploitation ──→ Standard CVD process
         │                              (90-day timeline)
         │
         └── Active exploitation ──→ TRIGGER ENISA REPORTING
              detected                    │
                                         ▼
                                   24h Early Warning
                                         │
                                         ▼
                                   72h Detailed Report
                                         │
                                         ▼
                                   Accelerated CVD
                                   (coordinate with ENISA)

Common Mistakes

No Published Policy

Problem: Policy exists internally but isn't public.

Fix: Publish at a discoverable URL. Researchers can't follow a policy they can't find.

Unrealistic Timelines

Problem: Promising 7-day response when you can't deliver.

Fix: Set achievable commitments. Under-promise, over-deliver.

Missing Safe Harbor

Problem: No legal protection for researchers.

Fix: Add explicit safe harbor language. Without it, researchers may not report to you.

Treating Researchers as Threats

Problem: Legal threats, aggressive responses, ignoring reports.

Fix: Researchers are helping you. Treat them as partners.

No Internal Process

Problem: Policy published but no one knows how to handle reports.

Fix: Document internal procedures. Train the team. Test with simulations.

CVD Policy Checklist

CVD POLICY COMPLETENESS CHECKLIST

SCOPE:
[ ] Products covered are listed
[ ] Out-of-scope items defined
[ ] Geographic scope clear (if relevant)

CONTACT:
[ ] Email address provided
[ ] Web form available
[ ] PGP key published
[ ] security.txt deployed
[ ] Response channels monitored

TIMELINE:
[ ] Acknowledgment timeline stated
[ ] Assessment timeline stated
[ ] Resolution target stated
[ ] Disclosure timeline stated
[ ] Extension conditions defined

LEGAL:
[ ] Safe harbor statement included
[ ] Covered activities defined
[ ] Good faith requirements stated

RECOGNITION:
[ ] Credit process explained
[ ] Hall of Fame (if applicable)
[ ] Bounty program (if applicable)

PROCESS:
[ ] Internal triage documented
[ ] Escalation path defined
[ ] Template responses ready
[ ] ENISA integration planned

Important: A Coordinated Vulnerability Disclosure (CVD) policy is mandatory under the CRA. You must publish it and make it easily accessible (ideally via security.txt).

Tip: Commit to specific response timelines in your CVD policy: acknowledge within 3 days, initial assessment within 10 days, resolution target within 90 days.

Related Guides

How CRA Evidence Helps

CRA Evidence includes CVD workflow support:

  • Report intake tracking: Log and track researcher reports
  • Timeline management: Automatic SLA tracking
  • ENISA integration: Trigger reporting when exploitation detected
  • Documentation: Audit trail for regulatory compliance

Establish your CVD process with app.craevidence.com.


This article is for informational purposes only and does not constitute legal advice. For specific compliance guidance, consult with qualified legal counsel.

Topics covered in this article

Share this article

Related Articles

Does the CRA apply to your product?

Answer 6 simple questions to find out if your product falls under the EU Cyber Resilience Act scope. Get your result in under 2 minutes.

Ready to achieve CRA compliance?

Start managing your SBOMs and compliance documentation with CRA Evidence.