Back to Knowledge Base
Knowledge Base · post-launch

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

20 May 2026 7 min read NIS2

NIS2 Article 23 requires essential and important entities to report a significant incident in three stages: an early warning within 24 hours of becoming aware of it, an incident notification within 72 hours, and a final report within one month of the notificat

The short answer

NIS2 Article 23 requires essential and important entities to report a **significant incident** in three stages: an **early warning within 24 hours** of becoming aware of it, an **incident notification within 72 hours**, and a **final report within one month** of the notification. Reports go to the CSIRT or, where applicable, the competent authority designated by your Member State.

The 24-hour clock does not start when the incident begins. It starts when the entity **becomes aware** of it. That distinction is where most of the budget is lost.

Who this applies to

Essential and important entities as defined in Annex I and Annex II of Directive (EU) 2022/2555, once transposed into your national law.

**One exception matters more than the rest.** Under NIS2 Article 4, where a sector-specific Union act imposes cybersecurity risk-management or incident-notification obligations at least equivalent in effect, that act applies instead. **For financial entities, DORA displaces NIS2 Article 23.** If you are in DORA scope, the sequence below is not the one that governs you — see which instrument applies when DORA and NIS2 both cover you.

What counts as a significant incident

Article 23(3) sets the threshold. An incident is significant if it satisfies either limb:

1. **It has caused or is capable of causing severe operational disruption of the services, or financial loss, for the entity concerned**; or 2. **It has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage.**

Two features of this definition drive practical decisions:

**"Is capable of causing" includes incidents with no realised impact yet.** A contained intrusion that could have disrupted service qualifies on its potential. Waiting to observe actual damage before starting the clock is a misreading, and a common one.

**The second limb points outward.** Damage to your customers or to third parties triggers the obligation independently of any harm to you. An entity that assesses significance purely on internal impact will under-report.

Member States and the Commission have issued implementing rules specifying thresholds for particular sector types. **Check the criteria that apply to your sector before writing your own** — the general definition is the floor, not the whole answer.

The three stages, and what each must contain

**Stage 1 — Early warning, within 24 hours**

Submitted without undue delay and in any event within 24 hours of becoming aware of the significant incident.

It must indicate whether the incident is suspected of being caused by **unlawful or malicious acts**, and whether it could have a **cross-border impact**.

This is deliberately minimal. It is a signal, not an analysis. The most common failure at this stage is treating it as a report — teams spend eighteen hours assembling detail that belongs in stage two, and file late.

**Stage 2 — Incident notification, within 72 hours**

Submitted without undue delay and in any event within 72 hours of becoming aware.

It updates the early warning, provides an **initial assessment of the significant incident, including its severity and impact**, and where available, the **indicators of compromise**.

The 72 hours run from awareness, **not from the early warning**. Filing the early warning at hour 23 does not give you 72 further hours; it leaves you 49.

**Stage 3 — Final report, within one month**

Submitted no later than one month after the incident notification. It must include:

**Intermediate reports and ongoing incidents**

Upon request from the CSIRT or competent authority, an entity must provide **status updates**. Where the incident is still ongoing at the one-month point, the entity submits a **progress report** at that time and a **final report within one month of handling the incident**.

  • a **detailed description** of the incident, its severity and impact;
  • the **type of threat or root cause** that likely triggered it;
  • the **mitigation measures applied and ongoing**;
  • where applicable, the **cross-border impact**.

Two obligations that are not the notification itself

**Recipients of your service (Article 23(1)).** Where appropriate, entities must notify without undue delay the recipients of their services who are potentially affected by a significant cyber threat, of any measures or remedies those recipients can take. This is a separate duty from the CSIRT report, with a different audience and a different purpose, and it is frequently missed by programmes focused only on the regulator.

**Public communication (Article 23(7)).** The CSIRT or competent authority may require the entity to inform the public, or may inform the public itself, where public awareness is necessary to prevent or handle the incident, or where disclosure is otherwise in the public interest.

The mistakes that cost hours

**Starting the clock at detection instead of at awareness.** These are not the same moment. Awareness is an organisational state, not a SOC alert. If an alert sits unread in a queue over a weekend, the regulator's view is unlikely to be that the clock had not started.

**Waiting for certainty.** The early warning explicitly accommodates uncertainty — it asks whether malicious cause is *suspected*. Holding it until root cause is confirmed inverts the design.

**Assessing significance on internal impact only.** The second limb of Article 23(3) concerns damage to others. Missing it produces systematic under-reporting.

**Assuming one report satisfies everything.** A single event can simultaneously trigger NIS2 Article 23, a GDPR Article 33 personal data breach notification within 72 hours to the supervisory authority, and CRA Article 14 if the entity also manufactures a product with digital elements. **Different recipients, different content, different legal bases.** They are not interchangeable, and one filing does not discharge the others.

**Not knowing who may file.** A regulatory notification within 24 hours requires a named person with authority to send it, and a deputy. Programmes that route this through a committee do not make the window.

**Treating a Directive as directly applicable.** NIS2 reaches you through your Member State's transposition. Reporting channels, formats and sometimes thresholds are national. The Article text tells you the shape; your national authority tells you the specifics.

What to have in place before the first incident

1. A **written trigger definition** for your sector, mapped to Article 23(3) and to any applicable implementing rules. 2. A **named filer and a named deputy**, with the authority to submit without escalation. 3. The **actual submission channel** of your national CSIRT, tested — not discovered during the incident. 4. A **24-hour template** already drafted, with only the incident-specific fields blank. 5. A **decision point at the top of the runbook** asking which instruments this event triggers — NIS2, GDPR, CRA, DORA — before anyone starts writing. 6. **Timestamped evidence retention** of every filing: what was sent, when, and to whom.

Tools available on NexCyber

Further reading

NIS2 implementation — a practical walkthroughNIS2 × CRA overlap — the six shared obligation areasDORA × NIS2 — which instrument governs when both applyOne evidence set across five EU regulationsNIS2 regulation overview

*This is regulatory information, not legal advice, and nothing here constitutes a compliance guarantee. NIS2 applies through national transposition and reporting thresholds, channels and formats vary by Member State. Confirm with your national CSIRT or competent authority.*

This is an educational explainer. For the canonical regulation reference, see the dedicated NIS2 page — or run an assessment to see how it applies to your product.