NIS2 Incident Reporting: Timelines, Thresholds, and CSIRT Coordination

Not every security event triggers NIS2 reporting obligations. Article 23(3) defines a significant incident as one that: (a) has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned, or (b) has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage.

This threshold is intentionally broad — the use of 'capable of causing' means that incidents with potential impact trigger reporting even if the actual damage has been contained. The assessment is based on reasonable professional judgement at the time of detection, not on hindsight analysis.

The European Commission may adopt implementing acts further specifying what constitutes a significant incident for specific entity types. Until such acts are adopted, entities should develop internal incident classification criteria that map to the Art. 23(3) thresholds, considering: the number of users affected, the duration of the disruption, the geographic spread of the incident, the potential for cascading effects to other entities or sectors, and the sensitivity of data potentially compromised.

Entities should err on the side of reporting — the consequences of failing to report a significant incident are more severe than the administrative burden of reporting an incident that ultimately proves less impactful than initially assessed. The 24-hour early warning mechanism is designed precisely for situations where the full impact is not yet clear.

NIS2 establishes a structured four-stage reporting timeline under Article 23(4), each stage serving a distinct purpose in the notification lifecycle.

Stage 1 — Early Warning (within 24 hours): The entity must submit an early warning to the competent CSIRT or competent authority without undue delay and in any event within 24 hours of becoming aware of a significant incident. The early warning must indicate whether the significant incident is suspected of being caused by unlawful or malicious acts, and whether it could have a cross-border impact. This is deliberately a low-friction report — it does not require full analysis, just initial awareness sharing so that the CSIRT can begin coordination if needed.

Stage 2 — Incident Notification (within 72 hours): Within 72 hours of becoming aware of the significant incident, the entity must submit an incident notification that updates the early warning information and provides an initial assessment of the incident, including its severity and impact, and indicators of compromise where available. This is a more substantive report that should include technical details to enable the CSIRT to provide assistance and support threat intelligence sharing.

Stage 3 — Intermediate Report (on CSIRT request): Upon request of the CSIRT or competent authority, the entity must submit an intermediate report with relevant status updates. The timing is not fixed — it depends on when the authority requests information. This mechanism allows CSIRTs to obtain situation-specific information as the incident develops, particularly for prolonged or complex incidents.

Stage 4 — Final Report (within one month): Within one month of submitting the incident notification (Stage 2), the entity 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 likely triggered the incident, applied and ongoing mitigation measures, and where applicable the cross-border impact of the incident. If the incident is still ongoing at the one-month mark, the entity must submit a progress report at that point and a final report within one month of conclusion.

Failure to meet these timelines constitutes a compliance violation and can trigger enforcement action by the national competent authority.

The reporting relationship under NIS2 is not purely one-directional. CSIRTs (Computer Security Incident Response Teams) and competent authorities have reciprocal obligations to provide support to reporting entities.

Under Article 23(5), the CSIRT or competent authority must, within 24 hours of receiving the early warning, provide a response to the notifying entity including initial feedback on the incident and, upon the entity's request, guidance or operational advice on the implementation of possible mitigation measures. The CSIRT must also provide additional technical support if the entity requests it, coordinate with other CSIRTs if the incident has cross-border implications, and treat the information provided with appropriate confidentiality.

Article 23(6) allows the competent authority or CSIRT to inform the public about the incident or require the entity to do so, where public awareness is necessary to prevent or deal with the incident or is otherwise in the public interest. This creates a potential disclosure obligation beyond the private notification to authorities.

For entities operating across multiple member states, the reporting obligation is to the CSIRT or competent authority of the member state where the entity has its main establishment. However, if the incident affects services in other member states, those member states' CSIRTs must be informed through the CSIRTs Network. The European Cyber Crises Liaison Organisation Network (EU-CyCLONe) coordinates at the EU level for large-scale cross-border incidents.

Entities should establish a pre-incident relationship with their relevant CSIRT — do not wait for an actual incident to identify the correct reporting channel, understand the expected format, and establish communication procedures.

NIS2 places particular emphasis on cross-border incident management, reflecting the reality that significant cyber incidents rarely respect national boundaries.

When a significant incident has cross-border impact — affecting network and information systems or services in more than one member state — the reporting entity's CSIRT must share relevant information with affected member states' CSIRTs through the CSIRTs Network established under Article 15. The single point of contact in the entity's member state must also notify the single points of contact of other affected member states.

The EU-CyCLONe network (Article 16) operates at a strategic level, supporting coordinated management of large-scale cybersecurity incidents and crises at the EU level. It exchanges information between member state cybersecurity crisis management authorities, discusses national cybersecurity incident response strategies, assesses the consequences and impact of relevant incidents, and coordinates public communications.

For entities providing services across the EU, the practical implication is clear: an incident affecting your services in multiple member states will involve multiple national authorities. Pre-establishing cross-border incident communication procedures and understanding the involvement of EU-CyCLONe for large-scale events is essential for effective incident management.

Article 30 allows entities to notify significant incidents, cyber threats, and near misses on a voluntary basis, even if they do not meet the mandatory reporting thresholds. This applies to both in-scope entities (for sub-threshold events) and entities not covered by the Directive.

Voluntary notifications are processed by the CSIRT in the same manner as mandatory notifications, but the CSIRT may prioritise mandatory notifications over voluntary ones. Voluntary reporting serves two purposes: it enriches the EU's collective threat intelligence picture, and it allows entities to benefit from CSIRT guidance and support even for incidents below the mandatory threshold.

Member states must ensure that voluntary reporting does not result in additional obligations for the notifying entity. This is an important protection — entities should not be deterred from voluntary reporting by fear of triggering regulatory scrutiny. The information provided through voluntary notifications is subject to the same confidentiality protections as mandatory notifications.