NIS2 Article 23 requires every essential and important entity to report a “significant incident” to its national CSIRT or competent authority in three stages: an early warning within 24 hours, an incident notification within 72 hours, and a final report within one month (or a progress report if the incident is still open). The 24-hour clock starts when the entity becomes aware of the incident, not when the incident itself happens. This guide gives you the operational mechanics: what counts as a significant incident, what each report must contain, the sector-specific reporting routes (CSIRT for general digital, sector regulators for finance, energy, health), and a worked timeline showing what your team should be doing in each four-hour block of the first day.

For the wider NIS2 picture, see our NIS2 compliance guide. For the scoping decision, see essential vs important entities.

What is a “significant incident” under NIS2?

Article 23 defines a significant incident as one that (a) has caused or is capable of causing severe operational disruption of the services or financial loss to the entity, or (b) has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage.

In practice, the Commission’s October 2024 implementing regulation set sector-specific thresholds for digital providers, and member-state transposition has added thresholds for other sectors. Common triggers include:

• Confidentiality breach affecting personal data or business-critical information
• Loss of integrity of network or information systems supporting service delivery
• Loss of availability where the affected service is unavailable for a defined duration (often measured in hours of total outage or percentage of users affected)
• Material impact on a critical interdependency (for example an upstream service whose disruption cascades downstream)
• A confirmed unauthorised access to systems handling sensitive data
• A ransomware or destructive-malware event affecting production systems

When in doubt, report. Authorities can stand down a notification; they cannot retro-actively credit you for a missed clock.

The three-stage reporting cascade

Stage 1: Early warning within 24 hours

Submit an early warning to the national CSIRT (or designated competent authority) within 24 hours of becoming aware of the significant incident. The early warning must indicate:

• Whether the incident is suspected of being caused by unlawful or malicious acts
• Whether it could have a cross-border impact

That is the legal minimum content. In practice, CSIRTs accept (and expect) a short initial set of contextual fields: entity identifier, incident category, services affected, geography of impact, current containment status, expected next update.

The early warning is rapid by design — speed over completeness — but it is a formal submission via the CSIRT’s defined channel, not an email. Most member states have a portal or a dedicated incident-reporting email plus secure-upload channel.

Stage 2: Incident notification within 72 hours

Within 72 hours of becoming aware of the incident, submit a substantive notification updating and expanding on the early warning. Required content:

• An updated initial assessment of the incident, including severity and impact
• Indicators of compromise (IOCs) where available
• Confirmation or correction of the malicious-acts and cross-border indications from the early warning

This is where the CSIRT cycle starts to add value: a well-formed 72-hour notification with IOCs allows the CSIRTs Network and ENISA to warn peer CSIRTs about ongoing campaigns. Your IOCs may be re-distributed to other in-scope entities; this is the intended behaviour.

Stage 3: Final report within one month

Within one month after the 72-hour notification, submit a final report containing:

• A detailed description of the incident, including its severity and impact
• The type of threat or root cause that triggered the incident
• The mitigation measures that have been applied
• Where applicable, the cross-border impact of the incident

If the incident is ongoing at the one-month mark, submit a progress report at one month and a final report within one month of the actual incident resolution.

Worked timeline — the first 24 hours

Use this as a template for your incident-response runbook. Every block has a designated decision-maker.

If the incident clearly exceeds the threshold in the first hour, do not wait — the 24-hour clock has already started.

Sector-specific reporting routes (parallel obligations)

NIS2 is not the only reporting obligation that may apply. In many incidents you will file in parallel to:

The NIS2 and GDPR clocks both run from “awareness”, but they go to different regulators and serve different purposes. Treat them as parallel tracks with overlapping evidence, not as one report.

Decision tree — do I report under NIS2?

1. Is your entity in scope of NIS2? If not, stop (but check GDPR and sector-specific obligations).
2. Does the event meet the “significant incident” threshold (severe operational disruption OR financial loss OR material impact on others)? If unclear, treat as significant — better to file and stand down than to miss the clock.
3. Has the entity become aware (not “happened” — aware)? If yes, the 24-hour clock has started.
4. Is the incident cross-border? Mark in the early warning; expect onward reporting via the CSIRTs Network.
5. Is malicious activity suspected? Mark in the early warning; this materially changes which IOCs the CSIRT will request at the 72-hour stage.
6. Personal data involved? Run a parallel GDPR 72-hour assessment.
7. Sector regulator obligations? Run parallel sector reporting (see table above).

Common mistakes that lead to NIS2 enforcement findings

1. Missing the 24-hour clock because containment took priority. Containment and reporting are parallel obligations, not sequential.
2. Reporting via email instead of the official CSIRT channel. The clock only stops when the official portal acknowledges receipt.
3. Treating the 72-hour notification as a finished investigation report. It is an interim update with IOCs, not the final root-cause analysis.
4. Reporting only to GDPR DPA when a parallel NIS2 obligation exists. The two are independent.
5. No drill of the 24-hour workflow. Authorities expect evidence the runbook has been exercised.
6. Inconsistent significance criteria. Two incidents with similar impact must produce similar significance decisions, or the criteria are not really documented.

Reporting-template skeleton

What every CSIRT submission portal asks for (channel-specific fields vary):

• Entity identifier and NIS2 category (essential / important)
• Reporting role and contact (24/7 reachable)
• Incident category (confidentiality / integrity / availability) and subcategory (ransomware, account takeover, DDoS, data exfiltration, supply-chain compromise, insider, other)
• Affected services and geographies; user/customer counts where known
• Awareness timestamp and submission timestamp (with explicit timezone)
• Cross-border indicator and member states potentially impacted
• Malicious-activity indicator
• Mitigation measures taken so far
• IOCs (hashes, IPs, domains, TTPs) — at 72 hours
• Expected next update time

How Enactia automates NIS2 incident reporting

Enactia’s incident workflow tracks the 24/72/one-month SLA against the awareness timestamp, prompts for the legally required fields at each stage, supports parallel filing to GDPR and sector regulators from the same incident record, and maintains an immutable audit log of every submission. Integrated CSIRT-routing presets cover the major member-state portals so the on-call team does not have to look them up at 3 a.m. Book a demo now to walk through the incident workflow against your own runbook.

Frequently asked questions

When does the NIS2 24-hour clock start?

At the moment the entity becomes aware of the significant incident — not when the incident itself begins. “Awareness” means a person within the entity has reasonable grounds to believe a significant incident has occurred. The awareness timestamp must be documented.

Does the 24-hour clock pause overnight or on weekends?

No. The 24 hours run continuously. 24/7 on-call coverage is therefore a practical requirement, in-house or contracted.

Is the early warning a final commitment?

No. The early warning is rapid and provisional. The 72-hour notification updates and corrects it. If you misclassified the incident, the 72-hour stage is when you correct the record.

Do I need to notify customers under NIS2?

NIS2 itself focuses on regulator notification. The competent authority may direct you to notify affected recipients of your services where appropriate (Article 23(2)) but customer notification is not automatic. Sector-specific rules (for example eIDAS, DORA, GDPR) may impose direct customer notification.

What if I report and the incident turns out not to be significant?

The CSIRT can stand the notification down. There is no penalty for over-reporting in good faith; there is a penalty for missing a significant-incident clock.

Are GDPR and NIS2 reporting the same?

No. GDPR’s 72-hour clock runs to the national Data Protection Authority for personal-data breaches; NIS2’s cascade runs to the CSIRT for significant cyber incidents. Both can run in parallel for an incident that involves personal data and meets the NIS2 threshold.

Do third-party (supplier) incidents trigger NIS2?

Yes, where the supplier incident causes a significant impact on your entity’s services. NIS2 Article 21(d) requires supply chain security and Article 23 captures incidents whose origin is upstream.

Want to make sure your team can hit the 24-hour clock? Book a demo now and we will walk through the Article 23 cascade against your current incident-response runbook in 30 minutes.