NIS2 Art.23.4b: Incident Notification (72 Hours)
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: (b) without undue delay and in any event within 72 hours of becoming aware of the significant incident, an incident notification, which, where applicable, shall update the information referred to in point (a) and indicate an initial assessment of the significant incident, including its severity and impact, as well as, where available, the indicators of compromise.
In Plain Language
Within 72 hours of becoming aware of a significant incident, you must submit a fuller notification that goes well beyond the initial early warning. This second report should include an initial assessment of severity and impact, plus any indicators of compromise (IoCs) you have identified so far. The purpose is to give your CSIRT a clearer picture of what happened, how bad it is, and what to look for. Your assessment should cover the types of systems and data affected, the estimated number of impacted users or services, the known or suspected attack vector, and any IoCs such as malicious IPs, file hashes, or domain names. Sharing IoCs is particularly valuable for collective defence - they let other entities check their own environments for signs of similar compromise. The directive uses "where available" to acknowledge that you may not have everything at 72 hours, but you should make a genuine effort to collect and share what you can.
How to Implement
Build a structured notification template covering all required elements: an updated incident description building on the early warning, initial severity assessment on a defined scale, impact assessment (affected systems, data, services, users), suspected or confirmed attack vector, indicators of compromise (IPs, domains, file hashes, email addresses), mitigation measures already taken, and an expected timeline for further updates. Set up internal processes for gathering the information quickly. This means forensic triage procedures for identifying IoCs, impact assessment frameworks for estimating scope and severity, coordination procedures between your IR team and business stakeholders for assessing business impact, and a clear handoff to the designated reporter. Create a severity assessment matrix tailored to your organisation. Factor in service disruption scope and duration, data compromise type and volume, financial impact, regulatory implications, and cross-border or cascading effects. A consistent matrix gives you defensible severity ratings rather than subjective guesswork. Make sure your tooling supports rapid IoC extraction. SIEM, EDR, and forensic tools should be configured to facilitate identification and export of relevant indicators during an incident. Add a review step before submission. A designated reviewer should check for completeness, accuracy, and appropriate handling of sensitive information - for instance, avoiding disclosure of details that could compromise an ongoing investigation. Track every reporting milestone (awareness, early warning, 72-hour notification, final report) with timestamps. This log demonstrates compliance with all deadlines.
Evidence Your Auditor Will Request
- 72-hour incident notification template with all required data fields
- Severity and impact assessment matrix
- Records of actual 72-hour notifications submitted with timestamps
- IoC collection and sharing procedures
- Notification timeline tracker showing compliance with deadlines
Common Mistakes
- 72-hour notification contains no additional information beyond the early warning
- IoCs are identified but not included in the notification or shared too late
- Severity assessment is subjective and inconsistent across incidents
- Internal coordination delays prevent timely collection of impact information
- Notifications lack sufficient detail for the CSIRT to provide meaningful support
Related Controls Across Frameworks
Frequently Asked Questions
What if our investigation is still ongoing at 72 hours?
Must we share IoCs that could reveal our internal infrastructure?
Track NIS2 compliance in one place
AuditFront helps you manage every NIS2 control, collect evidence, and stay audit-ready.
Start Free Assessment