A cyber incident strikes a Tuesday morning. By Tuesday lunch, the question on the executive committee table is no longer what is happening — it is what does the regulator need from us, and when. Article 23 of Directive (EU) 2022/2555 is the part of NIS2 that runs the clock. It is also the part that boards most often misread.
This is the practical 72-hour guide, written hour by hour, with the legal text read closely and the operational implications translated.
When the clock starts: "awareness", not "detection"
Article 23(1) requires entities to notify significant incidents to the CSIRT or competent authority without undue delay. The clock referenced throughout the article runs from the moment the entity becomes aware of the incident.
That distinction matters. "Awareness" is not the moment a SIEM alert fires. It is the moment a person inside the entity, with the authority and information to make the call, has reasonable grounds to believe an incident has occurred and that it meets the significance threshold. Recital 101 of the directive frames this as a judgement call, not an automatic trigger.
In practice, "awareness" is the moment your CSIRT lead, or the head of security operations, or the duty officer on call, decides that the alert in front of them looks like a significant incident. That decision should be timestamped. National CSIRTs — ANSSI in France, BSI in Germany, INCIBE-CERT in Spain, ACN/CSIRT Italia, NCSC-IE in Ireland — all expect the timestamp in the notification.
Hour 24: the early warning
Article 23(4)(a) requires an early warning within 24 hours of awareness. The early warning is short. It must indicate:
- whether the entity suspects the incident was caused by unlawful or malicious acts,
- whether the incident could have cross-border impact, and
- (in practice, even if not strictly listed) basic identifying information so the CSIRT can route the case.
That is the whole content. No detailed forensics, no full impact assessment, no patient zero. The early warning is a routing signal, not a report.
The common mistake is to treat the early warning as the full notification and miss the window because the entity was still investigating. The directive is explicit on this point: the early warning is a flag, not a finding. Send it on partial information; correct or expand on the 72-hour notification if needed.
Hour 72: the incident notification
Article 23(4)(b) requires an incident notification within 72 hours of awareness, updating the early warning with substantive information. It must include:
- an initial assessment of the significance of the incident (severity, impact, scope),
- where available, indicators of compromise (IoCs).
This is where regulators look for evidence that the entity has a working incident response process. The expectations published by the European national CSIRTs, with reference to ENISA's incident reporting guidance, are consistent on what "substantive" means:
- a description of the affected services and the operational impact (in plain language and quantified where possible — number of users affected, duration of disruption),
- the type of threat (ransomware, unauthorised access, data exfiltration, denial-of-service, supply-chain compromise),
- IoCs available at the time of notification (file hashes, malicious domains, attacker IPs),
- the mitigation actions already taken or in progress.
The notification is submitted via the national reporting channel — for most Member States, an authenticated portal operated by the CSIRT or competent authority. The format varies; the substance does not.
One month: the final report
Article 23(4)(d) requires a final report no later than one month after the incident notification. It must contain:
- a detailed description of the incident, including its severity and impact,
- the type of threat or root cause that likely triggered the incident,
- the applied and ongoing mitigation measures,
- where applicable, the cross-border impact of the incident.
If the incident is still ongoing at the one-month mark, Article 23(4)(c) provides for a progress report instead, with a final report submitted within one month of the incident's resolution.
The final report is the document that closes the regulatory loop. It is also the document that, in jurisdictions with director liability, becomes the centrepiece of any subsequent enforcement review. Boards should treat it accordingly: read it, challenge it, sign off on it, minute the discussion.
What counts as a "significant incident"?
Article 23(3) defines a significant incident as one that:
- has caused or is capable of causing severe operational disruption of services or financial loss for the entity, or
- has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage.
The Commission has published thresholds for digital service providers and certain other categories (Implementing Regulation (EU) 2024/2690). For other in-scope sectors, the assessment is qualitative and rests with the entity in the first instance, subject to challenge by the national competent authority.
The trap, in practice, is not that entities under-report — it is that they over-report borderline events to be safe, and then drown the CSIRT in noise. ENISA's guidance is clear: significance is the test, not severity in absolute terms. A 30-minute disruption to a checkout flow may be significant for a payments processor at scale; the same disruption to a back-office tool may not be.
The 72-hour clock is not a deadline for completeness. It is a deadline for honest, structured disclosure of what is known so far.
What good looks like
Three signals show up consistently in regulator post-incident reviews:
- A dated incident timeline that pinpoints the moment of awareness and shows the time of the early warning, the 72-hour notification, and the final report. Gaps between these milestones are tolerated; missing timestamps are not.
- A single signed authority for the notification chain — typically the CSIRT lead with a documented escalation path to the CEO or legal representative. Multiple uncoordinated notifications from different parts of the entity are a red flag.
- Evidence the board was informed at each milestone. A board minute referencing the early warning is enough. Silence on the timeline gives the regulator room to ask why.
None of these are documents the entity needs to invent at the moment of crisis. They are documents the entity needs to have rehearsed in advance. The 72-hour clock is short; the runway to prepare is not.
Sources
- Directive (EU) 2022/2555, Article 23 ("Reporting obligations").
- Directive (EU) 2022/2555, Article 23(3) (definition of "significant incident").
- Directive (EU) 2022/2555, recitals 100 to 102 (incident reporting process and significance criteria).
- Commission Implementing Regulation (EU) 2024/2690 (incident significance thresholds for digital service providers and similar categories).
- Published incident reporting guidance from national competent authorities and CSIRTs: ANSSI / CERT-FR (FR), BSI / CERT-Bund (DE), INCIBE-CERT (ES), ACN / CSIRT Italia (IT), NCSC-IE (IE), and ENISA.
