Guides

NIS2 Guide · 7 min

NIS2 incident reporting: the 24- and 72-hour deadlines explained

When a significant incident hits, the clock starts immediately — and NIS2 sets a sequence of hard deadlines measured in hours, not days. This guide explains what counts as a significant incident, the exact reporting timeline under Article 23, and the situation teams most often miss: when a supplier's incident becomes your reporting obligation.

Key takeaways

  • A significant incident triggers a staged report: early warning within 24 hours, full notification within 72 hours, final report within one month (Art. 23).
  • 'Significant' means severe operational disruption or financial loss, or considerable damage to others — not every incident qualifies.
  • A supplier or third-party incident that disrupts your service can start your 24-hour clock — visibility into them is part of readiness.
  • Reports go to your national CSIRT or competent authority; you may also have to inform the recipients of your services.

What counts as a 'significant' incident

Not every incident is reportable. Under Article 23, 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, or if it has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage.

The Commission has set more concrete thresholds for certain digital providers in an implementing regulation, but the principle holds across sectors: judge by the severity and reach of the impact, not by the technical novelty of the attack. When in doubt, document your assessment — the decision not to report should be as defensible as the decision to report.

The reporting timeline (Article 23)

Reporting is staged: a fast signal first, detail later. The deadlines run from the moment you become aware of the significant incident.

Within 24 hours — early warning

A first alert to your CSIRT or competent authority, indicating whether the incident is suspected to be caused by unlawful or malicious acts, or could have a cross-border impact.

Within 72 hours — incident notification

An update with an initial assessment: severity and impact, and indicators of compromise where available.

On request — intermediate report

If the CSIRT or authority asks, a status update on the handling of the incident.

Within 1 month of the notification — final report

A detailed description: root cause and type of threat, the mitigations applied and ongoing, and any cross-border impact.

If the incident is still ongoing at the one-month mark, you submit a progress report instead, and the final report within one month of the incident being handled.

When someone else's incident becomes yours

NIS2's reporting duty is not limited to incidents that originate in your own systems. If a supplier or service provider suffers an incident that causes a significant disruption to the services you provide, the obligation to report can fall on you — and the 24-hour clock starts when you become aware, not when the supplier finally tells you.

That is the hard part: suppliers do not always disclose incidents quickly, and a notification that arrives a week late has already burned your deadline. Readiness therefore depends on independent visibility — knowing when a critical supplier appears on a ransomware leak site, has credentials dumped, or goes dark, without waiting for their email.

How to be ready before the clock starts

Meeting an hours-long deadline is an exercise in preparation, not heroics. Before an incident, make sure you can answer:

Who decides whether an incident is 'significant', and who can reach the CSIRT outside office hours?
Do we have the CSIRT/authority contact and submission channel ready — not looked up mid-crisis?
Are supplier incident-notification clauses in our contracts, with a defined notification window?
Do we have independent monitoring of critical suppliers, so we are not blind to an incident they have not disclosed?
Can we produce the timeline and evidence a final report needs — what happened, when, and what we did?

Source: Directive (EU) 2022/2555 (NIS2), Article 23 — plus the Commission implementing regulation on significant-incident thresholds for certain digital providers; check your national CSIRT's reporting portal for the exact channel.

How norppa.io helps

The hardest part of the timeline is the part you do not control: a supplier incident you find out about too late. norppa.io monitors your suppliers continuously — ransomware-victim listings and dark-web credential leaks are checked roughly every six hours, with an immediate alert — so a supplier event reaches you in time to start your own clock.

And because every finding is timestamped and mapped to NIS2 articles, the history you need for a 72-hour notification or a one-month final report — what was seen, when, and what was done — is already assembled rather than reconstructed under pressure.

Don't learn about a supplier incident too late

See how continuous supplier monitoring surfaces ransomware and leaks within hours — in the sample report.

View sample report

Related guides

NIS2 and the supply chain requirement — what it means in practice

NIS2 requires significant and important entities to assess their supply chain cyber risks. Supplier tiering, 4th-party risk, Art. 23 notification, and what auditors look for.

NIS2 Art. 21(2) — supplier security checklist

Checklist for procurement and security teams: what to ask, what evidence to collect, and how to respond when a supplier falls short. Includes suggested evidence documents.

Supplier cyber risk assessment: what automated NIS2 monitoring checks

All check categories explained: ransomware, dark web leaks, TLS/DNSSEC, cookie security, CVE/EPSS, sanctions, MX blacklists and SAQ. Finding lifecycle and NIS2 article mapping.

Who is in scope for NIS2? Essential vs important entities, sectors and size thresholds

Determine whether NIS2 applies to you: the two tiers, the Annex I/II sectors, the size thresholds, size-independent exceptions, and how the supply chain pulls you in even if you're not designated.

NIS2 supplier questionnaire (SAQ): what to ask, how to score it, and a free template

What to ask suppliers under Art. 21(2)(d), how to score answers and respond to gaps, why self-attestation needs verification, and a free copy-paste questionnaire template.

NIS2 vs DORA: how they differ, where they overlap, and which one applies to you

How the two EU regimes differ and overlap, why DORA is lex specialis for financial entities, which applies to you, and what both mean for third-party and supply-chain risk.

NIS2 and management responsibility: what boards and leadership must know

What NIS2 expects of the management body: approval and oversight duties, personal liability (Art. 20), training, board reporting KPIs, and the penalties under Art. 34.

ISO 27001 and NIS2: what your ISMS already covers — and the gaps it doesn't

If you hold ISO 27001, what carries over to NIS2 and what does not: statutory incident reporting, management liability, registration, and continuous supply-chain assurance — plus how to close the gap.