NIS2 Incident Reporting: The Complete 24-72-1 Guide

TL;DR

NIS2 Article 23 requires three notification stages: an early warning within 24 hours, a full notification within 72 hours, and a final report within one month. The 24h clock starts when you become aware of a significant incident, not when you have full details.

The notification requirements under NIS2 are stricter than anything EU organisations have dealt with before. GDPR gives you 72 hours for a data breach notification. NIS2 compresses that to 24 hours for the first early warning, even if you barely have any information at that point.

This guide explains what makes an incident 'significant', what belongs in each of the three notifications, who you report to, and which mistakes most organisations make the first time.

When Is an Incident 'Significant'?

NIS2 Article 23(3) defines a significant incident as one that:

🔴

has caused or is capable of causing severe operational disruption of the services or financial losses for the entity concerned, or

🔴

has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage.

The EU Implementing Regulation 2024/2690 introduced sector-specific quantification thresholds. Examples of concrete thresholds:

Sector	Example threshold for 'significant'
DNS services	Outage of more than 30 minutes or degradation affecting more than 1% of users
Cloud services (Essential category)	Outage of more than 60 minutes or data loss
Energy (electricity)	Outage affecting more than 50,000 users or lasting more than 60 minutes
Health (hospitals)	Failure of critical IT systems that disrupts patient care for more than 30 minutes
Financial infrastructure	Outage of payment services for more than 30 minutes or loss of customer data

Source: EU Implementing Regulation 2024/2690. Full thresholds vary by sector and entity type.

The Three Notification Stages in Detail

Stage 1Early WarningWithin 24 hours

Clear statement that a significant incident has occurred or is suspected
Type of incident (where known): ransomware, DDoS, data breach, unauthorised access, etc.
Whether the incident is or could be cross-border
Preliminary assessment of whether the act appears to be malicious
No complete report required: 'We are investigating, details to follow' is acceptable

Stage 2Full NotificationWithin 72 hours

Update or confirmation of information from the early warning
Initial assessment of the incident: severity, impact, indicators of compromise (IoCs)
Type of threat or root cause, where identified: external attackers, internal error, supply chain issue
Affected systems, services, and geographic areas
Remediation measures taken or planned
If needed: request for support from CSIRT or competent authority

Stage 3Final ReportWithin 1 month

Full description of the incident: timeline, affected systems, attack vectors
Root cause analysis: how was the incident able to occur?
Assessment of severity and cross-border impact
Remediation measures taken and their effectiveness
Measures to prevent future incidents of the same type
Status: whether the incident is ongoing or closed

Who Receives the Notification?

NIS2 designates the national CSIRT as the primary recipient of incident notifications. If the member state has not designated a CSIRT as the primary recipient, the notification goes directly to the national competent authority. In some countries, both must be notified.

Country	Notification body	Portal / Contact
🇩🇪 Germany	BSI (Bundesamt für Sicherheit in der Informationstechnik)	bsi.bund.de/meldung
🇧🇪 Belgium	CCB (Centre for Cybersecurity Belgium) / CERT.be	cert.be / report.ccb.belgium.be
🇫🇷 France	ANSSI (Agence nationale de la sécurité des systèmes d'information)	cyber.gouv.fr/declaration-d-incident
🇳🇱 Netherlands	NCSC-NL (via sector regulators)	ncsc.nl
🇸🇪 Sweden	NCSC-SE (Nationellt cybersäkerhetscenter)	ncsc.se
🇪🇸 Spain	CCN-CERT / INCIBE-CERT	incibe.es / ccn-cert.cni.es

Always verify the current notification portals directly with your national authority, as processes can change following national transposition.

📊 Quick Test

Find out if your company is in scope

Does your organisation fall under Annex I (Essential) or Annex II (Important) entities?

Check NIS2 Scope →

The Most Common Mistakes in NIS2 Notifications

⏰

Waiting for full details before the early warning

Many organisations wait until they have all the facts before sending the 24h early warning. That is a mistake. The early warning only needs to signal that a significant incident has occurred or is suspected. Nothing more is required at this stage.

📋

Contacting the wrong authority

In multi-sector organisations, there may be multiple competent authorities. An energy provider with IT services may need to notify both the energy sector regulator and the IT security authority. Clarify this before an incident occurs.

📝

Having no notification templates

During the stress of an active incident is not the time to create a notification template. Prepare templates for all three stages in advance, so they only need to be filled with incident-specific data when needed.

🔄

Confusing the 72h notification with the early warning

The early warning (24h) and the full notification (72h) are two separate documents. Some organisations send a single notification after 48 hours. That misses both deadlines simultaneously.

🗂️

No documentation of the notification process

Authorities can require you to demonstrate during an audit when you became aware of an incident, when you sent the early warning, and who authorised the notifications in your organisation. Document every step.

Voluntary Notifications and Their Value

NIS2 also allows voluntary notifications for incidents that do not meet the threshold for mandatory reporting. Article 30 makes clear that such notifications must not disadvantage the reporting organisation. This is a deliberate incentive to keep authorities informed about emerging threats.

Voluntary notifications can be strategically sensible: they build a relationship with the authority before you urgently need one, and they demonstrate a cooperative stance that can be factored positively into later fine calculations.

How to Prepare Your Notification Process

Identify your authority and CSIRT

Identify the competent authority for your sector in your country and register for the relevant notification portal before an incident occurs.

Define significance thresholds

Translate the abstract NIS2 criteria into concrete, measurable trigger rules for your organisation. Example: 'Any outage of our critical core banking systems exceeding 30 minutes qualifies as a significant incident'.

Create notification templates

Develop a template for each of the three stages. Have these internally approved and store them in a location accessible even during a ransomware attack (for example, in a separate document management system or printed).

Assign responsibilities

Define who can trigger a notification, who must approve it, and who actually submits it. Document the authority contact details and internal contacts in your incident response plan.

Run exercises

Run at least one tabletop exercise per year simulating a fictitious significant incident and walking through the NIS2 notification obligations. Document the results.

Ready to test your incident process?

Our free Incident Reporting tool helps you structure a correct NIS2 notification.

🚨 Open Incident Tool 📊 Start Gap Assessment

Frequently Asked Questions

When exactly does the 24-hour clock start?

The clock starts when your organisation 'becomes aware' of the incident. That means: as soon as someone in your organisation documents or escalates it internally. An informal chat mention may already count. Set up a clear internal reporting process that defines the 'awareness' moment precisely.

What happens if we miss the 24h deadline?

Missing a notification deadline is a separate violation of NIS2 Article 23 and can lead to a separate fine procedure, independent of the original incident. Authorities generally consider whether the failure was due to lack of knowledge or deliberate disregard.

Do we still need to report if the incident turns out to be less serious?

If you have already sent the 24h early warning and it later turns out that the incident does not meet the significance threshold, you should inform the authority. There is no penalty for having sent an early warning that later proved unnecessary.

Does the 72h deadline apply to incidents outside business hours?

Yes. The deadlines run continuously, including weekends and holidays. This requires that you establish an on-call arrangement for incident response and notifications. CSIRTs and authorities typically also have emergency contacts outside office hours.

Can we submit a single notification for multiple incidents?

No. Each significant incident requires a separate notification. If you are affected by multiple incidents simultaneously (for example, during a coordinated attack campaign), report each separately and note the possible connection.