NIS2 incident reporting: the 24-hour, 72-hour and one-month duties

Who Article 23 reaches

The duty falls on essential and important entities. Article 2(1) puts an entity in scope where it is of a type listed in Annex I or II and qualifies as a medium-sized enterprise or larger under Recommendation 2003/361/EC, and where it provides its services or carries out its activities in the Union. Article 2(2) then overrides the size cap for a set of entities that are in scope regardless of how small they are: providers of public electronic communications networks and publicly available electronic communications services, trust service providers, top-level domain name registries and DNS service providers, the sole provider in a Member State of a service essential to critical societal or economic activity, entities whose disruption could significantly affect public safety, security or health or induce systemic risk, and certain public administration entities. Article 2(3) adds every entity identified as a critical entity under Directive (EU) 2022/2557, and Article 2(4) adds every provider of domain name registration services.

Article 3 then sorts those entities into two boxes. Essential entities are the Annex I types above the medium-sized ceiling, plus qualified trust service providers, TLD name registries and DNS service providers regardless of size, medium-sized providers of public electronic communications networks or services, certain public administration entities, entities a Member State has designated essential, and critical entities under the CER Directive. Everything else in Annex I or II that is in scope is an important entity.

Jurisdiction is settled by Article 26. As a rule you fall under the Member State where you are established. Electronic communications providers instead fall under the Member State where they provide the service. DNS providers, TLD registries, domain registration services, cloud computing providers, data centre providers, content delivery network providers, managed service providers, managed security service providers, online marketplaces, online search engines and social networking platforms fall under the Member State of their main establishment in the Union, which Article 26(2) defines as the Member State where decisions on cybersecurity risk-management measures are predominantly taken, failing that where cybersecurity operations are carried out, and failing that where the entity has its largest EU workforce. A provider in that group with no EU establishment must designate an EU representative.

What counts as a significant incident

The chain starts only for a significant incident, and Article 23(3) defines that in two alternatives. 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. Either limb is enough.

Note how far forward the test reaches. "Is capable of causing" means the assessment is about potential, not about realised harm, so an intrusion contained before it disrupted anything can still be significant. Note also that the second limb points outward: damage to your customers, to their customers, or to individuals is a trigger even where your own operations never wavered.

For most sectors that abstract test is all there is, elaborated by whatever your national transposition adds. For one group of entities the Commission has replaced it with numbers.

The numbers, if you run digital infrastructure

Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 was adopted under Articles 21(5) and 23(11) of the Directive. It applies to DNS service providers, TLD name registries, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers, managed security service providers, providers of online marketplaces, of online search engines and of social networking services platforms, and trust service providers. For those entities it says exactly when an incident is significant.

Article 3(1) sets horizontal triggers that apply to all of them. An incident is significant where it has caused or is capable of causing direct financial loss exceeding EUR 500 000 or 5 per cent of total annual turnover in the preceding financial year, whichever is lower; where it has caused or can cause the exfiltration of the entity's trade secrets; where it has caused or can cause the death of a natural person or considerable damage to a natural person's health; or where a successful, suspectedly malicious and unauthorised access to network and information systems occurred that is capable of causing severe operational disruption. Article 3(2) excludes scheduled interruptions and the planned consequences of scheduled maintenance. Article 4 aggregates recurring incidents: two or more within six months with the same apparent root cause count as one significant incident where they collectively meet the financial-loss threshold.

Then come the sector numbers, and they are tighter than most operators expect.

Two of those numbers deserve a second look. Thirty minutes of complete unavailability is inside the window in which most operations teams are still deciding whether they have an incident at all. And "a successful, suspectedly malicious and unauthorised access capable of causing severe operational disruption" makes a contained intrusion reportable on its own, with no outage required.

The four filings, and what each one has to contain

Article 23(4) sets out the chain. Every deadline in it runs from the same moment: becoming aware of the significant incident.

The early warning is the filing organizations get wrong most often, and they get it wrong by over-preparing. Read what point (a) asks for: whether malice is suspected, and whether there could be cross-border impact. That is a flag, not a report. You can file it while the forensics are still running, and the whole design of the chain assumes you will.

The 72-hour notification is where an initial assessment appears, and the word "initial" is doing real work. Severity and impact as you currently understand them, with indicators of compromise "where available". Nothing in point (b) demands that root cause be settled; that belongs to the final report a month later.

There is no scheduled intermediate report under NIS2. Point (c) exists only so the CSIRT can ask, which is a meaningful difference from the DORA chain, where the intermediate report is fixed at 72 hours after the initial notification whether or not anything has changed.

The second audience nobody plans for

Article 23 obliges you toward two different audiences and only one of them is an authority. The first subparagraph of Article 23(1) requires an entity to notify, without undue delay, the recipients of its services of significant incidents that are likely to adversely affect the provision of those services. That is a separate duty on a separate trigger, and it is not discharged by filing with the CSIRT.

Article 23(2) adds a further one for threats rather than incidents. Where a significant cyber threat exists, Member States must ensure that entities communicate, without undue delay, to the recipients of their services that are potentially affected any measures or remedies those recipients are able to take in response, and where appropriate inform them of the threat itself.

Both of these are customer communications with legal weight, written under time pressure, usually by the same three people already handling the CSIRT filing. Drafting the templates before you need them is the cheapest preparation available in this whole subject.

Where the notification goes, and why that is a national question

Article 23(1) says the entity notifies "its CSIRT or, where applicable, its competent authority". The Directive genuinely offers the Member State that choice, and Member States have taken it differently. Where the competent authority is the recipient, the second subparagraph requires the Member State to ensure the authority forwards the notification to the CSIRT on receipt. For a cross-border or cross-sectoral significant incident, the third subparagraph requires the single points of contact to be given the relevant information in due time.

Two worked examples show how much this varies. In Latvia, Article 34 of the Nacionālās kiberdrošības likums routes reports to the competent cyber incident response institution; Article 9(2) makes that the Institute of Mathematics and Computer Science of the University of Latvia, which operates CERT.LV, for state and local government institutions and for private legal persons, and the Military Intelligence and Security Service for defence bodies. Latvia also adds a duty the Directive does not contain: Article 34(1) requires an entity that detects any cyber incident, significant or not, to inform the competent incident response institution immediately and follow its instructions. Article 34(2) to (5), which carry the 24-hour, 72-hour and one-month chain, have applied since 1 July 2025.

In Finland, sections 11 to 13 of Kyberturvallisuuslaki 124/2025 route the notification to the sector supervisory authority rather than to the CSIRT, and section 17 then obliges that supervisor to pass it to the CSIRT unit immediately. The hours match the Directive: 24 for the initial notification, 72 for the follow-up, 24 for a trust service provider whose trust services are affected, and one month for the final report. Section 33 adds a Finnish specialty: the supervisory authority itself must notify the Data Protection Ombudsman where it learns that a failure of the risk-management duties may lead or has led to a personal data breach notifiable under GDPR Article 33.

A group operating in both countries has two different first phone calls for the same class of event, and a national addition in Latvia that no group-level playbook written from the Directive would contain. The comparison on the home page sets both out side by side.

What comes back, and how quickly

The obligation is not one-way. Article 23(5) requires the CSIRT or competent authority to respond without undue delay, and where possible within 24 hours of receiving the early warning, with initial feedback on the incident and, at the entity's request, guidance or operational advice on implementing mitigation measures. Where the CSIRT was not the original recipient, the guidance comes from the competent authority in cooperation with the CSIRT. The CSIRT must provide additional technical support if the entity asks. Where the incident is suspected to be criminal, the recipient must also give guidance on reporting it to law enforcement.

That response is a resource most entities never use, largely because they file the early warning as late as they dare and so receive the feedback when it is no longer actionable. Filing at hour four rather than hour twenty-three buys you a national CSIRT's view of whether anyone else is seeing the same thing.

Where NIS2 stops

Article 4 is the provision that decides whether you are in this chain at all. Where a sector-specific Union legal act requires essential or important entities to adopt cybersecurity risk-management measures or to notify significant incidents, and those requirements are at least equivalent in effect, Article 4(1) disapplies the relevant provisions of the Directive, including the supervision and enforcement provisions in Chapter VII. Article 4(2) defines equivalence: either the risk-management measures are at least equivalent to Article 21(1) and (2), or the sectoral act gives the NIS2 CSIRTs, competent authorities or single points of contact immediate, and where appropriate automatic and direct, access to the incident notifications and its notification requirements are at least equivalent to Article 23(1) to (6).

One act has expressly claimed that status. DORA Article 1(2) declares itself a sector-specific Union legal act for the purposes of NIS2 Article 4 in relation to financial entities identified as essential or important. A bank therefore does not run a parallel Article 23 chain: it runs the DORA chain and its financial supervisor routes the details to the NIS2 CSIRT under DORA Article 19(6)(c).

Nothing displaces the GDPR. Article 2(12) of the Directive states that it applies without prejudice to Regulation (EU) 2016/679, so where personal data are involved the Article 33 clock runs in addition, to a different authority. And Article 35(1) closes the loop between the two regimes: where a competent authority becomes aware in supervision or enforcement that an infringement of Article 21 or 23 can entail a notifiable personal data breach, it must inform the GDPR supervisory authority without undue delay. Article 35(2) then prevents double punishment for the same conduct, but only for administrative fines.

If you also place a connected product on the EU market, Cyber Resilience Act Article 14 adds a clock that runs to different recipients entirely, and it has applied since 11 September 2026.

Building the plan around hour 24

Three practical conclusions follow from reading the article rather than a summary of it.

• The binding constraint is the 24-hour mark, not the 72-hour one. If you made the early warning, the notification is a rewrite of it with an assessment attached, and the final report has a month.
• Nothing at hour 24 requires certainty. Point (a) asks for two yes-or-no judgments. Draft the early warning template now, get it approved now, and reduce the hour-24 task to filling in three fields and pressing send.
• "Becoming aware" is the only variable you control. Every clock in this article starts there, so detection capability is the deadline. An entity that first learns of an intrusion from a customer, a journalist or a national CSIRT has already spent the whole of its margin before the first filing exists.

The reporting clock finder will lay the Article 23 chain out against whatever else applies to your situation, including the duties from the other three regimes that most Article 23 checklists leave out.