The situation
A manufacturer has notified a severe incident and restored service. Its case file includes timing and mitigation, but the threat type or likely root cause has not been recorded. A recovery status should not hide that final-report gap.
Facts that change the answer
- What was the actual timestamp of the incident notification?
- What is known about threat type or likely root cause?
- Are severity, impact and applied or ongoing measures documented?
Compare the worked results
These examples use the published assessment with the assumptions shown below. Change the facts in your own assessment before relying on its result.
Threat type or likely root cause not recorded
Hypothetical example 1
Escalate the missed, uncertain, or incomplete Article 14 notification step immediately and preserve the actual submission timestamps.(CRA Article 14(4))
Key facts in this example
- The likely threat type or root cause that triggered the incident is recorded
- No
All recorded assumptions (19)
- Affected product with digital elements
- Hypothetical example product
- Reporting role
- manufacturer
- Timestamp when the organisation became aware of the incident
- 2026-09-11T09:00:00Z
- Effect on the product’s ability to protect sensitive or important data or functions
- negatively affected or capable of negative effect
- Introduction or execution of malicious code caused or enabled by the incident
- no malicious code effect or capability identified
- 24-hour early-warning status
- submitted within 24 hours
- The early warning records whether unlawful or malicious acts are suspected
- Yes
- The early warning identifies relevant Member States where the product is known to have been made available
- Yes
- 72-hour incident-notification status
- submitted within 72 hours
- Actual timestamp when the incident notification was submitted
- 2026-09-12T10:00:00Z
- The notification records available product information and the nature and initial assessment of the incident
- Yes
- Corrective or mitigating measures taken and measures users can take are recorded
- Yes
- The notification records how sensitive the submitted information is, where applicable
- Yes
- Final-report status within one month after the incident notification
- submitted within one month
- The final report gives a detailed incident description, including severity and impact
- Yes
- The likely threat type or root cause that triggered the incident is recorded
- No
- Applied and ongoing mitigation measures are recorded
- Yes
- Impacted users were informed without undue delay, including necessary risk-mitigation or corrective measures
- Yes
- Submission through the coordinating CSIRT endpoint, with simultaneous ENISA access, is confirmed
- Yes
Incident notification record complete
Hypothetical example 2
Key facts in this example
- The likely threat type or root cause that triggered the incident is recorded
- Yes
All recorded assumptions (19)
- Affected product with digital elements
- Hypothetical example product
- Reporting role
- manufacturer
- Timestamp when the organisation became aware of the incident
- 2026-09-11T09:00:00Z
- Effect on the product’s ability to protect sensitive or important data or functions
- negatively affected or capable of negative effect
- Introduction or execution of malicious code caused or enabled by the incident
- no malicious code effect or capability identified
- 24-hour early-warning status
- submitted within 24 hours
- The early warning records whether unlawful or malicious acts are suspected
- Yes
- The early warning identifies relevant Member States where the product is known to have been made available
- Yes
- 72-hour incident-notification status
- submitted within 72 hours
- Actual timestamp when the incident notification was submitted
- 2026-09-12T10:00:00Z
- The notification records available product information and the nature and initial assessment of the incident
- Yes
- Corrective or mitigating measures taken and measures users can take are recorded
- Yes
- The notification records how sensitive the submitted information is, where applicable
- Yes
- Final-report status within one month after the incident notification
- submitted within one month
- The final report gives a detailed incident description, including severity and impact
- Yes
- The likely threat type or root cause that triggered the incident is recorded
- Yes
- Applied and ongoing mitigation measures are recorded
- Yes
- Impacted users were informed without undue delay, including necessary risk-mitigation or corrective measures
- Yes
- Submission through the coordinating CSIRT endpoint, with simultaneous ENISA access, is confirmed
- Yes
Evaluated on 2026-09-13 using EU Cyber Resilience Act severe security incident notification record, version 2026.09.04. A completed example is not a customer Record or a declaration of conformity.
Evidence to keep
- Actual incident-notification receipt
- Investigation findings, including remaining uncertainty
- Mitigation record, final report and user communications
Keep source artifacts in their controlled systems and record their references, responsible owner and review date with the decision.
Your next step
Prepare the report from the actual notification date and the available investigation findings. Keep the severe-incident sequence separate from vulnerability final-report timing.
Choose your real product or vulnerability case in the workspace. The selected assessment will be highlighted; example answers are not copied into your record.
Sources and application dates
- Regulation (EU) 2024/2847 (Cyber Resilience Act)Articles 14(3)–(8), 24(3) and 71(2)
- European Commission CRA reporting obligationsSingle Reporting Platform, reporting scope and application date
Manufacturer reporting applies from 11 September 2026. Broader product requirements apply from 11 December 2027; these product-readiness examples support preparation. Open-source-steward obligations have their own application date.
These examples structure a decision and do not replace the Regulation, official guidance or product-specific professional advice. Not lawyer-reviewed.