Key Takeaway: NIS2 introduces a three-stage mandatory reporting process: an early warning within 24 hours, a full notification within 72 hours, and a final report within one month. Penalties apply not just for the incident, but for missing any reporting deadline.

Under NIS2, a significant cybersecurity incident triggers legal obligations that begin running the clock the moment you become aware. There is no grace period, no "we were still assessing the situation" exception. The 24-hour early warning deadline is hard.

This playbook gives you the step-by-step process to manage a significant incident under NIS2, from initial detection through your one-month final report. Read it before an incident happens, not during one.

What counts as a "significant" incident?

The reporting obligations only trigger for "significant" incidents. NIS2 Article 23 defines a significant incident as one that causes or is capable of causing severe operational disruption or financial loss, or that has affected or is capable of affecting other natural or legal persons. More specifically, an incident is significant if it:

Has caused or may cause severe operational disruption to your services

Including significant downtime of critical services, systems, or processes.

Has caused or may cause significant financial loss to your organization

Has affected or may affect other organizations or persons (customers, partners, citizens)

Has resulted in loss of confidentiality, integrity, or availability of data at significant scale

When in doubt, report. NIS2 national authorities consistently advise erring on the side of reporting. Filing an unnecessary early warning carries no penalty. Missing a required one does.

The three-stage reporting process

1

Early warning

Within 24 hours

Notify your national CSIRT (or competent authority if your member state requires it) that a significant incident has occurred or is suspected. This is a brief notification, not a full analysis.

Minimum required information:

  • Date and time of detection
  • Nature of the incident (what type: ransomware, breach, DDoS, etc.)
  • Systems or services affected
  • Initial assessment of impact
  • Whether a cross-border impact is suspected
2

Incident notification

Within 72 hours

A detailed notification providing your current assessment of the incident. You are not expected to have full root cause analysis at this point, but you must provide a substantive update.

Required information:

  • Updated description of the incident and its timeline
  • Severity assessment and impact scope
  • Indicators of compromise (if known)
  • Containment measures taken
  • Whether customers or other affected parties have been notified
  • Preliminary root cause hypothesis
3

Final report

Within 1 month

A comprehensive post-incident report covering the full analysis. If the incident is still ongoing at one month, submit an interim progress report instead, followed by a final report within one month of resolution.

Required information:

  • Full incident description and confirmed root cause
  • Complete impact assessment (financial, operational, reputational)
  • Remediation measures implemented
  • Measures taken to prevent recurrence
  • Cross-border impact details (if applicable)

Who do you actually notify?

NIS2 requires notification to your national CSIRT (Computer Security Incident Response Team) or the competent authority designated by your member state. Each EU country has implemented this differently. Your primary contacts depend on your sector and country of establishment:

Country Primary NIS2 authority National CSIRT
Netherlands NCSC-NL / sector regulators NCSC-NL
Germany BSI CERT-Bund (BSI)
France ANSSI CERT-FR (ANSSI)
Belgium CCN / sector regulators CERT.be
Other EU states Varies by sector National CSIRT per ENISA register

Note: For sector-specific entities (energy, finance, health), your sector regulator may be the primary notification point rather than the national CSIRT. Check with your national implementation.

Action before an incident: Identify and document your specific notification contact now, including the reporting portal URL, contact email, and any required registration. This information should be in your incident response plan, not searched for under pressure at 2am.

Internal response steps running in parallel

Regulatory reporting runs alongside your technical incident response, not after it. Here is the parallel track you need to manage:

Hour-by-hour first 24 hours

0:00

Detection and initial triage

Alert security team. Activate incident response plan. Begin containment. Do NOT shut down forensic evidence.

0:30

Significance assessment

Apply your pre-defined significance criteria. If in doubt, treat as significant. Notify incident commander and management.

1:00

Internal escalation

Brief C-suite and legal counsel. They need to be involved in the reporting decision, especially if cross-border or customer impact is possible.

4:00

Draft early warning

Prepare your 24-hour early warning notification with available information. Legal review if time permits.

H-2

Final review and submission

Submit early warning at least 2 hours before the 24-hour deadline. Keep internal confirmation record.

Notifying affected customers and partners

NIS2 Article 23(2) also requires notification to significant service recipients when an incident may affect them. This runs alongside your regulatory reporting. Key principles:

Notify customers who need to take protective action

If a breach could enable attackers to target your customers (credential compromise, exposed personal data, supply chain attack), notify them promptly so they can act. Delay transfers risk to them.

Coordinate messaging with your authority

If the national CSIRT requests that you delay public disclosure to avoid tipping off attackers or enabling copycat attacks, follow that guidance and document it.

GDPR notification may run in parallel

If personal data is involved, GDPR Article 33 requires notification to your supervisory authority within 72 hours of becoming aware. Check whether the same authority handles both (in some member states, yes).

Prepare before an incident happens

Improvising incident response under a 24-hour deadline is how organizations miss reporting requirements. Build these elements into your incident response plan now:

Pre-incident checklist

  • Documented incident significance criteria (what triggers reporting)
  • National CSIRT contact details and reporting portal access
  • Reporting notification templates (early warning, 72h, final)
  • Named incident commander with defined authority
  • 24/7 escalation path to management and legal
  • Incident log template for evidence preservation
  • Out-of-band communication channel (in case primary systems are compromised)
  • Tabletop exercise completed at least annually

Frequently asked questions

What counts as a significant incident under NIS2?

Article 23 defines a significant incident as one that causes or is capable of causing severe operational disruption or financial loss, or that has affected or is capable of affecting other natural or legal persons. In practice, severe service disruption, material financial loss, customer or partner impact, or significant loss of confidentiality or integrity all meet the threshold.

What are the NIS2 incident reporting deadlines?

Article 23 sets a three-stage clock: an early warning within 24 hours of becoming aware of the incident, a full notification within 72 hours with updated assessment and containment measures, and a final report within one month covering root cause and corrective actions. If the incident is ongoing at one month, submit an interim progress report.

Who do I notify when a NIS2 incident occurs?

The national CSIRT or competent authority designated by your member state. In the Netherlands this is NCSC-NL, Germany uses BSI and CERT-Bund, France uses ANSSI and CERT-FR, Belgium uses CCB and CERT.be. For entities in energy, finance, or health, a sector regulator may be the primary notification point instead of the national CSIRT.

What information must the 24-hour early warning contain?

The early warning is a brief notification covering date and time of detection, the nature of the incident such as ransomware or breach, the systems or services affected, an initial impact assessment, and whether cross-border impact is suspected. It is a notification, not a full analysis. Root cause is not expected at this stage.

Do I need to notify customers after a NIS2 incident?

Yes, where the incident may affect them. Article 23(2) requires notification to recipients of the service when they need to take protective action, for example after a credential compromise or a supply chain attack. Coordinate messaging with the authority if delayed public disclosure is requested, and run GDPR Article 33 notification in parallel if personal data is involved.

What should I have ready before a NIS2 incident happens?

Documented significance criteria, national CSIRT contact details and portal access, notification templates for the 24, 72, and 30-day reports, a named incident commander with defined authority, a 24/7 escalation path to management and legal, an incident log template for evidence preservation, an out-of-band communication channel, and a tabletop exercise at least annually.

What happens if I miss the 24 or 72-hour reporting deadline?

Late or absent notifications are explicitly cited in the first 2026 NIS2 fines. National authorities treat a missed deadline as a separate breach from the underlying incident. Expect a formal finding, a binding instruction to improve procedures, and potentially a monetary penalty. Evidence of the detection timeline is the single strongest mitigation.

Related articles