You've got 24 hours from awareness to initial report. That's not a planning window, it's an execution deadline. If you're selling products with digital elements in the EU, the Cyber Resilience Act's Article 14 reporting duties are now enforceable. Here's a template you can adapt for your internal notification workflow.
Purpose of This Template
This runbook helps you meet CRA Article 14 reporting deadlines when you discover an actively exploited vulnerability or severe incident affecting a product with digital elements sold in the EU. It covers the three mandatory reporting stages: early warning (24 hours), detailed notification (72 hours), and final report (14 days for vulnerabilities, one month for incidents).
The template assumes you're a manufacturer subject to CRA jurisdiction. If you're evaluating vendors under the CRA, use this to assess whether their incident response plans align with the regulation's timelines.
Prerequisites
Before executing this template, ensure you have:
- Component inventory ready: The 24-hour clock starts when you're aware of the issue, not when you finish mapping dependencies. If you're still building your Software Bill of Materials (SBOM) when an exploit hits, you're already late.
- CSIRT coordinator identified: EU manufacturers report to the CSIRT in their main establishment member state. Non-EU manufacturers follow separate coordination rules. Confirm your designated CSIRT beforehand.
- ENISA SRP access configured: All notifications go through ENISA's Single Reporting Platform. Set up credentials and test the submission process now.
- Notification authority assigned: Decide who can trigger this workflow. Legal review slows response time. Pre-authorize a technical lead to file the early warning if criteria are met.
The Template
Stage 1: Early Warning (24-Hour Deadline)
Trigger criteria: You're aware that a vulnerability in your product is being actively exploited, or a severe incident has occurred affecting product security.
Required actions:
Confirm scope (Hour 0-2)
- Identify affected product SKUs or versions.
- Check if related products sharing components are affected.
- Consult your SBOM. If a shared library is compromised, assume all products using it are in scope until proven otherwise.
Draft early warning (Hour 2-20)
- Product identifier and version
- Brief technical description of the vulnerability or incident
- Evidence of active exploitation or severity
- Preliminary impact assessment
- Intended next steps
Submit via ENISA SRP (Hour 20-24)
- Log into the Single Reporting Platform
- Address the notification to your coordinating CSIRT
- Retain submission confirmation and case reference number
Customization note: If your organization operates across multiple EU member states, clarify which legal entity is filing. The coordinating CSIRT is determined by the manufacturer's main establishment.
Stage 2: Detailed Notification (72-Hour Deadline)
Required content:
- Expanded technical analysis of the vulnerability or incident
- Affected product versions and component details (reference your SBOM)
- Attack vector and exploitation method, if known
- Current assessment of user impact
- Mitigation or correction status
- Timeline for delivering fixes or workarounds
Customization guidance: The 72-hour notification is an interim update, not a finalized root cause analysis. State what you know and what remains under review. Don't delay submission for complete certainty.
Stage 3: Final Report (14 Days for Vulnerabilities, One Month for Incidents)
For actively exploited vulnerabilities: Due 14 days after you make a corrective or mitigating measure available to users.
For severe incidents: Due one month after the initial early warning.
Required content:
- Root cause analysis
- Complete list of affected products and versions
- Description of the corrective measure or mitigation deployed
- User notification summary (confirm affected users were informed without undue delay)
- Lessons learned and process improvements
Customization note: The final report deadline is tied to remedy availability, not discovery date. If you release a patch on day 10, your final report is due on day 24. Track remedy release dates separately from discovery dates.
Customization Options
For products with limited digital elements: If your product includes minimal software (e.g., firmware in a hardware device), adjust the SBOM consultation step to focus on embedded components and update mechanisms. The reporting obligation still applies.
For multi-entity manufacturers: If your corporate structure includes separate legal entities manufacturing different product lines, assign a CSIRT coordinator and SRP access per entity. Don't centralize reporting through a single entity unless that entity is the actual manufacturer under CRA definitions.
For manufacturers outside the EU: Confirm your coordinating CSIRT under the CRA's non-EU manufacturer rules. The reporting obligation applies if you're making products available in the EU market.
For organizations subject to overlapping regulations: If you're also reporting under NIS2, DORA, or sector-specific incident notification rules, map the CRA workflow to your existing playbooks. Use the most restrictive timeline as your default.
Validation Steps
Before using this template in a live incident, validate it:
Conduct a tabletop exercise: Simulate an actively exploited vulnerability in a real product. Start the clock and execute each stage. Identify bottlenecks in your SBOM lookup, CSIRT coordination, or SRP submission process.
Confirm SBOM currency: Pull your SBOM for three representative products. Can you identify every third-party library, its version, and known vulnerabilities within two hours? If not, your SBOM maintenance process needs work.
Test SRP access: Log into the ENISA Single Reporting Platform with your credentials. Confirm you can initiate a draft notification. Don't wait until hour 23 of a real incident to discover authentication issues.
Review user notification channels: The CRA requires you to inform affected users of corrections or mitigations without undue delay. Confirm you have a distribution method (email list, in-app notification, public advisory) ready to execute.
The CRA's reporting duties carry penalties up to €15 million or 2.5% of annual turnover. Treat the 24-hour deadline as non-negotiable, not just because of the penalty, but because your users' security depends on it.
