NIS2 24-Hour Incident Reporting: What Counts as ‘Significant’?

The Reporting Framework: Three Stages

Article 23 of NIS2^[1] establishes a tiered incident responsereporting obligation for both essential and important entities. A “significant incident” triggers a three-stage notification sequence with prescribed timelines and content requirements.

Stage 1: Early warning—submitted to the competent authority or CSIRT (in Italy, the ACN^[2]) within 24 hours of awareness. Must indicate whether the incident is suspected of being caused by unlawful or malicious acts and whether it could have cross-border impact. The purpose is rapid notification, not detailed analysis.

Stage 2: Incident notification—due within 72 hours. Must update the early warning with an initial assessment of severity, impact, indicators of compromise, and technical details. This gives the authority context to assess whether coordination actions or public warnings are warranted.

Stage 3: Final report—due within one month. Must contain a detailed incident description, root cause analysis, applied and ongoing mitigation measures, and cross-border impact assessment. If the incident is still ongoing, submit a progress report at one month and a final report within one month of conclusion.

Defining “Significant Incident”

Article 23(3) defines a significant incident as one that has caused or is capable of causing severe operational disruption or financial loss, or has affected or could affect other persons by causing considerable material or non-material damage.

This operates on both actual-harm and potential-harm bases. An incident need not have caused disruption—“capable of causing” is sufficient, requiring entities to assess what could happen if countermeasures fail. The European Commission's implementing guidance considers: number of users affected, incident duration, geographic spread, extent of service disruption, economic and societal impact, and materiality of financial loss relative to entity size.

What Does and Does Not Qualify

Typically Significant

A ransomware attack halting service delivery qualifies regardless of ransom payment or backup recovery—the operational disruption and potential data exfiltration meet both criteria. A data breach exposing financial, health, or identity data is significant due to potential harm to individuals. A supply chain compromise introducing malicious code qualifies even without observed exploitation, due to potential for severe disruption. APT intrusions with persistent access, and sustained DDoS attacks degrading availability beyond defined thresholds, also meet the bar.

Typically Not Significant

A phishing email received but not acted upon is not an incident. Vulnerability scans revealing unpatched systems require remediation but are not incidents unless exploitation has occurred. A brief, auto-mitigated DDoS attempt with no measurable service degradation falls below the threshold. An isolated malware detection on a single endpoint, contained by automated controls without lateral movement, generally does not qualify—though subsequent investigation may reveal a broader compromise, restarting the clock.

The 24-Hour Clock: When Does It Start?

The trigger is awareness, not occurrence. The clock starts when personnel responsible for security have sufficient information to reasonably conclude a significant incident has occurred. If a SOC detects anomalous activity at 02:00 but the on-call analyst confirms significance at 08:00, the clock begins at 08:00.

Entities cannot use deliberate triage delays to extend the window. If processes artificially delay awareness, the competent authority may determine awareness should have occurred earlier. For PE portfolio companies relying on MSSPs, escalation delays do not excuse late notification—the entity remains responsible regardless of whether its MSSP meets escalation commitments.

Cross-Border Notification

When a significant incident has or may have cross-border impact, entities must indicate this in the early warning. The national CSIRT then notifies counterparts in affected member states. For entities operating across multiple European Union jurisdictions—common for Private Equityportfolio companies—primary jurisdiction is where cybersecurity risk-management decisions are predominantly taken.

Cross-border preparedness requires identifying your primary contact authority in advance, establishing communication channels, and understanding each jurisdiction's notification procedures. For PE funds with multi-country portfolios, a centralised incident coordination function ensures consistency while respecting entity-level obligations.

Practical Implementation

Compliant incident reporting requires three capabilities. Detection and triage processes must identify significant incidents promptly with clear escalation paths and a significance assessment checklist aligned with Article 23 criteria. Notification procedures need pre-drafted early warning templates covering: incident nature, detection time, awareness time, malicious activity assessment, and cross-border impact. Test these through tabletop exercises simulating the 24-hour process.

Documentation throughout the reporting cycle is essential. Every stage—detection, triage, significance assessment, notification, follow-up—should be logged with timestamps, responsible personnel, and decision rationale. This provides the evidentiary basis for regulatory inquiries and post-incident improvement.

Note the intersection with GDPR^[3] breach notification underArticle 33. A cyber incident involving personal data may trigger parallel obligations with different authorities, timelines (72 hours for GDPR, 24 hours for NIS2), and content requirements. Map these parallel obligations and establish coordinated workflows.

For PE portfolio companies and Family Offices-controlled entities, the 24-hour timeline does not allow ad hoc improvisation. Standing procedures, trained personnel, and tested communication channels must be in place before an incident occurs.