NIS2 Incident Reporting: How to Meet the 24-Hour Deadline

NIS2 Article 23 gives you 24 hours to send an early warning to your CSIRT or competent authority after becoming aware of a significant incident. Not 24 business hours — 24 clock hours, including weekends and holidays. If your incident response workflow is not designed for this timeline, you will miss it.

This guide breaks down exactly what NIS2 requires for incident reporting, the three-stage reporting process, what qualifies as a "significant incident," and how to build a process that meets the deadline every time.

The three-stage reporting timeline

NIS2 does not require you to have complete information within 24 hours. Instead, it establishes a progressive reporting structure with three mandatory stages:

Stage 1: Early warning — within 24 hours

Within 24 hours of becoming aware that a significant incident has occurred, you must submit an early warning to your CSIRT or competent authority. This early warning is intentionally brief. It must indicate whether the incident is suspected to be caused by unlawful or malicious acts, and whether it could have cross-border impact. That is it. You do not need to know the full scope, root cause, or impact at this stage.

The purpose of the early warning is to give authorities a heads-up so they can coordinate responses and warn other potentially affected entities. Speed matters more than completeness at this stage.

Stage 2: Incident notification — within 72 hours

Within 72 hours of becoming aware of the incident, you must submit a more detailed notification. This updates or replaces the early warning and must include an initial assessment of the incident's severity and impact, the indicators of compromise (IoCs) where available, and any initial containment actions taken.

By 72 hours, you should have a clearer picture of what happened, what systems and data are affected, and what you have done to contain the situation. If you are also subject to GDPR and personal data is involved, note that the GDPR 72-hour notification to the DPA aligns with this stage — but they go to different authorities (CSIRT/competent authority for NIS2, DPA for GDPR).

Stage 3: Final report — within one month

Within one month of the incident notification, you must submit a comprehensive final report. This must include a detailed description of the incident (including severity and impact), the type of threat or root cause that likely triggered it, the mitigation measures applied and ongoing, and the cross-border impact if applicable.

If the incident is still ongoing after one month, you submit a progress report at the one-month mark and a final report within one month of the incident's resolution.

What counts as a "significant incident"?

Not every security event triggers the reporting obligation. NIS2 Article 23(3) defines a significant incident as one that has caused or is capable of causing severe operational disruption of the service 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.

In practical terms, you should report when any of the following apply:

Service disruption: A cybersecurity incident that disrupts or degrades a service you provide — especially if it affects customers, partners, or the public. Duration matters: a 5-minute blip is different from a 5-hour outage.

Data compromise: Unauthorized access to, or exfiltration of, sensitive data — whether customer data, business-critical information, or system credentials. If personal data is involved, GDPR obligations also apply simultaneously.

Active ongoing threat: A detected intrusion where the attacker is still present in your systems — even if no data has been confirmed compromised yet and services are still running. The potential for escalation makes this reportable.

Supply chain impact: An incident at one of your suppliers or service providers that affects your operations. If your cloud provider has a significant outage or breach that impacts your service delivery, that can be reportable.

When in doubt, report. The consequences of over-reporting are minimal (the CSIRT processes it and moves on). The consequences of under-reporting — missing a mandatory notification — can include fines and regulatory scrutiny.

Building a process that meets the 24-hour deadline

Pre-incident preparation

Define your reporting chain. Who has the authority to classify an incident as "significant" and trigger the reporting process? This should be a named individual (typically the CISO, IT manager, or compliance officer) with a designated backup. Do not create a process that requires three levels of approval — the 24-hour clock does not accommodate committee decisions.

Identify your CSIRT and competent authority. Know exactly where your early warning goes. Each EU member state has designated CSIRTs and competent authorities for NIS2. Find yours now, save their contact details and reporting portals, and verify the process. Some member states have online reporting forms; others accept email. Some have dedicated NIS2 portals; others are still building them.

Pre-draft your early warning template. The early warning is brief, but under pressure at 2 AM, even brief documents are hard to produce from scratch. Have a template ready with placeholders:

NIS2 Early Warning Template

Reporting entity: [Company name, NIS2 registration if applicable]
Date/time of detection: [When you became aware]
Nature of incident: [Brief description — 1-2 sentences]
Suspected cause: [Malicious / Accidental / Under investigation]
Cross-border impact: [Yes / No / Under assessment]
Contact person: [Name, phone, email for follow-up]

Establish an out-of-band communication channel. If your email or Slack is compromised (as it often is in serious incidents), how will your response team communicate? Have a backup channel — a pre-configured Signal group, a dedicated phone tree, or a secondary email service — that does not depend on your primary IT infrastructure.

Build your plan now: Our Security Policy Generator creates a customized Incident Response Policy, and our IRP guide covers the full incident lifecycle.

During an incident

Hour 0-4: Detect, confirm, classify. The 24-hour clock starts when you become "aware" — which means when the incident has been confirmed (not just suspected) and classified as significant. Your detection-to-classification time directly affects how much of the 24 hours you have left for the actual report. Invest in faster detection and clearer classification criteria to buy yourself more reporting time.

Hour 4-20: Contain and gather initial information. While your technical team works on containment, your compliance or legal team should be drafting the early warning. In parallel, document everything with timestamps — what was detected, by whom, what actions were taken, and what is known about scope and impact.

Hour 20-24: Submit early warning. Do not wait until hour 23. Aim to submit by hour 20 to leave buffer for any technical issues with the reporting portal. Submit what you know — completeness comes later in stages 2 and 3.

After the early warning

The pressure does not end with the early warning. At 72 hours, your incident notification is due with significantly more detail. And the one-month final report requires root cause analysis and remediation measures. Build these deadlines into your incident timeline from the start — do not treat them as afterthoughts.

Common mistakes in NIS2 incident reporting

Waiting for complete information before reporting. The most common and most dangerous mistake. The early warning does not require complete information — it requires timely information. Submit what you know, update later. Waiting for a complete picture and missing the 24-hour deadline is worse than submitting an incomplete early warning on time.

Not knowing who to report to. If you are scrambling to find your CSIRT's contact details during an active incident, you have already lost precious hours. This should be documented and tested in advance.

Confusing NIS2 and GDPR reporting. They go to different authorities with different timelines and different content requirements. A personal data breach in a NIS2-covered entity requires reporting to both the CSIRT (NIS2, 24h early warning) and the DPA (GDPR, 72h notification). These are parallel obligations, not alternatives.

No weekend/holiday coverage. Attackers do not take weekends off. If your incident response capability exists only during business hours, you are exposed. The 24-hour clock runs continuously. Ensure someone is reachable and empowered to act at any hour.

Not testing the process. NIS2 explicitly requires that incident handling procedures be tested. A tabletop exercise specifically focused on the 24-hour reporting deadline will reveal weaknesses in your process before a real incident does.

How NIS2 reporting compares to GDPR and DORA

NIS2: 24h early warning → 72h notification → 1 month final report. To CSIRT/competent authority.

GDPR: 72h notification to DPA. No staged approach — single comprehensive report. Plus notification to data subjects if high risk.

DORA: 4h initial notification → 72h intermediate report → 1 month final report. To competent authority (financial regulator).

Financial entities subject to DORA comply with DORA's reporting requirements instead of NIS2's for ICT incidents (lex specialis). But if personal data is involved, GDPR reporting still applies alongside DORA.

For a detailed comparison, see our article NIS2 vs GDPR: Key Differences and How They Overlap.

Checklist: are you ready for the 24-hour deadline?

Answer these questions honestly. If any answer is "no," that is your gap to fix now — not during an incident:

☐ Do you have a named person (and backup) authorized to classify incidents and trigger reporting?
☐ Do you know your CSIRT/competent authority's contact details and reporting method?
☐ Do you have an early warning template pre-drafted?
☐ Can your team detect, confirm, and classify an incident within 4-8 hours?
☐ Do you have an out-of-band communication channel for the response team?
☐ Is someone reachable and empowered to act on weekends and holidays?
☐ Have you tested your incident reporting process in the last 12 months?

If you answered "no" to any of these, our NIS2 Readiness Assessment can help you identify all your compliance gaps across the full directive, not just incident reporting.

Further reading: NIS2 Directive Explained · How to Write an Incident Response Plan