NIS2 Incident Reporting: 24-Hour Rules and Procedures

Under the NIS2 Directive (EU 2022/2555), organizations classified as essential or important entities must report significant cybersecurity incidents following a strict multi-phase timeline: an early warning within 24 hours, an incident notification within 72 hours, and a final report within one month. These requirements, outlined in Article 23, represent one of the most operationally demanding aspects of NIS2 compliance. Failure to meet these deadlines can result in fines of up to EUR 10 million or 2% of global annual turnover. This guide breaks down exactly what you need to report, when, to whom, and how to build processes that ensure compliance.

The NIS2 Incident Reporting Timeline

Article 23 of the NIS2 Directive establishes a phased reporting framework designed to balance the need for rapid information sharing with the reality that full incident analysis takes time. Here is the complete timeline:

Phase	Deadline	Required Content	Purpose
Early Warning	24 hours from awareness	Suspected malicious act? Cross-border impact?	Enable rapid response and coordination
Incident Notification	72 hours from awareness	Initial assessment, severity, impact, IoCs	Inform authorities for situational awareness
Intermediate Report	Upon request by CSIRT/authority	Status updates on handling and recovery	Ongoing situational awareness
Final Report	1 month after incident notification	Detailed description, root cause, mitigations, cross-border impact	Lessons learned and systemic improvement
Progress Report	1 month after notification (if ongoing)	Progress update if incident is still active	Track ongoing incidents

The clock starts when the entity becomes "aware" of the significant incident. According to ENISA guidance, "awareness" means the point at which a reasonable assessment leads to the belief that a significant incident has occurred -- not when it is fully confirmed. This is an important distinction: you cannot delay reporting while waiting for complete forensic analysis.

What Constitutes a "Significant Incident"?

Not every security event triggers the NIS2 reporting obligation. Article 23(3) defines a significant incident as one that:

• Criterion A: Has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned
• Criterion B: Has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage

The European Commission is empowered to adopt implementing acts that further specify when an incident is considered significant. In the meantime, organizations should consider these practical indicators:

Incidents That Typically Qualify as Significant

• Ransomware attacks that encrypt systems or data affecting service delivery
• Data breaches involving personal data of customers, employees, or partners
• Denial-of-service attacks causing prolonged service outages
• Supply chain compromises that affect your service delivery to clients
• Unauthorized access to critical systems or networks
• Exploitation of zero-day vulnerabilities in production systems
• Insider threats resulting in data exfiltration or system sabotage

Incidents That May Not Qualify

• Blocked phishing attempts with no successful compromise
• Vulnerability scans or reconnaissance activity that is detected and contained
• Minor malware infections on isolated endpoints with no lateral movement
• Brief service interruptions due to routine technical failures (not cyber-related)

According to the IBM X-Force Threat Intelligence Index 2024, the average time to identify a breach was 204 days globally. NIS2 aims to dramatically compress this timeline by requiring organizations to have detection and triage capabilities that enable 24-hour initial reporting. The Verizon 2024 DBIR found that 62% of financially motivated breaches involved ransomware or extortion, both of which would nearly always meet the significant incident threshold.

Phase 1: The 24-Hour Early Warning

The early warning is the most time-critical phase. Within 24 hours of becoming aware of a significant incident, you must submit an early warning to your CSIRT or competent authority that includes:

1. An indication of whether the incident is suspected of being caused by unlawful or malicious acts -- This helps authorities assess whether law enforcement involvement is needed and whether other entities may be targeted
2. An indication of whether the incident could have cross-border impact -- This triggers EU-level coordination mechanisms through the CSIRTs network

The early warning is deliberately lightweight. You do not need a full assessment or root cause analysis at this stage. The purpose is to alert authorities so they can begin coordination and potentially warn other entities that may be at risk.

Practical tip: Prepare early warning templates in advance. Pre-populate fields with your organization's details and CSIRT contact information. When an incident occurs, you should be able to submit the early warning within minutes, not hours.

For organizations providing services to recipients in other Member States, Article 23(2) adds an additional obligation: you must notify affected recipients of the significant incident "without undue delay" and inform them of any measures or remedies they can take.

Phase 2: The 72-Hour Incident Notification

Within 72 hours of awareness, you must submit a more detailed incident notification that updates the early warning and includes:

• Initial assessment of the incident, including its severity and impact
• Indicators of compromise (IoCs) where available -- IP addresses, file hashes, domains, TTPs
• Updated information on whether the incident is malicious and whether cross-border impact is confirmed

This notification should reflect the results of initial triage and containment efforts. By 72 hours, most organizations should have a basic understanding of the attack vector, the scope of compromise, and the initial impact assessment.

Phase 3: The Final Report

No later than one month after the incident notification, you must submit a final report containing:

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

If the incident is still ongoing at the one-month mark, you must submit a progress report instead, followed by the final report within one month of the incident being handled.

National CSIRT Contacts: Italy and Spain

The NIS2 Directive requires each Member State to designate one or more CSIRTs responsible for receiving incident notifications. Here are the relevant contacts for Italy and Spain:

Country	Authority	Scope	Contact
Italy	ACN - Agenzia per la Cybersicurezza Nazionale	All NIS2 entities (CSIRT + competent authority)	[email protected] / acn.gov.it
Spain	INCIBE-CERT	Private sector entities, citizens	[email protected] / incibe.es
Spain	CCN-CERT (Centro Criptologico Nacional)	Public administration entities	ccn-cert.cni.es
Spain	ESPDEF-CERT	Defense sector	emad.defensa.gob.es

Italy: ACN Reporting Process

In Italy, the ACN serves as the single point of contact for NIS2 incident reporting. The D.Lgs. 138/2024 establishes that:

• All notifications must be submitted through the ACN's dedicated portal
• The ACN will acknowledge receipt and may request additional information
• For incidents involving personal data, the ACN will coordinate with the Garante per la Protezione dei Dati Personali
• The ACN provides technical assistance during incident handling when requested

Spain: INCIBE and CCN Reporting

Spain has a split model for incident reporting:

• INCIBE-CERT handles notifications from private sector entities, including SMEs and large companies
• CCN-CERT handles notifications from public administration entities and entities covered by the Esquema Nacional de Seguridad
• Both CSIRTs coordinate through Spain's national cybersecurity framework
• INCIBE provides a dedicated incident reporting portal and 24/7 hotline (017)

Building an Incident Reporting Process

Meeting NIS2's tight timelines requires preparation. Here is a practical framework for building an effective incident reporting process:

Step 1: Define Your Incident Classification Scheme

Create a clear classification system that maps security events to NIS2 significance criteria. Include specific examples relevant to your sector and services. Every member of your incident response team should be able to determine within 30 minutes whether an incident meets the significant threshold.

Step 2: Establish Notification Templates

Prepare templates for each reporting phase:

• Early Warning Template: Organization details, incident summary (2-3 sentences), malicious activity indicator (yes/no/unknown), cross-border impact indicator (yes/no/unknown), initial contact person
• 72-Hour Notification Template: Updated summary, severity classification, affected systems/services, number of affected users, initial IoCs, containment status, preliminary impact assessment
• Final Report Template: Complete incident timeline, root cause analysis, full impact assessment, remediation actions taken, lessons learned, preventive measures implemented

Step 3: Assign Roles and Escalation Paths

Designate specific individuals responsible for:

• Incident detection and initial triage (SOC analysts or IT security team)
• Significance determination (CISO or incident response lead)
• Notification submission (compliance officer or designated reporter)
• Management communication (CISO to board/management body)
• External communication (PR/communications team for public-facing incidents)

Step 4: Implement Detection and Alerting

You cannot report what you cannot detect. Ensure you have:

• 24/7 security monitoring -- either in-house or through a managed detection and response provider
• Automated alerting for indicators of significant incidents (ransomware execution, mass data exfiltration, DDoS attacks)
• Log aggregation and SIEM capabilities for rapid investigation
• Network detection and response (NDR) for identifying lateral movement

The ENISA NIS Investments 2023 report found that only 37% of entities subject to the original NIS Directive had a fully staffed 24/7 SOC. For organizations without round-the-clock monitoring, outsourcing to a managed security provider is often the most practical way to ensure timely incident detection and reporting.

Step 5: Test Through Exercises

Conduct tabletop exercises at least twice per year that simulate significant incidents and practice the full reporting timeline. Include scenarios such as:

• Ransomware attack discovered on a Friday evening (testing after-hours response)
• Supply chain compromise affecting multiple customers (testing cross-border notification)
• Data breach involving personal data (testing parallel NIS2 and GDPR notification)
• Insider threat with gradual data exfiltration (testing detection-to-awareness timing)

Common Pitfalls in Incident Reporting

Based on experience from the original NIS Directive and GDPR breach notification, here are the most common mistakes organizations make:

Pitfall	Consequence	Prevention
Waiting for complete information before early warning	Missed 24-hour deadline	Submit early warning with available information; update later
No after-hours reporting capability	Incidents discovered Friday night reported Monday	24/7 monitoring + on-call notification chain
Unclear significance criteria	Delayed classification and reporting	Pre-defined criteria with specific examples for your sector
No pre-built templates	Scrambling to compile information under pressure	Maintain ready-to-use templates for each reporting phase
Forgetting parallel GDPR notification	Separate GDPR violation and additional fines	Integrated process covering both NIS2 and GDPR obligations
No management body notification	Article 20 non-compliance; personal liability for directors	Include board notification in escalation procedures

NIS2 vs. GDPR: Parallel Reporting Obligations

Many cybersecurity incidents involve personal data, triggering both NIS2 and GDPR reporting requirements. Understanding the differences is critical:

Aspect	NIS2	GDPR
Trigger	Significant cybersecurity incident	Personal data breach
First deadline	24 hours (early warning)	72 hours (to DPA)
Report to	CSIRT / competent authority	Data Protection Authority
Individual notification	To affected service recipients	To affected data subjects (if high risk)
Final report	1 month	No formal final report requirement
Max fine (essential)	EUR 10M or 2% turnover	EUR 20M or 4% turnover

When an incident triggers both regimes, the NIS2 timeline is more aggressive (24 hours vs. 72 hours for the first notification). Organizations should design their processes to meet the NIS2 24-hour deadline first, then complete the GDPR notification within the separate 72-hour window.

Leveraging Incident Reporting for Improvement

Beyond compliance, NIS2's reporting framework creates an opportunity for systematic improvement. The final report's requirement for root cause analysis and mitigation measures forces organizations to conduct structured post-incident reviews. According to the Ponemon Institute's 2024 Cost of a Data Breach report, organizations with an incident response team that regularly tested their plan saved an average of USD 2.66 million per breach compared to those without.

Use each incident report as input for:

• Updating risk assessments and security policies
• Improving detection capabilities based on identified gaps
• Strengthening controls that failed during the incident
• Training staff on lessons learned
• Revising compliance programs to address identified weaknesses

Conclusion

NIS2's incident reporting requirements are among the most operationally demanding aspects of the Directive, but they serve a critical purpose: enabling rapid response, cross-border coordination, and systematic improvement of cybersecurity across the EU. The 24-hour early warning, 72-hour notification, and 1-month final report timeline is achievable with proper preparation -- pre-built templates, clear classification criteria, defined escalation paths, and 24/7 detection capabilities. Organizations that invest in building robust incident reporting processes will not only meet their compliance obligations but will also significantly improve their ability to detect, respond to, and recover from cybersecurity incidents. For organizations needing support, managed detection and response services combined with NIS2 compliance support can bridge the gap between current capabilities and regulatory requirements.