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. Where applicable, it updates the early warning and gives an initial assessment of the incident, including its severity and impact, and the indicators of compromise (IoCs) where available (Article 23(4)(b)). Trust service providers have 24 hours instead of 72 for this notification when the incident affects their trust services.

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 (Article 23(4)(d)). Between the notification and the final report, the CSIRT or authority can ask you for an intermediate report on relevant status updates (Article 23(4)(c)).

If the incident is still ongoing when the final report is due, you submit a progress report at that point and a final report within one month of having handled the incident (Article 23(4)(e)).

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.

For DNS service providers, TLD name registries, cloud computing, data centre and content delivery network providers, managed service and managed security service providers, online marketplaces, online search engines, social networking platforms and trust service providers, Commission Implementing Regulation (EU) 2024/2690 (Articles 3 to 14) sets out concrete cases in which an incident is significant.

For the providers listed above, the exact thresholds (outage durations, share of users affected, malicious compromise of service data, financial loss above €500,000 or 5% of turnover) are set out in our guide to NIS2 significant incident thresholds. Other entities apply the Article 23(3) test, and any national guidance, by asking:

Operational disruption: Has the incident caused, or could it cause, severe disruption of the services you provide? Consider duration, the share of customers affected and whether critical functions stop.

Financial loss: Has it caused, or could it cause, significant financial loss for you, such as recovery costs, lost revenue or penalties?

Damage to others: Has it affected, or could it affect, customers, partners or other people by causing considerable material or non-material damage, for example through leaked data or unavailable services they depend on? If personal data is involved, GDPR obligations apply in parallel.

Potential, not only actual: The test covers incidents "capable of" causing such effects. An intrusion that is still active, or a compromise at a supplier that reaches your systems, can meet it before the damage is visible.

When in doubt, report. Notifying does not in itself expose you to increased liability (Article 23(1)), and the CSIRT or authority must give you initial feedback, where possible within 24 hours of your early warning (Article 23(5)). 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": when, after an initial assessment of a suspicious event, you have a reasonable degree of certainty that a significant incident has occurred. That assessment has to happen in a timely manner (Implementing Regulation (EU) 2024/2690, recital 31). 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 requires policies and procedures to assess whether your security measures are effective (Article 21(2)(f)), and for the digital entities covered by Implementing Regulation (EU) 2024/2690, testing incident response procedures at planned intervals is explicit (Annex, point 3.5.5). 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 the DPA, unless the breach is unlikely to result in a risk to people. Information you do not have yet can follow in phases (Article 33(4)). Affected people must also be told if the risk to them is high (Article 34).

DORA: initial notification within 4 hours of classifying the incident as major and no later than 24 hours after becoming aware of it → intermediate report within 72 hours of the initial notification → final report within one month of the latest intermediate report (Delegated Regulation (EU) 2025/301, Article 5). To the competent authority (financial supervisor).

Financial entities subject to DORA comply with DORA's reporting requirements instead of NIS2's for ICT incidents (NIS2 Article 4 and recital 28). 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 Check 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