Skip to content
AuditFront
Art.23.1 NIS2

NIS2 Art.23.1: Significant Incident Notification Obligation

What This Control Requires

Member States shall ensure that essential and important entities notify, without undue delay, their CSIRT or, where applicable, their competent authority of any significant incident. Where appropriate, those entities shall notify, without undue delay, the recipients of their services of significant incidents that are likely to adversely affect the provision of those services.

In Plain Language

When a significant incident hits, you are legally required to report it to your national CSIRT or competent authority without undue delay. This is mandatory, not optional, and failing to report carries real penalties. What counts as "significant" is defined in Art.23.3 - broadly, incidents that have caused or could cause severe operational disruption or financial loss, or that have affected or could affect other people or organisations by causing considerable damage. You need internal processes that can rapidly assess whether an incident crosses that threshold. There is also a customer-facing obligation. If a significant incident is likely to affect the services you provide, you must notify your service recipients too. This gives downstream organisations the chance to take their own protective measures. The notification needs to be timely, clear, and actionable.

How to Implement

Write an incident notification policy and procedure that spells out the criteria for classifying an incident as "significant" based on Art.23.3, the internal escalation path from detection to notification decision, your CSIRT or competent authority contact details, notification templates and formats, and who is responsible for preparing and submitting each notification. Build a rapid assessment process that can determine significance within the required timeframes. The early warning must go out within 24 hours of becoming aware of a significant incident, and the full notification within 72 hours. Train your incident response team on the criteria and the process. Prepare notification templates in advance. You need templates for the early warning (nature of the incident, suspected cause, cross-border impact), the full notification (initial assessment, severity, indicators of compromise, mitigation measures), and customer notifications (impact on services, recommended protective actions). Make notification a formal step in your incident response workflow rather than something people remember after the fact. Assign a specific role - incident commander or designated reporter - who owns the notification timeline. Build a relationship with your CSIRT and competent authority before anything goes wrong. Understand their reporting mechanisms, preferred formats, and communication channels. If your sector runs incident reporting exercises, participate. Keep a detailed log of all incident notifications with timestamps for awareness, assessment, and submission. This audit trail proves you met the "without undue delay" requirement. Review and refine your notification procedures regularly based on regulatory guidance, lessons from real notifications, and any changes to reporting requirements.

Evidence Your Auditor Will Request

  • Incident notification policy and procedures with defined significance criteria
  • Notification templates for early warning, full notification, and customer notification
  • CSIRT/competent authority contact details and established communication channels
  • Log of incident notifications with timestamps demonstrating timely reporting
  • Integration of notification steps in the incident response plan

Common Mistakes

  • No clear criteria for determining when an incident is 'significant' and requires reporting
  • Notification process not integrated into incident response workflow, causing delays
  • Legal or PR concerns cause deliberate delays in notification beyond required timeframes
  • Customer notification is overlooked or delayed when services are adversely affected
  • No pre-established relationship with CSIRT; first contact occurs during an active incident

Related Controls Across Frameworks

Framework Control ID Relationship
GDPR Art.33 Related
GDPR Art.34 Related
ISO 27001 A.5.24 Related

Frequently Asked Questions

What qualifies as a 'significant incident' under NIS2?
An incident is significant if it has caused or is capable of causing severe operational disruption or financial loss, or if it has affected or is capable of affecting other people or organisations by causing considerable material or non-material damage. Implementing acts may further specify these thresholds on a per-sector basis.
Can we be penalised for late notification even if we handled the incident well?
Yes. The notification obligation stands on its own, separate from the quality of your incident response. Even if you manage the technical response perfectly, failing to notify within the required timeframes is a separate infringement that can lead to enforcement action.

Track NIS2 compliance in one place

AuditFront helps you manage every NIS2 control, collect evidence, and stay audit-ready.

Start Free Assessment