NIS2 Article 23 incident notification

An incident is significant under Article 23 when it has caused or is capable of causing severe operational disruption of the entity's services or financial loss for the entity, or considerable material or non-material damage to another natural or legal person. Record actual and capable effects; an incident, loss, or third-party impact is not automatically significant merely because it exists.

The trigger record should capture the service affected, the time the entity became aware, the expected or actual disruption, affected recipients or third parties, financial-loss indicators, material or non-material damage indicators, and whether the incident may have cross-border impact. If the facts are still incomplete, record the uncertainty and update the assessment as the incident response team learns more.

For the provider types named in Regulation (EU) 2024/2690, an incident is significant if any horizontal criterion or applicable provider-specific criterion is met. Horizontal triggers include direct financial loss above EUR 500,000 or 5% of the preceding financial year's total turnover, whichever is lower; actual or capable exfiltration of the entity's trade secrets; actual or capable death or considerable health damage; and successful, suspectedly malicious unauthorised access capable of causing severe operational disruption.

Calculate direct financial loss from incident costs such as replacement or relocation, extra staff and overtime, contractual redress, compensation, forgone revenue, communications, legal advice, forensics, and remediation. Do not include administrative fines, ordinary operating costs, general maintenance, insurance premiums, or post-incident improvements. Use available data and estimate where the actual amount is not yet known.

The Regulation also aggregates recurring incidents when they occur at least twice within six months, share the same apparent root cause, and collectively meet the financial-loss criterion. Provider-specific examples include complete unavailability for more than 30 minutes for a cloud, CDN, managed, or managed-security service; limited availability for more than one hour affecting more than 5% of Union users or more than 1 million Union users, whichever is smaller, for those services; and complete unavailability of a trust service for more than 20 minutes. Scheduled interruptions and planned consequences of scheduled maintenance are excluded from its significance criteria. Other sectors must use Article 23, applicable national law, and any sector-specific thresholds; they should not import the Regulation's numeric tests as universal NIS2 rules.

Article 23 uses a staged reporting sequence. The early warning is due without undue delay and in any event within 24 hours of becoming aware of the significant incident. The incident notification is due without undue delay and in any event within 72 hours of awareness and should update the early warning with an initial severity and impact assessment and, where available, indicators of compromise.

After the 72-hour notification, be ready for intermediate reports when the CSIRT or competent authority requests status updates. The authority should respond without undue delay and, where possible, within 24 hours after receiving the early warning with initial feedback and, if requested, mitigation guidance or operational advice. The final report is due not later than one month after the incident notification. If the incident is still ongoing at that point, provide a progress report and then a final report within one month of handling the incident.

Authority reporting and recipient communication use different tests. Article 23 requires notification to the CSIRT or competent authority. Where appropriate, the entity must also notify recipients when a significant incident is likely to adversely affect the provision of its services.

Keep separate decision owners for authority reporting, recipient communications, law-enforcement escalation, and public disclosure. Article 23 also anticipates cross-border and cross-sector cases, where single points of contact and other affected Member States may need relevant information, while preserving the entity's security, commercial interests, and confidentiality.

The Article 23 file should show why the team treated the event as reportable or not reportable, what the entity knew at each reporting point, and how the submission changed as the investigation and mitigation progressed. Incident responders should be able to use it during the event, and management, auditors, and regulators should be able to review it afterward.

For entities covered by Commission Implementing Regulation (EU) 2024/2690, align the notification file with incident-handling evidence such as incident classification, escalation records, logs, root-cause work, mitigation decisions, post-incident review, and management-body updates. ENISA guidance for that regulation describes practical advice and examples of evidence for cybersecurity requirements.

Review this checklist before an incident to make Article 23 operational and during an incident to keep the reporting record complete. Do not wait for complete forensic certainty. Report the required information on time, distinguish facts from estimates, and update the record as the investigation develops.

Trust service providers need separate handling for significant incidents affecting trust services because Article 23 sets a 24-hour notification derogation for that case. Other sector-specific Union laws may also change which NIS2 provisions apply when their incident-notification requirements are at least equivalent in effect.