Does this policy meet CRA Article 13 requirements?

This template is structured to address the key elements of CRA Article 13: a publicly accessible CVD policy, a single point of contact, 48-hour acknowledgment, and coordinated disclosure. You will need to customise it with your specific contact details and products. Consider using CVD Portal to automate the acknowledgment tracking and audit trail.

What triggers Article 14 notification to ENISA?

Article 14 is triggered when a vulnerability is actively exploited in the wild, or when you become aware of a severe security incident affecting your product. The thresholds are: 24 hours for an early warning, 72 hours for a full notification, and 14 days for a final report.

Do I need to publish CSAF advisories?

CSAF 2.0 advisory publication is not explicitly mandated by the CRA for all manufacturers, but it is referenced in Annex I as part of the expected security practices and is increasingly required by procurement frameworks. CVD Portal generates CSAF 2.0 advisories automatically.

Can I use this policy for all my products?

Yes, a single CVD policy can cover all your products. List all applicable products in the Scope section and maintain the policy as products are added or discontinued.

How often should I review this policy?

We recommend reviewing your CVD policy at least annually, and whenever you add a new product line, change your security contact, or there are updates to the CRA implementing acts.

← All templates

Free Template

CRA-Compliant CVD Policy Template

A comprehensive CVD policy structured specifically for the EU Cyber Resilience Act. Addresses Articles 13 and 14 obligations including 24-hour early warning, 72-hour full notification, and coordinated disclosure timelines.

Article 13 · Article 14 · Annex I

ForEU manufacturers of products with digital elements who need a CVD policy that demonstrably satisfies CRA obligations

CRA Articles

Article 13Article 14Annex I

Policy Statement

Article 13(1)

[COMPANY NAME] maintains a coordinated vulnerability disclosure (CVD) programme in compliance with the EU Cyber Resilience Act (Regulation (EU) 2024/2847) and ISO/IEC 29147.

This policy governs how we receive, assess, and respond to security vulnerability reports for all [COMPANY NAME] products with digital elements. It applies to security researchers, customers, partners, and any third party who discovers a potential security vulnerability in our products.

Note

Explicitly reference the CRA and ISO 29147. This signals to regulators, auditors, and researchers that your policy is grounded in recognised frameworks — not just a boilerplate page.

Scope

Article 13(4)

This policy covers all [COMPANY NAME] products with digital elements, including:

[PRODUCT NAME 1] (model [X], firmware [X.X] and later)
[PRODUCT NAME 2]
Associated cloud services and APIs at [DOMAIN]

Excluded from scope:

Products at end-of-life (see [SUPPORT LIFECYCLE URL])
Physical security vulnerabilities
Third-party services not under [COMPANY NAME] control
Vulnerabilities requiring physical access to the device

Note

Under the CRA, your policy must cover all products with digital elements you place on the EU market. Be comprehensive — an omission here could be evidence of non-compliance.

How to Report a Vulnerability

Article 13(1)

Report vulnerabilities to our security team via any of the following channels:

Preferred: Submit a report through our vulnerability disclosure portal: [PORTAL URL]

Email: [[email protected]] PGP encryption: Key fingerprint [FINGERPRINT], available at [KEY URL]

We accept reports in English. We treat all reports as confidential.

Do not report security vulnerabilities through public forums, support tickets, or social media.

Note

A single, clearly identified point of contact is an explicit CRA requirement (Article 13(1)). A dedicated portal creates an automatic audit trail — critical for demonstrating compliance.

What to Include in Your Report

Article 14

To help us triage your report efficiently, please include:

Affected product, model, and firmware/software version
CWE category if known (e.g. CWE-78 OS Command Injection)
CVSS score if you have assessed it (CVSS 3.1 or 4.0)
Description of the vulnerability and its potential impact
Step-by-step reproduction instructions
Proof of concept (code, video, or screenshots)
Whether the vulnerability is already publicly known or being exploited
Your contact information (optional)

Note

Asking for CVSS and CWE information helps with severity triage and populates CSAF advisories. Asking about active exploitation helps you prioritise Article 14 notification obligations.

Response Commitments

Article 13, Article 14

[COMPANY NAME] commits to the following response timeline:

| Milestone | Commitment | |-----------|------------| | Acknowledgment | Within 48 hours of receipt | | Initial severity assessment | Within [5] business days | | Status updates | At least every [30] days | | Patch or workaround | As soon as practicable | | Security advisory | Published upon or after patch release |

For vulnerabilities that meet the threshold for Article 14 notification (actively exploited or severe security incidents), [COMPANY NAME] will additionally notify ENISA within the timelines specified by the CRA (24-hour early warning, 72-hour full notification).

Note

Combining your researcher commitments with a reference to Article 14 obligations in the same section demonstrates an integrated approach to vulnerability management — exactly what regulators expect.

Article 14 Notification Obligations

Article 14

Where a reported vulnerability meets the threshold for mandatory reporting under Article 14 of the EU Cyber Resilience Act (i.e. the vulnerability is actively exploited, or constitutes a severe security incident), [COMPANY NAME] will:

Submit an early warning to ENISA within 24 hours of becoming aware
Submit a full notification to ENISA within 72 hours including severity assessment and initial remediation actions
Submit a final report within 14 days (or such period as agreed with ENISA) including root cause analysis and mitigation measures

This reporting is made to the ENISA Single Reporting Platform (SRP) or the relevant national CSIRT.

Note

Including this section in your public CVD policy serves as evidence that your organisation understands and has procedures for Article 14. It also informs researchers about what may happen when they report a critical vulnerability.

Safe Harbour

[COMPANY NAME] authorises security research conducted in good faith and in accordance with this policy. We will not pursue legal action against researchers who:

Follow this policy
Limit testing to what is strictly necessary to confirm the vulnerability
Avoid intentional service disruption or data access beyond proof of concept
Report to us before any public or third-party disclosure

We request that researchers contact us before publishing any vulnerability details.

Note

A safe harbour statement is essential for a functioning CVD programme. Without it, researchers may avoid reporting entirely — harming the security of your products.

Coordinated Disclosure and Advisory Publication

Annex I, Article 13

[COMPANY NAME] follows a coordinated disclosure model. We request [90] days from initial report to patch and publish before public disclosure.

Upon resolution, we will publish a security advisory in CSAF 2.0 format (OASIS Common Security Advisory Framework) at [CSAF ADVISORY URL]. Our advisories include:

CVE identifier (where assigned)
CVSS severity score
Affected products and versions
Remediation guidance
Acknowledgment of the reporter

Where a vulnerability affects upstream open-source or third-party components, we will coordinate disclosure with the relevant maintainers.

Note

CSAF 2.0 advisory publication is part of the CRA's expected practices under Annex I. Mentioning it here sets expectations with researchers and signals maturity to auditors.

Supply Chain Coordination

Article 13(4)

Where a reported vulnerability affects a component supplied by a third party, [COMPANY NAME] will:

Notify the upstream component manufacturer or maintainer within [X] business days of confirming the vulnerability
Coordinate disclosure timelines with upstream parties
Include upstream remediation status in our security advisory

If you are reporting a vulnerability that you believe originates in an upstream component, please include component name and version in your report.

Note

The CRA explicitly requires supply chain vulnerability coordination. Including this section demonstrates that your programme extends upstream — important for products with significant third-party component dependencies.

Use this template automatically in CVD Portal

CVD Portal generates your CVD policy, tracks acknowledgments, and creates an audit trail — free, forever.

Set up your free portal

Frequently asked questions

Ready to go beyond the template?

CVD Portal automates acknowledgments, tracks deadlines, and generates CSAF advisories — free.

Set up your free portal

Related templates

Basic CVD Policy Template

A straightforward coordinated vulnerability disclosure policy aligned with ISO/IEC 29147. Covers the core commitments expected by security researchers and satisfies CRA Article 13 requirements.

Article 14 Early Warning Notification Template

A structured notification template for the CRA Article 14 24-hour early warning obligation. Designed to be submitted to ENISA (or the relevant national CSIRT) when a manufacturer discovers an actively exploited vulnerability or severe security incident.

Security Incident Notification Policy Template

An internal security incident notification policy for manufacturers, covering escalation procedures, Article 14 regulatory notification, and user communication. Designed to sit alongside your CVD policy as an internal-facing document.

EU CVD Policy Template

A CVD policy template specifically written for EU manufacturers placing products on the European market. References EU-specific obligations (CRA, NIS2 intersection, ENISA), using terminology aligned with EU regulatory guidance.