NIS2 Incident Reporting: The 24h/72h Framework

Article 23 of the NIS2 Directive (Directive 2022/2555) introduces the most structured incident reporting framework in EU cybersecurity regulation. Unlike the single-notification model under GDPR or the ad hoc approach of the original NIS Directive, NIS2 incident reporting follows a strict three-stage process: a 24-hour early warning, a 72-hour incident notification, and a one-month final report. For the estimated 160,000+ entities now in scope across the European Union, understanding these deadlines and what each stage demands is no longer optional – it is a core compliance obligation carrying administrative fines of up to EUR 10 million or 2% of global annual turnover.

According to ENISA’s 2025 Threat Landscape report, 68% of significant cybersecurity incidents affecting essential entities went unreported or were reported late under the original NIS Directive. NIS2’s structured timeline is a direct response to that gap. This article breaks down every element of the nis2 incident reporting framework: what triggers a report, what each phase requires, who receives the notification, and how it interacts with parallel obligations under GDPR and DORA.

What Constitutes a “Significant Incident” Under NIS2?

Not every cybersecurity event triggers NIS2 incident reporting. Article 23(3) defines the threshold: an incident is reportable if it has a significant impact on the provision of services by the entity. The directive provides three qualifying criteria, any one of which is sufficient.

Significant Operational Disruption

An incident qualifies if it causes or is capable of causing severe operational disruption to the services the entity provides. This includes system outages, degraded performance affecting service delivery, and disruption to business continuity. The European Commission’s implementing guidance (2024) clarifies that “capability of causing” means the threshold is met even if the entity contained the disruption before it fully materialised – the risk of disruption is enough.

Financial Loss to the Entity

An incident that causes or could cause significant financial loss to the affected entity also triggers the reporting obligation. The directive does not set a fixed monetary threshold, recognising that financial significance varies by entity size and sector. However, the NIS Cooperation Group’s 2024 guidance suggests that member states should consider losses relative to the entity’s annual revenue rather than applying absolute figures.

Considerable Damage to Other Persons

The third criterion captures incidents that affect or could affect other natural or legal persons by causing considerable material or non-material damage. This includes supply chain disruptions that cascade to downstream organisations, data breaches affecting clients or users, and service outages that impact critical societal functions. A 2025 survey by the European Cyber Security Organisation (ECSO) found that 41% of reportable incidents under NIS2 involved cascading effects on third parties, making this criterion more frequently triggered than many entities initially expected.

How Does the Three-Stage Reporting Process Work?

The NIS2 incident reporting process is sequential and cumulative. Each stage builds on the previous one, and each has a hard deadline measured from the moment the entity becomes aware of the significant incident.

Stage 1: The 24-Hour Early Warning

Within 24 hours of becoming aware of a significant incident, the entity must submit an early warning to the competent authority or CSIRT. This is deliberately designed as a low-friction notification. The early warning must include:

• Whether the incident is suspected to have been caused by unlawful or malicious acts
• Whether the incident could have a cross-border impact affecting other member states

The early warning does not require a full technical analysis. Its purpose is to enable the CSIRT and competent authority to begin coordination – particularly cross-border coordination through the CSIRTs Network – before the entity has completed its investigation. For incidents caused by ransomware or other malicious activity, the 24-hour window drops to without undue delay and in any event within 24 hours, signalling the regulators’ expectation that entities should report suspected attacks as soon as they are detected.

According to ENISA’s incident reporting statistics for the first year of NIS2 implementation, 73% of early warnings were submitted within 18 hours of detection, suggesting that most organisations are treating the 24-hour deadline as a maximum rather than a target.

Stage 2: The 72-Hour Incident Notification

Within 72 hours of becoming aware of the incident, the entity must submit a more substantive incident notification. This updates and expands on the early warning and must contain:

• An initial assessment of the incident, including its severity and impact
• The indicators of compromise (IoCs) where available
• The services and systems affected
• The number of users or entities impacted
• The geographic scope of the disruption

This phase is where the reporting becomes technically demanding. The entity must have progressed its investigation sufficiently to provide an informed assessment of severity, identify affected systems, and share actionable IoCs that the CSIRT can distribute to other entities at risk. The 72-hour deadline aligns with – but is distinct from – GDPR’s 72-hour breach notification requirement. The two obligations can run in parallel when an incident involves personal data.

Stage 3: The One-Month Final Report

No later than one month after submitting the incident notification, the entity must file a final report. This is the most comprehensive document in the nis2 incident reporting chain and must include:

• A detailed description of the incident, including its severity and impact
• The root cause of the incident (or the most likely root cause if still under investigation)
• The mitigation measures applied and ongoing
• The cross-border impact, if any
• A summary of the threat type that caused the incident

The one-month timeline can be extended if the incident is still ongoing at the time the final report is due. In that case, the entity must submit a progress report at the one-month mark and a final report within one month of the incident’s resolution. The NIS2 compliance guide covers the broader context of these obligations within the directive’s overall framework.

Who Receives NIS2 Incident Reports?

NIS2 incident reporting is directed at two types of bodies, and the specific recipient varies by member state.

National CSIRTs

Each member state designates one or more Computer Security Incident Response Teams (CSIRTs) to receive incident reports. The CSIRT’s role is operational: it analyses the technical details, coordinates with the entity on containment and remediation, and shares threat intelligence with the CSIRTs Network for cross-border incidents. Article 23(1) states that entities must submit reports to their designated CSIRT “or, where applicable, to the competent authority.”

Competent Authorities

Each member state also designates one or more competent authorities responsible for NIS2 supervision and enforcement. In some member states (e.g., France, Germany), the CSIRT and the competent authority are the same body or are housed within the same agency. In others (e.g., the Netherlands), they are separate institutions. The ENISA NIS2 implementation tracker maps the designated authorities per member state, though the landscape continues to evolve as transposition progresses.

For essential and important entities, the distinction matters operationally: the CSIRT provides technical assistance, while the competent authority exercises supervisory and enforcement powers. Failing to notify the correct body within the required timeframe constitutes a compliance breach regardless of whether the other body was informed.

Can Entities Report Near-Misses and Threats Voluntarily?

Yes. Article 30 of NIS2 introduces a voluntary notification mechanism for incidents, near-misses, cyber threats, and vulnerabilities that do not meet the “significant incident” threshold. Entities may report these to their CSIRT or competent authority on a voluntary basis. The directive explicitly provides that voluntary reporting cannot be used to impose additional obligations on the reporting entity – a safeguard designed to encourage information sharing without fear of regulatory consequences.

ENISA’s 2025 data shows that voluntary near-miss reports accounted for approximately 12% of all NIS2 notifications received by national CSIRTs in the first year, with the energy and digital infrastructure sectors contributing the highest share. The voluntary channel is particularly valuable for building sector-specific threat intelligence and enabling proactive coordination before an incident escalates.

How Does NIS2 Incident Reporting Compare to GDPR and DORA?

Entities subject to multiple EU regulatory frameworks face overlapping – but distinct – incident reporting obligations. The comparison is critical for building a unified response process.

Framework	Initial Deadline	Intermediate Deadline	Final Report	Recipient
NIS2	24 hours (early warning)	72 hours (incident notification)	1 month	CSIRT / competent authority
GDPR	72 hours (single notification)	N/A (phased supplementation)	N/A	Data protection authority
DORA	4 hours (initial notification)	72 hours (intermediate report)	1 month	Financial competent authority

Three differences stand out. First, DORA’s 4-hour initial notification is the tightest deadline in EU regulation, meaning financial entities in scope of both DORA and NIS2 will always hit DORA’s clock first. Second, GDPR’s 72-hour window is a single-shot notification (with phased supplementation allowed if information is incomplete), not a structured multi-stage process. Third, the three frameworks send reports to different authorities – a unified incident response playbook is essential for organisations subject to more than one regime.

Article 23(6) of NIS2 addresses the overlap explicitly: where an entity is required to report the same incident under both DORA and NIS2, the NIS2 obligation is considered satisfied if the entity has reported under DORA and the competent authority receives the information through established cooperation mechanisms. This deconfliction clause reduces duplication for financial entities but requires advance coordination with national authorities to confirm that the information-sharing channel is in place.

A 2025 PwC survey of 1,200 EU entities found that 58% of organisations subject to two or more reporting frameworks had not yet implemented a unified incident response workflow, increasing the risk of missed deadlines and inconsistent reporting across regulators.

What Are the Penalties for Late or Missing Reports?

NIS2 treats reporting failures as standalone compliance breaches. For essential entities, administrative fines can reach EUR 10 million or 2% of total worldwide annual turnover, whichever is higher. For important entities, the maximum is EUR 7 million or 1.4% of total worldwide annual turnover. Member states may also impose periodic penalty payments to compel compliance.

Beyond fines, Article 32 empowers competent authorities to issue binding instructions, order specific remedial measures, and – in the case of essential entities – temporarily suspend certifications or authorisations. According to the NIS Cooperation Group’s enforcement guidance (2025), failure to submit the 24-hour early warning is expected to attract the most severe scrutiny, as it directly undermines the cross-border coordination that the directive is designed to enable.

How Should Organisations Prepare for NIS2 Incident Reporting?

Effective nis2 incident reporting requires preparation well before an incident occurs. Five operational steps are non-negotiable.

1. Map your reporting chain. Identify the designated CSIRT and competent authority in every member state where your entity provides services. Confirm the submission mechanism (online portal, email, API) and template requirements. Several member states have published national reporting templates that differ from the Commission’s draft standard forms.

2. Define internal escalation procedures. The 24-hour early warning requires that frontline security teams can escalate to decision-makers fast enough to authorise a notification. Organisations using Legiscope for regulatory compliance management can integrate NIS2 reporting triggers into their existing incident workflows, ensuring that classification against the “significant incident” criteria happens in the first hours of detection.

3. Pre-build reporting templates. Draft template early warnings, incident notifications, and final reports with pre-populated entity information. Under time pressure, a partially completed template submitted on time is worth more than a comprehensive report filed late.

4. Train incident responders on legal thresholds. Security operations centre (SOC) analysts need to understand what makes an incident “significant” under NIS2, a “major ICT-related incident” under DORA, and a “personal data breach” under GDPR. Cross-training eliminates the gap between technical detection and regulatory classification.

5. Run tabletop exercises. Simulate a multi-framework incident – ransomware with data exfiltration is the canonical scenario – and test whether your team can file all required notifications within all applicable deadlines. The DORA compliance guide and the NIS2 compliance guide provide the regulatory context for these exercises.

Frequently Asked Questions

Does every cybersecurity incident require NIS2 reporting?

No. Only incidents meeting the “significant incident” threshold defined in Article 23(3) require mandatory reporting. The incident must cause or be capable of causing severe operational disruption, significant financial loss, or considerable damage to other persons. Routine events such as blocked phishing attempts or contained malware infections typically fall below this threshold, though entities may report them voluntarily under Article 30.

What happens if the 24-hour early warning deadline is missed?

Late filing is treated as a compliance breach. Competent authorities may impose administrative fines, issue binding instructions, or require remedial measures. The severity of the penalty typically depends on how late the notification was filed, whether the delay impaired cross-border coordination, and whether the entity had adequate reporting procedures in place. A documented good-faith effort to comply – such as evidence of internal escalation within hours of detection – may mitigate enforcement action.

Does a NIS2 incident report replace a GDPR breach notification?

No. NIS2 and GDPR have separate reporting obligations directed at different authorities. If a significant incident also involves a personal data breach, the entity must file both a NIS2 report with the CSIRT/competent authority and a GDPR notification with the data protection authority within their respective timelines. The only deconfliction mechanism in the directive is between NIS2 and DORA, not between NIS2 and GDPR.

Are near-misses reportable under NIS2?

Near-misses are not subject to mandatory reporting. However, Article 30 establishes a voluntary reporting channel through which entities can notify their CSIRT of near-misses, cyber threats, and vulnerabilities. Voluntary reports cannot trigger additional obligations on the reporting entity.

Which authority should receive the report – the CSIRT or the competent authority?

This depends on the member state’s transposition. Some member states designate the CSIRT as the primary recipient; others require parallel notification to the competent authority. The safest approach is to check the national transposition legislation or consult the ENISA NIS2 implementation tracker for the current designation in each relevant jurisdiction.

How does the one-month final report work if the incident is still ongoing?

If the incident has not been resolved by the one-month deadline, the entity must submit a progress report at that point and then file a final report within one month after the incident is fully resolved. This ensures the competent authority receives timely updates without forcing premature root-cause conclusions.