NIS2 incident reporting: the 24-hour early warning, the 72-hour notification and what to prepare

NIS2 reporting deadlines: 24 hours, 72 hours and one month

Article 23 of the NIS2 Directive, (EU) 2022/2555, requires an essential or important entity to report a significant incident to its CSIRT or, where applicable, its competent authority in stages. An early warning is due within 24 hours of becoming aware of it and an incident notification within 72 hours. A final report is due not later than one month after the incident notification. Both hour figures are outer limits, since the reports are due “without undue delay and in any event within” them. Trust service providers have 24 hours for the incident notification when their trust services are affected.

Directive (EU) 2022/2555, Article 23(4), on eur-lex.europa.eu (CELEX 32022L2555).

The Directive is addressed to the Member States, so the duty reaches a company through the national law that transposes Article 23. The recipient is that Member State’s CSIRT or competent authority. Whether your company is an essential or important entity, and which national law applies to it, is a legal assessment for your legal department.

Article 34 requires Member States to apply the same fine ceilings to infringements of Article 23 as of Article 21. For essential entities the ceiling is at least EUR 10 million or 2 per cent of the total worldwide annual turnover in the preceding financial year, whichever is higher. The turnover is that of the undertaking to which the entity belongs. For important entities the figures are EUR 7 million or 1.4 per cent. Under Article 23(1), “The mere act of notification shall not subject the notifying entity to increased liability.” Our guide to the NIS2 Article 21 measures covers incident handling as a risk-management measure, Article 21(2)(b).

What counts as a significant incident under NIS2

In the Directive’s definition (Article 6(6)), an incident is an event compromising the availability, authenticity, integrity or confidentiality of data, or of the services offered by or accessible via network and information systems. Article 23(3) makes it significant if it has caused or is capable of causing severe operational disruption of the services or financial loss for the entity. The same applies to considerable material or non-material damage to other natural or legal persons. Because of the words “capable of causing”, an incident can be significant before the damage occurs.

Recital 101 leaves the initial assessment to the entity. The recital names indicators such as “the extent to which the functioning of the service is affected, the duration of an incident or the number of affected recipients of services”. Under Article 23(11) the Commission set criteria for digital providers in Implementing Regulation (EU) 2024/2690. The Commission may do so for other sectors, and as of 6 October 2026 we found no such act.

Significant incident thresholds in Implementing Regulation 2024/2690

The regulation of 17 October 2024 binds only the entities in its Article 1. These are DNS service providers, TLD name registries, cloud computing, data centre and CDN providers, managed service providers (MSPs), managed security service providers (MSSPs), online marketplaces, search engines, social networking platforms and trust service providers. One criterion is enough, and Articles 5 to 14 add type-specific criteria that the table leaves out. These include slow DNS responses, any complete outage of a TLD registry’s name resolution or a data centre service, and the 20-minute limit for trust services. Each provider should therefore read its own article.

Commission Implementing Regulation (EU) 2024/2690, Articles 1, 3 to 5 and 7 to 14, on eur-lex.europa.eu (CELEX 32024R2690).

Recital 36 counts replacement of systems, staff costs, fees for breached contracts, compensation to customers, forgone revenue and advisory costs as direct financial loss. It does not count administrative fines, running costs, later upgrades or insurance premiums. Amounts that cannot be determined should be estimated. Under recital 39, an intrusion in which a threat actor pre-positions in the network “with a view to causing disruption of services in the future” should be considered significant.

The regulation does not bind a manufacturer, an energy company or any other entity outside Article 1. Such a company can base its predefined criteria on Article 3, unless the rules that apply to it set figures of their own.

When the 24-hour clock starts and who decides

The deadlines run from becoming aware of the significant incident, a moment the Directive does not define. Recital 31 of the implementing regulation, written for the providers it covers, asks for a suspicious event, including one reported by a third party, to be assessed “in a timely manner”. It then states: “The relevant entity is therefore to be regarded as having become ‘aware’ of the significant incident when, after such initial assessment, that entity has a reasonable degree of certainty that a significant incident has occurred.”

For those providers, Annex point 3.4.2 requires that assessment to be “based on predefined criteria laid down in advance”. The same point requires triage, log correlation and reassessment as information arrives. Recital 102 of NIS2 limits the early warning to “the information necessary to make the CSIRT, or where applicable the competent authority, aware of the significant incident and allow the entity concerned to seek assistance, if required”.

1. Record the time of the first alert or third-party report and who received it.
2. Triage the event against the predefined criteria, using the logs that confirm or rule out an incident.
3. Have the named decision-maker or a deputy classify it and record the time, the criteria met and the evidence.
4. For a significant incident, send the early warning without undue delay and at the latest 24 hours after becoming aware. In it, say whether malicious acts are suspected and whether other Member States could be affected.
5. Reassess as findings arrive and carry them into the incident notification.

Both timestamps belong in the incident log, kept with the evidence (Annex point 3.5.4). Roles, playbooks and exercises are covered in our guide to what an incident response plan must contain.

An incident response plan with roles, actions and deadlines is part of our cyber resilience service. Tell us who decides today whether an incident is reported and how that decision is recorded.

Logs and detection that the reports depend on

Annex point 3.2.3 lists what logs should include where appropriate. Among them are network traffic, authentication events, all privileged access and the activities of administrative accounts. The list also includes access or changes to critical configuration and backup files, logs from security tools, and the activation, stopping and pausing of logs. Point 3.2.6 calls for synchronised time sources, and point 3.2.5 requires logs kept and backed up for a predefined period and protected from unauthorised access or changes.

An intruder with administrator rights can stop or delete the logs on the systems they control. The final report therefore depends on a copy kept outside those systems, for long enough to cover the time before detection. Point 3.2.4 requires that an alarm is followed by “a qualified and appropriate response” in a timely manner. This raises the question of who receives alarms at night and at weekends. Our article on EDR, XDR, SIEM and MDR compares the tools and who watches them.

Event centralisation in a SIEM is part of our cyber resilience service, on Trend Micro, Cisco and other vendors’ solutions. Describe which systems send logs to a central place today in the form below.

Notifying customers and other recipients of your services

Article 23(1) requires entities to notify the recipients of their services, without undue delay and where appropriate, of significant incidents likely to adversely affect those services. Article 23(2) requires entities, where applicable, to tell recipients potentially affected by a significant cyber threat what measures or remedies they can take. Customers bound by the implementing regulation also put an incident notification duty into supplier contracts where appropriate (Annex point 5.1.4(d)), as our article on NIS2 supplier requirements explains.

GDPR Article 33 and DORA alongside NIS2

NIS2 applies “without prejudice to” the GDPR (Article 2(12)), so a personal data breach is reported separately. Article 33(1) of the GDPR requires the controller to notify the supervisory authority “without undue delay and, where feasible, not later than 72 hours after having become aware of it”. This applies unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. A notification made after 72 hours must give reasons for the delay. The notification covers the nature of the breach, approximate numbers of data subjects and records where possible, and a contact point. It also covers likely consequences and measures taken or proposed, and may follow in phases (Article 33(3) and (4)).

The two clocks can start at different moments, since the GDPR counts from awareness of a personal data breach and NIS2 from awareness of a significant incident. A ransomware attack that stops services and copies personal data can trigger both, with different recipients and content. The technical order of work is in our guide to ransomware recovery in the first 72 hours.

Financial entities covered by DORA, Regulation (EU) 2022/2554, report major ICT-related incidents under that regulation. In the words of recital 28 of NIS2, DORA’s provisions “should apply instead of those provided for in this Directive”.

Report fields to prepare before an incident

On 26 May 2026 the NIS Cooperation Group of Member States, Commission and ENISA agreed common templates for incident reporting. The Commission’s announcement says it “plans to adopt these templates through an implementing act, making them mandatory for all Member States”. The announcement does not include the templates. As of 6 October 2026 we found no implementing act on the format of notifications, so the receiving CSIRT or authority’s own form applies.

Directive (EU) 2022/2555, Article 23(4); GDPR Article 33(3); Implementing Regulation (EU) 2024/2690, Annex points 3.1 to 3.5. The preparation column is our recommendation.

The Annex counts contact lists and templates among the documents for incident response (point 3.1.2(d)). Keep pre-approved drafts of the early warning and the notification with named contacts, deputies and phone numbers, where they can be reached when email and file servers are down.

General information on EU law as of October 2026, not legal advice for an individual case.

What we do

Under our Cyber Resilience service, our engineering partner Vixen.UNO writes an incident response plan with roles, actions and deadlines, including the regulatory reporting deadlines. Firewalls, EDR/XDR on workstations and servers and a SIEM are part of the same service. The technical assessment gives you a risk map and a prioritised action plan. The NIS2 compliance map lists the gaps with a plan to close them, as a technical assessment rather than a legal opinion. The first call is free of charge, and an active incident is handled separately: write to us straight away.

FAQ