NIS2 Incident Reporting: Understanding the 24-Hour Rule

For many organizations coming to grips with the NIS2 Directive (Directive 2022/2555), the incident reporting obligations under Article 23 represent one of the most operationally challenging requirements. The 24-hour early warning window is short. The scope of what constitutes a "significant incident" is broad. And the consequences of missing the deadline — or failing to recognize that a reportable incident has occurred — can trigger direct supervisory action.

This article breaks down the three-stage reporting timeline, explains what triggers the obligation, and outlines what your notification must contain at each stage.

What Is a "Significant Incident"?

Before examining the timeline, you need to understand when the reporting obligation is triggered. Article 23 applies to significant incidents — a term NIS2 defines using two criteria. An incident is significant if it:

a) Has caused or is capable of causing severe operational disruption to the services provided, or financial loss for the entity concerned; OR

b) Has affected or is capable of affecting other natural or legal persons by causing considerable material or immaterial damage.

Notice the forward-looking language: "capable of causing" and "is capable of affecting." You do not need to wait until damage materializes. If a security event has the potential to cause the defined harms, the incident is significant and the clock starts running.

ENISA has published additional guidance noting that in the energy, health, and digital infrastructure sectors, the threshold for "significant" should be interpreted conservatively — when in doubt, notify.

The Three-Stage Reporting Timeline

Article 23 establishes a three-tier notification structure. This is not a single report — it is a sequential disclosure process with defined content requirements at each stage.

Stage 1: Early Warning — Within 24 Hours

Deadline: No later than 24 hours after the entity becomes aware of the significant incident.

Recipient: National CSIRT (Computer Security Incident Response Team) or the competent authority designated in your Member State.

Required content at this stage (intentionally limited):

• Indication of whether the incident is suspected to be caused by unlawful or malicious action
• Whether the incident is likely to have a cross-border impact (affecting organizations or infrastructure in other EU Member States)
• The general nature of the incident (a brief description without prejudicing the ongoing response)

The 24-hour early warning is deliberately lightweight. Its purpose is to give your national CSIRT situational awareness, not to require a fully formed incident report during your initial response. You are not expected to have root cause analysis complete at this stage.

Practical implication: Your incident response plan must include a step, triggered within the first few hours of detecting a significant incident, to file the early warning. This requires a functioning 24/7 escalation path — you cannot rely on business-hours-only processes when incidents typically occur on Friday evenings or during holiday periods.

Stage 2: Incident Notification — Within 72 Hours

Deadline: No later than 72 hours after becoming aware of the significant incident (or, if an Early Warning was submitted, an update to that Early Warning within 72 hours).

Required content (substantially more detailed):

• Initial assessment of the significant incident, including its severity and impact
• Indicators of compromise where available
• An update on the information provided in the Early Warning

At this point, supervisors expect you to have conducted at least a preliminary investigation. You should be able to characterize the incident type (ransomware, data breach, DDoS, insider threat, etc.), identify the systems affected, and provide an initial estimate of scope.

The 72-hour window aligns intentionally with GDPR's Article 33 breach notification to supervisory authorities. If your incident involves personal data, you will typically be filing parallel notifications — one to your national CSIRT under NIS2, and one to your lead supervisory authority under GDPR. Some Member States have created joint notification portals to simplify this.

Stage 3: Final Report — Within 1 Month

Deadline: No later than one month after the Incident Notification submission (or, if the incident is still ongoing at that point, the deadline may be extended — check your national transposition law).

Required content (comprehensive):

• Detailed description of the incident, including its severity and impact
• Type of threat or root cause that triggered the incident
• Applied and ongoing mitigation measures
• Cross-border impact where applicable

Where the incident is still ongoing at the one-month mark, the entity submits an interim report at that point and a final report within one month of the incident being handled.

The Full Timeline at a Glance

| Stage | Deadline | Content Required | |---|---|---| | Early Warning | T+24h | Nature, suspected malicious act, cross-border risk | | Incident Notification | T+72h | Initial assessment, severity, IOCs | | Intermediate Report (if ongoing) | T+30 days (if incident ongoing) | Status update, ongoing mitigations | | Final Report | T+30 days after handling | Root cause, full description, mitigations applied |

T = moment the entity becomes aware of the significant incident.

When Does the Clock Start?

"Becomes aware" is the triggering condition, and it is interpreted as the moment a responsible person in your organization has sufficient information to recognize that a significant incident has occurred or is occurring.

This creates an important operational risk: if your detection capabilities are poor, you may be unaware of an incident for days or weeks. While this technically delays the clock, it does not protect you — supervisors will examine whether your detection capabilities were adequate, and a failure to detect may itself constitute a breach of Article 21's security requirements.

Conversely, if you detect anomalous activity but are uncertain whether it meets the "significant" threshold, ENISA guidance suggests erring toward notification. A false positive report does not attract penalties; a missed significant incident can.

Cross-Border Incidents

If your incident has or is likely to have an impact on entities or critical services in other EU Member States, Article 23 requires you to indicate this in your Early Warning. Your national CSIRT is then responsible for notifying the relevant CSIRTs in affected Member States.

For multinational organizations, this can mean coordinating notifications across multiple national systems simultaneously. The NIS Cooperation Group has published templates to standardize reporting formats, but implementation varies by Member State.

Building a Compliant Reporting Capability

Most organizations that fail to meet Article 23 obligations do so not because of bad faith but because of operational gaps:

Gap 1: No 24/7 escalation path Your security operations must be able to trigger an Early Warning outside business hours. A security event detected on Saturday morning cannot wait until Monday for the compliance team to decide whether it is "significant."

Gap 2: No pre-approved notification templates Drafting a compliant Early Warning during an active incident, when your team is simultaneously managing the response, is unnecessarily difficult. Pre-approved templates for common incident types (ransomware, data breach, DDoS) reduce friction significantly.

Gap 3: Unclear "significant" threshold Your incident classification policy must include explicit criteria for when an incident crosses the NIS2 significance threshold. If everyone assumes someone else will make the call, reports get missed.

Gap 4: No CSIRT contact pre-established Know who your national CSIRT is and how to reach them before an incident occurs. Each Member State has a designated CSIRT; many have dedicated portals for NIS2 notifications.

WarDek continuously monitors your external attack surface and flags vulnerabilities that, if exploited, would constitute a significant incident under NIS2 Article 23 — giving you early visibility before a potential incident occurs, rather than starting the 24-hour clock from a position of surprise.

For an overview of NIS2 scope and which organizations must comply, see our introduction to NIS2 compliance.

This article reflects the requirements of Article 23 of Directive 2022/2555. Member States may impose additional reporting requirements in their national transposition legislation. Consult applicable national law and ENISA guidance for jurisdiction-specific obligations.