NIS2 Art.23.4d: Final Incident Report (One Month)
What This Control Requires
For the purposes of the notification under paragraph 1, the entities concerned shall submit to the CSIRT or the competent authority: (d) a final report not later than one month after the submission of the incident notification under point (b), including: a detailed description of the incident, its severity and impact; the type of threat or root cause that is likely to have triggered the incident; applied and ongoing mitigation measures; and the cross-border impact of the incident, where applicable.
In Plain Language
One month after your 72-hour notification, you must submit a comprehensive final report covering the full story of the incident. This is not a formality - it is your opportunity to demonstrate that you understand what happened, why it happened, and what you are doing to prevent it from happening again. The report must include a detailed incident description with timeline, a thorough severity and impact assessment, identification of the threat type or root cause, a complete account of all mitigation measures (during and after the incident), and any cross-border impact. This requires significantly deeper analysis than the earlier notifications. Root cause analysis is the most important element. It shows that you have gone beyond firefighting to understand the underlying weaknesses. Without it, you risk repeating the same incident - and regulators will rightly question whether your risk management measures are effective.
How to Implement
Create a final report template that covers every required element: executive summary with key findings, complete incident timeline from initial compromise to full resolution, detailed technical description of the attack vector and affected systems, root cause analysis identifying the underlying vulnerability or systemic weakness, severity and impact assessment across operational, financial, data, and reputational dimensions, all mitigation and remediation measures applied, cross-border impact where applicable, lessons learned and improvement recommendations, and status of any ongoing remediation. Run a post-incident review (PIR) soon after containment - ideally within one to two weeks while everything is still fresh. Bring in incident responders, affected business units, IT operations, management, and legal. Conduct a structured root cause analysis using methods like the "5 Whys," fishbone diagrams, or fault tree analysis. Go beyond the technical cause to identify the systemic factors - process gaps, training deficiencies, resource constraints - that allowed the incident to happen. Include quantitative impact data wherever possible: service disruption duration, number of affected users or records, estimated financial impact, and recovery costs. Hard numbers strengthen your impact assessment and inform future risk decisions. Make the report forward-looking. For every identified weakness or gap, define specific corrective actions with assigned owners, target completion dates, and verification criteria. These are commitments you will need to deliver on. Submit within the one-month deadline. If the investigation is still running, submit a progress report and clearly state when the final version will follow. The CSIRT may request additional detail or follow-up reports. Archive all incident reports and supporting evidence. You will need them for regulatory audits, trend analysis, and demonstrating continuous improvement.
Evidence Your Auditor Will Request
- Final incident report template covering all Art.23.4(d) requirements
- Completed final reports for all significant incidents within the past year
- Post-incident review records and root cause analysis documentation
- Remediation action plans with owners, deadlines, and completion status
- Evidence of timely submission within the one-month deadline
Common Mistakes
- Final reports are superficial and lack meaningful root cause analysis
- Reports submitted late, well beyond the one-month deadline
- Remediation recommendations documented but never implemented or tracked
- Impact assessment is qualitative only, without quantitative data to support conclusions
- No post-incident review conducted; final report is based solely on incident response notes
Related Controls Across Frameworks
Frequently Asked Questions
What if the investigation is not complete within one month?
How detailed should the root cause analysis be?
Track NIS2 compliance in one place
AuditFront helps you manage every NIS2 control, collect evidence, and stay audit-ready.
Start Free Assessment