Guides

NIS2 Guide · 7 min

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

When a significant incident lands, the clock starts at once, and NIS2 measures its deadlines in hours, not days. This guide sets out what counts as a significant incident, the exact reporting sequence under Article 23, and the case teams trip over most: the moment a supplier's incident quietly 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 clears that bar.
  • 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 how novel the attack was. When you're unsure, document the 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, the detail later. Every deadline runs from the moment you become aware of the significant incident: not from when it began.

Within 24 hours: early warning

A first alert to your CSIRT or competent authority, flagging whether the incident is suspected to be malicious or unlawful, and whether it could have cross-border impact.

Within 72 hours: incident notification

An update carrying an initial assessment: severity and impact, and indicators of compromise where you have them.

On request: intermediate report

If the CSIRT or authority asks, a status update on how the incident is being handled.

Within 1 month of the notification: final report

A detailed account: root cause and type of threat, the mitigations applied and still running, and any cross-border impact.

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

When someone else's incident becomes yours

The reporting duty doesn't stop at incidents that start in your own systems. If a supplier or service provider suffers one that significantly disrupts the services you provide, the obligation to report can land on you, and the 24-hour clock starts when you become aware, not when the supplier finally gets around to telling you.

That's the hard part: suppliers don't always disclose quickly, and a notification that arrives a week late has already eaten your deadline. So readiness rests on independent visibility: knowing when a critical supplier turns up on a ransomware leak site, has credentials dumped, or simply 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 anything happens, make sure you can answer:

Who decides whether an incident is 'significant', and who can reach the CSIRT outside office hours?
Is the CSIRT/authority contact and submission channel ready to hand: not something you look up mid-crisis?
Are supplier incident-notification clauses in the contracts, with a defined window to tell you?
Do we monitor critical suppliers independently, so we're not blind to an incident they haven't disclosed?
Can we produce the timeline and evidence a final report needs: what happened, when, and what we did about it?

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 don't control: a supplier incident you hear about too late. norppa.io watches your suppliers continuously (ransomware victim listings and dark-web credential leaks are re-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 the NIS2 articles it answers to, the history a 72-hour notification or a one-month final report needs (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

Last reviewed: 19 June 2026

This guide is general information about EU law, not legal advice. NIS2 takes effect through each EU Member State's national transposition law, which can differ in detail. Verify the obligations that apply to you with your competent authority or legal counsel.

Related guides

How to comply with NIS2: a step-by-step roadmap

The steps to NIS2 compliance in order: confirm scope, register, management accountability (Art. 20), the Article 21(2) measures, supply-chain security, incident reporting (Art. 23) and continuous, evidenced assurance.

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 for suppliers: you're not designated, but your customers are

Most companies are never designated under NIS2, yet many must comply anyway. How a covered customer's Article 21(2)(d) supply-chain duty flows down to you, what they'll ask for, and how to respond credibly.

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

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

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.

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.

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 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.

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.

GDPR vs NIS2: how they overlap, where they differ, and when one incident triggers both

How GDPR and NIS2 differ and overlap, when one incident triggers both (GDPR Art. 33 72h to the DPA vs NIS2 Art. 23 24h/72h/1-month to the CSIRT), the Art. 35 cooperation and no-double-fine rule, and what both mean for supplier due diligence.

The EU Cyber Resilience Act (CRA): scope, timeline and what it means for your supply chain

What the CRA requires, its phased dates (in force 2024, reporting Sept 2026, full compliance Dec 2027), who is in scope and why pure SaaS often isn't, how it complements NIS2, and what it means for procurement and supplier due diligence.

The EU AI Act: risk tiers, the timeline, and what deployers must do (Article 26)

What the EU AI Act requires: the risk tiers, the phased dates (in force 2024, prohibited Feb 2025, GPAI Aug 2025, high-risk Aug 2026), the Article 26 deployer obligations, how it stacks with NIS2 and the GDPR, and what it means for AI procurement.