Skip to main content
Back to overview

NIS2 Incident Reporting: The 24-Hour, 72-Hour, and 1-Month Deadlines Explained

By NIS2Certify
nis2incident-reportingarticle-23csirt24-hour-deadline

Under NIS2, incident reporting is not optional and it's not flexible. When a significant incident occurs, you have 24 hours for your initial notification β€” not 24 business hours, not "as soon as reasonably practicable." Twenty-four hours from the moment you become aware.

This article breaks down the three reporting stages, explains what qualifies as a "significant incident," and gives you a practical framework to build your reporting process before you need it.


The three reporting stages

Article 23 of the NIS2 Directive establishes a three-stage reporting process:

NIS2 Incident Reporting Timeline

24h

Early Warning

Notify the competent authority (CSIRT/NCA) within 24 hours of becoming aware of a significant incident.

72h

Incident Notification

Submit a detailed notification within 72 hours with an initial assessment of severity, impact and indicators of compromise.

1mo

Final Report

Deliver a comprehensive final report within one month covering root cause, remediation taken and cross-border impact.

Let's examine each stage in detail.


Stage 1: Early warning β€” within 24 hours

Deadline: Within 24 hours of becoming aware of the significant incident.

Who to notify: Your national competent authority AND the relevant CSIRT (Computer Security Incident Response Team).

What you must include:

  • Whether the incident is suspected to be caused by unlawful or malicious acts
  • Whether it could have cross-border impact (affecting other EU member states)

What you don't need yet: A full analysis, root cause, or detailed impact assessment. This is an early warning β€” the purpose is to alert authorities quickly so they can coordinate if needed.

Key point: The 24-hour clock starts when you become aware of the incident, not when it occurred. If an incident happened on Friday night but you only detect it Monday morning, the clock starts Monday morning.

Practical tip: Have a pre-filled notification template ready. When an incident strikes, you don't want to be figuring out forms and contact details under pressure. Prepare the template, know your authority's reporting portal, and rehearse the process.


Stage 2: Incident notification β€” within 72 hours

Deadline: Within 72 hours of becoming aware of the incident (this updates or replaces the early warning).

What you must include:

  • An initial assessment of the incident's severity and impact
  • Indicators of compromise (IoCs) where available
  • An update on the information provided in the early warning

This is where you provide the first substantive analysis. You should have a clearer picture of what happened, what systems were affected, how many people or services were impacted, and what your initial containment measures are.

Key point: If you submitted the early warning and the incident notification together within 24 hours (because you had enough information), you've satisfied both requirements. The 72-hour deadline is a maximum, not a target.


Stage 3: Final report β€” within 1 month

Deadline: Within one month of the incident notification (stage 2).

What you must include:

  • A detailed description of the incident, including its severity and impact
  • The type of threat or root cause that likely triggered the incident
  • Applied and ongoing mitigation measures
  • Where applicable, the cross-border impact of the incident

This is your comprehensive post-incident report. It requires a thorough analysis β€” which is why you get a full month. Some investigations take longer; in that case, you must submit a progress report at the one-month mark and a final report when the investigation concludes.


What qualifies as a "significant incident"?

Not every security event triggers the reporting obligation. NIS2 defines a significant incident as one that:

  • Has caused or is capable of causing severe operational disruption of the services or financial loss for the entity
  • Has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage

Does NIS2 Apply to Your Organisation?

1

Does your organisation operate in an essential or important sector (energy, transport, health, digital infrastructure, etc.)?

Yes ↓No β†’
2

Does your organisation have 50 or more employees, or an annual turnover exceeding €10 million?

Yes ↓No β†’
3

Is your organisation a critical infrastructure provider or a qualified trust service provider?

Yes ↓No β†’
βœ—

NIS2 does not directly apply to your organisation.

βœ“

NIS2 applies to your organisation as an Essential or Important Entity.

!

NIS2 may apply to your organisation β€” seek legal advice to confirm your status.

Applies
Possibly applies
Does not apply

Examples of significant incidents:

  • Ransomware attack that encrypts production systems and halts operations
  • Data breach exposing personal data of customers or employees
  • DDoS attack that makes your services unavailable for an extended period
  • Supply chain compromise where a compromised supplier gives attackers access to your systems
  • Insider threat resulting in significant data exfiltration

Examples that are probably NOT significant:

  • A phishing email that was detected and blocked
  • A failed login attempt
  • A vulnerability discovered during routine scanning (before exploitation)
  • A brief service interruption that was resolved quickly with no data loss

When in doubt, report. It's better to file an early warning that turns out to be unnecessary than to miss the 24-hour deadline for a genuine significant incident.


Who do you report to?

Each EU member state designates its own competent authority and CSIRT. You must report to both:

CountryCompetent authorityCSIRT
BelgiumCCB (Centre for Cybersecurity Belgium)CERT.be
GermanyBSI (Bundesamt fΓΌr Sicherheit in der Informationstechnik)CERT-Bund
NetherlandsRDI (Rijksinspectie Digitale Infrastructuur) β€” expectedNCSC-NL
FranceANSSI (Agence nationale de la sécurité des systèmes d'information)CERT-FR
ItalyACN (Agenzia per la Cybersicurezza Nazionale)CSIRT Italia
SpainCCN-CERT / INCIBECCN-CERT / INCIBE-CERT
PolandNASK / Ministry of Digital Affairs β€” expectedCERT Polska

Note: If your incident has cross-border impact, the CSIRT of the country where you report will coordinate with CSIRTs in other affected member states. You report to your national authority; they handle the cross-border coordination.


Building your incident reporting process

Don't wait until you have an incident to figure out reporting. Build the process now:

1. Pre-incident preparation

  • Identify your authorities β€” know exactly who your national competent authority and CSIRT are
  • Register on reporting portals β€” many countries have online portals; register before you need them
  • Create notification templates β€” pre-fill everything you can (organisation details, contact persons, sector classification)
  • Define roles β€” who in your organisation is responsible for filing the report? Who is their backup?
  • Establish an escalation path β€” from detection team to management to legal to external reporting

2. During the incident

Follow this timeline:

TimeAction
T+0Incident detected β€” start the clock
T+1hInitial assessment: is this potentially significant? If yes, activate reporting process
T+4hBrief management β€” they need to be involved for the formal notification
T+12hPrepare early warning notification with available information
T+24hDEADLINE: Submit early warning to competent authority and CSIRT
T+48hContinue investigation, gather IoCs, assess severity
T+72hDEADLINE: Submit incident notification with initial assessment
T+1 weekContinue investigation and remediation
T+1 monthDEADLINE: Submit final report with root cause and mitigation measures

3. Post-incident

  • Conduct a lessons learned review β€” what worked, what didn't, what needs to change
  • Update your incident response plan based on learnings
  • Update your notification templates if you found gaps during the process
  • Rehearse β€” run a tabletop exercise using the actual incident as a scenario

Penalties for non-reporting

NIS2 doesn't just penalise inadequate security measures β€” it specifically penalises failures in incident reporting:

  • Failure to report within the required timeframes is a separate violation with its own penalties
  • This applies on top of any penalties for the underlying security failure
  • The message is clear: even if a breach was unavoidable, failing to report it on time makes the situation significantly worse

Common questions

"What if we're not sure if it's significant?"

Report it. You can always update or close the notification later. Failing to report a significant incident within 24 hours is a violation. Over-reporting is not.

"Do we need to report to law enforcement as well?"

NIS2 requires reporting to your competent authority and CSIRT. If the incident involves criminal activity, your competent authority may involve law enforcement. Some member states may have additional requirements for reporting to police.

"What about GDPR reporting?"

If the incident involves personal data, you may also need to report under GDPR (72-hour notification to the data protection authority). These are separate obligations. A NIS2 report to your competent authority does not satisfy GDPR requirements, and vice versa. Coordinate both reports.

"Can our incident response provider file the report on our behalf?"

The obligation lies with the entity. You can delegate the practical task of filing to a provider, but the legal responsibility remains with your organisation and its management.


Key takeaway

NIS2 incident reporting is a strict, time-bound obligation with three clear stages. The 24-hour early warning is the most critical deadline β€” and it requires preparation before an incident occurs.

Build your reporting process now. Create your templates. Know your authorities. Rehearse the process. When an incident hits, the last thing you want is to be scrambling to figure out who to call and what form to fill in.


Assess your incident readiness

Our free NIS2 quickscan includes an assessment of your incident handling and reporting readiness β€” one of the 10 Article 21 measure categories. Find out whether your organisation is prepared for the 24-hour clock.


Read also


Take the free quickscan β†’

    NIS2 Incident Reporting: The 24-Hour, 72-Hour, and 1-Month Deadlines Explained β€” NIS2Certify