The severe-incident final-report clock differs from the vulnerability final-report clock. It runs from submission of the 72-hour incident notification, not from awareness and not from availability of a security update. The one-month period should therefore be tracked separately in the Article 14 case.
The One-Month Clock Starts From the Incident Notification
Article 14(4)(c) gives the severe-incident final report its own deadline. The manufacturer must submit the final report within one month after submission of the incident notification required by Article 14(4)(b). This is different from the 24-hour and 72-hour periods, which are measured from manufacturer awareness. It is also different from the actively exploited vulnerability final report, which is connected to the availability of a corrective or mitigating measure. A reporting tracker should therefore preserve the actual 72-hour incident-notification submission time and calculate the one-month final-report deadline from that event.
- 24-hour early warning: measured from awareness.
- 72-hour incident notification: measured from awareness.
- Severe-incident final report: measured from submission of the incident notification.
- Do not reuse the vulnerability 14-day rule for severe incidents.
The Final Report Needs a Detailed Incident Description
The 72-hour incident notification provides general information and an initial assessment. The final report moves beyond that preliminary stage. Article 14 requires a detailed description of the incident, including its severity and impact. The manufacturer should therefore consolidate the developed technical findings, affected products and versions, relevant security properties, attack or failure path, confirmed scope and consequences. The description should be specific enough to explain what occurred while remaining consistent with the evidence preserved through the incident-response process. Changes from the initial assessment should be reflected rather than silently carried forward from earlier submissions.
- Describe what happened in detail.
- Identify affected products and versions.
- State the severity.
- Explain the impact.
- Update material facts that changed after the 72-hour notification.
Report the Threat or Likely Root Cause
Article 14(4)(c) requires the final report to include the type of threat or root cause that is likely to have triggered the incident. The wording recognises that cybersecurity investigations can involve uncertainty. A manufacturer should provide the best supported conclusion produced by the investigation and distinguish a likely cause from a conclusively demonstrated cause where appropriate. Relevant information can include the attack mechanism, compromised interface, configuration weakness, credential compromise, malicious software, supply-chain mechanism or other technical cause that explains the event. The regulatory description should remain tied to evidence rather than unsupported attribution.
- Identify the likely triggering threat or root cause.
- Distinguish supported findings from unresolved hypotheses.
- Connect the conclusion to investigation evidence.
- Avoid overstating certainty.
Include Applied and Ongoing Mitigation Measures
The severe-incident final report also needs applied and ongoing mitigation measures. Applied measures are actions already taken to contain, reduce or correct the security impact. Ongoing measures are actions still being implemented or monitored when the final report is prepared. Depending on the event, these can include product configuration changes, credential resets, service-side controls, component replacement, security updates, disabling an affected feature, monitoring changes or other containment and recovery actions. The regulatory record should explain what each measure addresses and which affected products or environments it covers.
- List mitigation measures already applied.
- Identify mitigation work still in progress.
- Connect each measure to the affected product or incident condition.
- Keep mitigation status current through final submission.
The Final Report Is More Developed Than the Initial Assessment
The 72-hour incident notification asks for an initial assessment because the investigation may still be in its early stages. The final report is expected to contain a detailed description, severity and impact information, the likely threat or root cause and mitigation measures. This progression means the manufacturer should actively maintain the regulatory case during the one-month period. New findings should be incorporated into the final report, and earlier statements that turned out to be incomplete or inaccurate should be corrected. The reporting sequence is intended to mature as the incident investigation matures.
- Treat the 72-hour assessment as an initial regulatory picture.
- Maintain the incident record during the one-month period.
- Incorporate developed severity and impact findings.
- Incorporate likely threat or root-cause findings.
- Reflect changes in mitigation status.
The CSIRT Can Request an Intermediate Status Report
The one-month final-report period does not prevent the CSIRT designated as coordinator from requesting information sooner. Article 14(6) allows the CSIRT that initially receives the notification to request an intermediate report on relevant status updates where necessary. Incident-response and regulatory teams should therefore maintain a current case record rather than waiting until the final-report deadline to consolidate the evidence. The ability to provide a prompt intermediate update is particularly important when incident scope, mitigation or customer impact changes materially during the investigation.
- Maintain a live regulatory case after the 72-hour notification.
- Track investigation changes.
- Track mitigation changes.
- Be prepared to provide a requested intermediate report.
Build the Final Report Alongside the Incident Investigation
A useful severe-incident final-report record can include the affected products and versions, awareness timestamp, early-warning submission, 72-hour submission time, incident chronology, severity, impact, evidence, likely threat or root cause, applied mitigation, ongoing mitigation, affected-user communication and final-report deadline. The incident-response team should not need to stop its technical work to recreate this information at the end of the month. Maintaining the regulatory fields alongside the technical incident record makes the final report a controlled continuation of the investigation rather than a separate compliance exercise.
- Record the exact 72-hour incident-notification submission time.
- Calculate the one-month deadline immediately.
- Maintain the detailed incident chronology.
- Maintain severity and impact findings.
- Maintain root-cause and threat analysis.
- Maintain applied and ongoing mitigation status.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.