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.
In this article
- Summary
- What the CRA Requires
- Essential Policy Components
- Complete CVD Policy Template
- Introduction
- Scope
- How to Report
- What to Include
- Our Commitments
- Coordinated Disclosure
- Safe Harbor
- Recognition
- Out of Scope
- Contact
- Implementation Checklist
- Handling Common Scenarios
- Integrating CVD with ENISA Reporting
- Common Mistakes
- CVD Policy Checklist
- How CRA Evidence Helps
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:
- Explain your standard timeline and the reason (thorough fix, testing)
- Offer compromise if possible (60 days with status updates)
- If researcher insists, escalate internally
- Document the disagreement and your good-faith efforts
- 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:
- Trigger ENISA reporting (24-hour requirement)
- Inform researcher of situation change
- Accelerate remediation
- Consider early coordinated disclosure
- 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
- Setting Up security.txt for CRA Compliance
- ENISA Vulnerability Reporting: The 24-Hour Requirement
- CRA Penalties and Enforcement Guide
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
Related Articles
Are Smart Cameras Important Products Under the EU Cyber...
Smart security cameras are classified as Important Products (Class I) under...
9 minEU Cybersecurity Act 2: Supply Chain Bans, Certification...
On January 20, 2026, the EU proposed replacing the Cybersecurity Act...
10 minCRA Product Classification: Is Your Product Default,...
A practical guide to determining your product's CRA category. Includes...
11 minDoes 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.