NIS2 incident reporting, step by step.

Where DORA covers finance, NIS2 reaches across the wider economy — and it carries its own reporting stopwatch. NIS2 incident reporting is the duty on essential and important entities to notify a significant incident to their CSIRT or competent authority in a strict 24-hour, 72-hour, one-month sequence. This guide covers what makes an incident significant, when each report is due, and who has to file. It is one piece of the broader discipline of cyber incident management.

Who NIS2 binds

NIS2 replaces the original NIS Directive and widens the net considerably. It sorts in-scope organizations into essential entities and important entities across a broad range of sectors — energy, transport, banking and financial market infrastructure, health, drinking and waste water, digital infrastructure, public administration, and space among the essential; and postal services, waste management, chemicals, food, manufacturing, and digital providers among the important, among others. The distinction mainly affects the intensity of supervision and the ceiling on penalties, not whether you have to report.

NIS2 also puts supply-chain security and incident response squarely on management's desk, with accountability that reaches the board. Polestead's model is sector-agnostic — it classifies vendors by your own exposure regardless of industry — which is the same discipline the NIS2 solution page describes for covering every significant supplier.

What counts as a significant incident

Only a significant incident triggers the reporting duty. Under NIS2 an incident is significant if it has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned, or if it has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage. The word to notice is capable: potential impact can qualify an incident, not only realized impact, so the classification judgement often has to be made while the situation is still unfolding.

The 24-hour, 72-hour, one-month sequence

As with DORA and GDPR, the clock runs from awareness of a significant incident, not from when the incident began. From that moment reporting to your CSIRT or competent authority runs in three stages:

1. Early warning — within 24 hours. A first flag indicating whether the incident is suspected to be caused by unlawful or malicious acts, and whether it could have cross-border impact.
2. Incident notification — within 72 hours. An update on the early warning with an initial assessment: severity, impact, and, where available, indicators of compromise.
3. Final report — within one month of the incident notification. A detailed description, the type of threat or root cause, the mitigation applied, and any cross-border impact.

There are two extra wrinkles worth knowing: the CSIRT can request an intermediate progress report between the 72-hour notification and the final report, and where the incident is still ongoing at the one-month mark, a progress report is filed then and the final report follows once the incident is handled. This is the EU baseline; national transposition varies. It's informational, not legal advice — verify the specifics that bind you with qualified counsel.

Who reports, and to whom

The obligation falls on the in-scope essential or important entity, reporting to the CSIRT (computer security incident response team) or the competent authority designated by its member state. Because NIS2 is a directive, the exact recipient, mechanism, and any national extras are set by each country's transposing law — one reason the practical detail varies more than under a directly applicable regulation like DORA. Entities may also be expected to inform the recipients of their services about significant incidents where appropriate, particularly where those recipients can take protective action.

NIS2 and DORA — the overlap

For organizations in the financial sector, NIS2 and DORA can both appear to apply. In practice DORA is the more specific regime for ICT risk management and incident reporting, and generally takes precedence for those entities, so a bank reports an ICT incident under DORA's clocks rather than twice. The mechanics of the DORA sequence are covered in DORA incident reporting, and the interaction between the two regimes — including the lex specialis point — in DORA vs NIS2.