NIS2 72-Hour Incident Notification: Article 23(4)(b) Requires Three Things, Not Ten — and 5 Mistakes That Add a Separate Violation
The SANS 2025 State of ICS Security Report, drawn from more than 330 ICS security professionals across energy, manufacturing, water and transport, found that 49% of incidents were detected within 24 hours and nearly one in five required more than a month to remediate. Those figures cover industrial environments specifically, but the shape they describe holds far more widely: at hour 72 of a real incident, most entities still do not know what happened, who did it, or how far it went.
The NIS2 Directive anticipated this. Recital 102 — interpretive rather than binding — says Member States should ensure that the obligation to submit the early warning or the incident notification "does not divert the notifying entity’s resources from activities related to incident handling that should be prioritised". The 72-hour notification was drafted to be thin. Most compliance guides treat it as a full report, and that misreading is where the trouble starts.
What Article 23(4)(b) Actually Requires
In plain language: the 72-hour notification updates what you already told the authority, gives your first real assessment of how bad it is, and hands over any attacker fingerprints you happen to have. That is the whole obligation. Verbatim, Article 23(4)(b) of Directive (EU) 2022/2555 requires entities to submit:
"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"
Free DownloadGet the NIS2 Article 21 Compliance Checklist
90+ assessment items mapped to CIR 2024/2690 — instant PDF, no payment.
Three elements. And the qualifiers matter more than the elements, because two of the three are conditional on something you may not have.
| Element | Qualifier in the text | What it means in practice |
|---|---|---|
| Update the early-warning information | "where applicable" | If nothing material has changed since hour 24, say so. There is no duty to manufacture an update. |
| An initial assessment, including severity and impact | None — unconditional | The only element you cannot omit. "Initial" is the operative word: the Directive is asking for your current best judgement, not a finding. |
| Indicators of compromise | "where available" | Send what forensics has produced by hour 72. If nothing has been produced, that is a complete answer. |
Now look at what is not in that list. Root cause, mitigation measures and confirmed cross-border impact are the contents of the final report under Article 23(4)(d), due one month after the 72-hour notification is submitted: "the type of threat or root cause that is likely to have triggered the incident", "applied and ongoing mitigation measures", and cross-border impact where applicable.
All four appear in mainstream 72-hour checklists. One widely-shared Article 23 playbook lists eleven items for this stage, including preliminary root cause and containment actions. None of that is wrong to send. It is wrong to wait for.
The Clock Gives You 48 Hours, Not 72
Both deadlines in Article 23(4) run from the same instant. Point (a) sets the early warning at 24 hours "of becoming aware of the significant incident"; point (b) sets the notification at 72 hours of the same moment. The 72-hour deadline is not 72 hours after you file the early warning. If you use the full 24 hours for the first filing, you have 48 hours of working time left for the second — and those 48 hours run through nights and weekends.
The first filing has its own, much narrower content rule — see our guide to the NIS2 24-hour early warning, where only two indications are named and both are qualified. Which raises when the clock starts at all. The Centre for Cybersecurity Belgium (CCB) sets the test in its NIS2 Notification Guide v1.2: an entity becomes aware "when, after such initial assessment, that entity has a reasonable degree of certainty that a significant incident has occurred". Germany’s BSI defines the same trigger — Kenntniserlangung — more aggressively: the moment any employee, during working hours, learns of a significant incident. Not the moment the SOC confirms it. Our guide to what counts as a significant incident covers the classification test upstream of both.
Neither deadline is a target. The CCB is explicit that "only duly justified special circumstances may lead to waiting until the very end of these deadlines". The BSI says the same in one line: the deadlines are maxima that should not be exhausted.
Two consequences most guides omit. First, trust service providers do not get 72 hours at all: a derogation at the end of Article 23(4) requires them to notify within 24 hours of becoming aware, for significant incidents affecting their trust services. The second stage collapses into the first. Second, the one-month final-report clock runs "after the submission of the incident notification under point (b)", not from the incident — file at hour 30 and you have shortened your own final-report window by 42 hours.
How to Write It While the Investigation Is Still Open
The word carrying the weight in Article 23(4)(b) is initial. The Directive is not asking what happened; it is asking what you currently believe on the evidence you have at hour 72. Recital 101 describes what that assessment should weigh: the affected systems and their importance to the service, the severity and technical characteristics of the threat, any vulnerabilities being exploited, and the entity’s own experience with similar incidents.
The method that follows is to label the confidence level of every statement you file, rather than filing only what you can prove. Three tiers are enough:
| Tier | Use for | Phrasing that signals it |
|---|---|---|
| Established | Facts confirmed by your own logs, monitoring or direct observation | "Confirmed: 14 file servers encrypted, first write at 02:41 CEST." |
| Assessed | Your current working judgement on incomplete evidence — this is where severity and impact belong | "Assessed as high severity; approximately 40% of order processing unavailable. Estimate based on partial telemetry." |
| Under investigation | Questions you have opened but not answered — including root cause | "Initial access vector under investigation; no attribution at this time." |
Three things make this the right format rather than a hedge. The BSI’s guidance is that speed comes before completeness — Schnelligkeit vor Vollständigkeit — and that time lost gathering information to fill a form completely is to be avoided. A submitted notification can never afterwards be cancelled or withdrawn, but an inaccurate or incomplete one can be corrected or supplemented by a follow-up report. And the CCB’s form applies a three-level depth ladder to the same severity field: brief or partial at the early warning, an initial assessment at 72 hours, detailed at the final report. Labelled uncertainty also protects you when your hour-72 assessment turns out to have been wrong.
There is also a physical constraint nobody writes about. On Belgium’s notification form, the incident description, severity, consequences and cause fields are each capped at 500 characters. You are not drafting a report. You are drafting four short paragraphs, and the confidence labels have to fit inside them.
Two provisions should remove the temptation to say less than you know. Article 23(1) states that "the mere act of notification shall not subject the notifying entity to increased liability", and Article 23(6) requires the receiving authority to preserve the entity’s security and commercial interests and the confidentiality of what was provided. Filing an honest, hedged assessment is the smaller risk.
The Content List Changes at the Border
Article 23(11) shows how much room a directive leaves. Its first subparagraph says the Commission may adopt implementing acts "further specifying the type of information, the format and the procedure of a notification". Permissive, and never exercised. The one implementing regulation that did arrive, CIR (EU) 2024/2690, states in its own Article 1 that it lays down the technical and methodological requirements for the Article 21(2) measures and specifies when an incident is significant under Article 23(3) — for eleven named categories of entity. It says nothing about notification content or format.
So there is no European 72-hour form, and national authorities have filled the gap differently.
| Source | Required at 72 hours | Delta vs the Directive |
|---|---|---|
| Directive (EU) 2022/2555, Art. 23(4)(b) | Update to the early warning (where applicable); initial assessment incl. severity and impact; IoCs (where available) | Baseline — 3 elements |
| Belgium — CCB NIS2 Notification Guide v1.2 | The same three, reproduced almost word for word, with the same "should not divert the entity’s resources" caveat | None |
| Germany — BSI, Folgemeldung | Detailed update to the early warning; detailed information on the cause; information on law enforcement action and cooperation with authorities; mitigation measures taken and planned; severity and impact; IoCs for exploited vulnerabilities where applicable | Three additional items — 6 in total |
Germany’s law-enforcement question is the one to plan for: by day three, a German entity is telling the authority whether it has gone to the police — a suspicion-level call made long before forensics or HR conclude anything. Cause detail and planned mitigation pull final-report material forward by four weeks.
If you operate in one Member State, build your internal 72-hour template from your own authority’s form and its field limits, not from the Directive. The Directive is the floor; your form is the deliverable. If you operate in several, build one template to the union of the national lists and file the local subset. Our directory of CSIRT portals and required fields across eight EU countries sets out where each filing goes.
Five Mistakes That Add a Separate Violation
1. Waiting for root cause before filing. Root cause is a final-report field, due a month later, and even there it is only the cause "likely to have triggered" the incident. Holding the notification until forensics concludes converts a solvable drafting task into a missed deadline.
2. Starting the 72-hour clock at the early warning. Both run from awareness. Teams that read the cascade as 24 + 72 give themselves four days they do not have.
3. Sitting on the early warning until hour 23 to buy time. It buys nothing — the 72-hour deadline does not move — and it costs something real. Article 23(5) requires the CSIRT or competent authority to respond, where possible within 24 hours of receiving the early warning, with initial feedback and, on request, operational advice on mitigation. A late early warning shortens the window in which that help can arrive.
4. Withholding indicators of compromise until they are validated. The text says "where available", not "where confirmed". A partial list of hashes and domains, labelled unvalidated, is worth more to a CSIRT correlating incidents across a sector than a clean list a month later — and a filed report can always be supplemented. The same logic runs through our guide to ransomware reporting obligations, where encryption is confirmed long before attribution.
5. Assuming an outsourced filing transfers the duty. The BSI confirms an organisation may authorise a service provider to submit notifications on its behalf — and that responsibility for the incident and for the content of the notification stays with the entity regardless. If your MSSP drafts the assessment, someone inside the entity still owns it. We cover the split in who must notify the CSIRT when your SOC detects a client incident.
On exposure, be precise about Article 34, because almost everyone paraphrases it backwards. For infringements of Article 21 or 23, Member States must provide for administrative fines of "a maximum of at least" EUR 10,000,000 or 2% of total worldwide annual turnover for essential entities, whichever is higher, and EUR 7,000,000 or 1.4% for important entities. That is a floor the national ceiling must clear, not a cap. And because Article 23 is named alongside Article 21, a reporting failure carries the same exposure as a risk-management failure.
Who Owns Which Field
The 72-hour notification fails on ownership more often than on content. Assign each element before an incident.
| Role | Owns at 72 hours | Effort |
|---|---|---|
| Incident commander / SOC lead | The Established tier: confirmed technical facts, systems affected, timeline, IoCs released for sharing | Medium |
| Compliance officer | The filing itself — deadline tracking from the awareness timestamp, jurisdiction-specific fields, submission evidence, and the Article 23(4)(d) date the submission sets running | Low |
| Legal counsel | Review of the Assessed tier for language that overstates certainty; the law-enforcement question where the national form asks it; the parallel GDPR assessment | Medium |
| Executive sponsor / management body | Sign-off on the severity and impact assessment, since it is the entity’s formal position on the incident’s scale | Low |
One incident can also run two clocks. Where personal data is involved, the GDPR Article 33 notification runs on its own timer from its own trigger — our guide to NIS2 and GDPR dual notification explains why the two 72-hour figures are not the same 72 hours. That parallel assessment is legal counsel’s field in the table above, not the compliance officer’s afterthought.
Frequently Asked Questions
Does the 72-hour clock restart if the incident escalates? No. The deadline is tied to becoming aware of the significant incident, and escalation of an incident you already know about creates no new awareness moment. New information belongs in the notification, or in a follow-up to it.
What if, at hour 60, we conclude it was not significant after all? The Article 23(1) duty attaches to significant incidents, so a documented reassessment can end the reporting obligation. But if you already filed an early warning, the BSI’s position is that a submitted notification cannot be withdrawn — correct the record through a follow-up rather than by going silent, and keep the reassessment and its reasoning.
Is the GDPR 72-hour deadline the same deadline? No. They are different obligations to different authorities, measured from different triggers, and they routinely fall on different timestamps. Treat them as parallel workstreams.
What if the national portal is unavailable at hour 71? Use the authority’s fallback channel and record the attempt. The CCB, for example, states that where its form is unavailable or technically impossible to reach, an emergency telephone call to the national CSIRT may be considered equivalent to the notification. Check whether your own authority publishes a comparable route before you need it.
Do we file a separate 72-hour notification in every affected Member State? Ordinarily no — you notify your own CSIRT or competent authority, and Article 23(6) puts the onward duty on that authority to inform other affected Member States and ENISA. Entities established in more than one Member State should confirm their filing route in advance.
This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.
For the full three-stage picture, see our guide to reporting a NIS2 significant incident and the NIS2 incident reporting overview.
Sources
- Directive (EU) 2022/2555 (NIS2), Articles 23 and 34, Recitals 101-102 — "NIS 2 Directive, Article 23: Reporting obligations", linked in full above; verified against the consolidated text on EUR-Lex, CELEX 32022L2555
- Commission Implementing Regulation (EU) 2024/2690, Article 1 (Subject matter) — EUR-Lex
- "NIS-2-Meldepflicht" — Bundesamt für Sicherheit in der Informationstechnik (BSI), Germany, #nis2know information package (bsi.bund.de)
- "NIS2 Notification Guide", version 1.2, October 2024 — Centre for Cybersecurity Belgium (CCB) (ccb.belgium.be)
- "SANS 2025 State of ICS Security Report: Progress, Pressure, and the Path to Resilience" — SANS Institute
Get the NIS2 Article 21 Compliance Checklist
90+ assessment items mapped to CIR 2024/2690 — instant PDF, no payment.
