NIS2 Incident Notification: 24h, 72h and 1-Month Deadlines Guide

Article 23 of the NIS2 Directive establishes the mandatory significant incident notification regime. Unlike NIS1, which left wide interpretive latitude to member states, NIS2 imposes harmonized deadlines applicable to all essential and important entities across the European Union. Here's how to structure your notification process to meet the 24h, 72h, and 1-month deadlines — without under-reporting or overloading your teams.

What is a "significant incident" under NIS2?

NIS2 defines a significant incident as an event that:

1. Has caused or is likely to cause a serious operational disruption of services provided or financial losses for the entity, OR
2. Has affected or is likely to affect other natural or legal persons by causing considerable material, bodily, or moral damage

The European Commission published an implementing regulation specifying sectoral thresholds (availability loss > X hours, financial impact > Y, number of users impacted > Z, etc.). These thresholds must be considered in combination with qualitative severity assessment.

Common examples of significant incidents

• Unavailability of a core business service > 2 hours (financial sector) or > 4 hours (other sectors)
• Confirmed personal data compromise (often crossed with GDPR obligation)
• Unauthorized access to critical systems, even without confirmed exfiltration
• Ransomware attack even if remediation is rapid
• Significant performance degradation > 50% over > 1 hour
• Loss of integrity of critical data (corruption, unauthorized modification)

Incidents that do not require notification

• Minor incidents (internal malfunction without user impact)
• Preventive incidents (patches applied before exploitation)
• Exercises and crisis tests
• Fully contained incidents with no service impact

The prudent rule: when in doubt, notify. The authority prefers over-reporting to under-reporting, and failure to notify an incident that turns out to be serious exposes the entity to increased sanctions.

The three notification milestones

Milestone 1 — Early warning: 24 hours

Deadline: no later than 24 hours after the entity became aware of the incident.

Minimum content:

• Indication that the incident is likely to originate from unlawful or malicious acts
• Potential cross-border impact (other member states affected?)
• Immediate actions already taken to limit propagation

This is a pre-alert, not a detailed report. The goal is to allow the competent authority (national CSIRT) to activate its own surveillance mechanism and alert other authorities if relevant.

Who to notify in France: ANSSI via the reporting portal Who to notify in Belgium: CCB (Centre for Cybersecurity Belgium) via the dedicated portal Who to notify in other member states: national CSIRT or NIS2 competent authority

Milestone 2 — Incident notification: 72 hours

Deadline: no later than 72 hours after the entity became aware of the incident.

Expected content:

• Initial description of the incident and probable causes
• Assessment of severity and impact
• Indicators of compromise (IoCs) if identified
• Updates on corrective actions in progress
• Estimated number of users/customers affected
• Geographic scope (countries, regions)
• Measured operational impact

The 72h notification is cumulative with the 24h early warning — you don't "replace," you update and enrich. Information not available at 24h becomes mandatory at 72h.

Milestone 3 — Final report: 1 month

Deadline: no later than 1 month after the significant incident.

Expected content:

• Detailed and final description of the incident
• Threat type or root cause
• Applied mitigation measures and their effectiveness
• Actual cross-border impact (if applicable)
• Preventive measures adopted to avoid recurrence
• Lessons learned

If the incident is still ongoing at 1 month, the entity must provide a status report at this deadline, then a definitive final report no later than 1 month after the incident has been handled.

Summary table

When does the clock start?

Article 23 refers to "awareness" of the incident. This notion is crucial and has been clarified by the Commission.

Practical interpretation

The clock starts when the entity:

1. Receives reliable information (internal or external) indicating a significant incident
2. Has confirmed that the event meets NIS2 criteria (threshold test + qualitative assessment)

This is not the moment the incident occurred (which can be much earlier — typical case: silent compromise detected 3 weeks after).

It's also not the moment the entity has a doubt or suspicion — a Level-2 SOC ticket does not start the clock. Confirmation that the incident is significant starts the clock.

Chronological example

• D-30: Silent intrusion into the IS (admin account compromise)
• D-5: EDR alert triggered, P1 SOC ticket
• D-2: Forensic analysis confirms: exfiltration of 2,000 user accounts
• D0, 14:00: CISO confirms the incident meets NIS2 significant criteria → clock starts
• D0+24h (D+1, 14:00): Early warning due
• D0+72h (D+3, 14:00): Notification due
• D0+1 month (D+30, 14:00): Final report due

Accurately tracking the awareness timestamp is therefore a major operational prerequisite. A timestamped ticket in your ITSM with the moment of confirmation is the usually accepted proof.

Coordination with other mandatory notifications

A NIS2 significant incident can also trigger other notification obligations:

GDPR (72h)

If personal data is involved: notify national DPA within 72 hours under GDPR Article 33. This is a distinct notification but with timing aligned to the NIS2 72h.

DORA (for financial entities)

Financial entities subject to DORA notify under a specific regime (early warning, intermediate, final). DORA and NIS2 deadlines partially overlap. In practice, the national CSIRT forwards to the financial supervisor to avoid formal double notification. For more details, see our DORA 2026 guide and our DORA vs NIS2 comparison.

CER Directive (physical critical entities)

For entities also covered by the CER Directive (Critical Entities Resilience), complementary notification to the CER authority may be required for non-cyber incidents (physical disasters, infrastructure failures).

Aviation, health sectors, etc.

Pre-existing sectoral obligations (EASA, EMA, etc.). NIS2 does not replace them: they coexist.

Our advice

Build a notification matrix that crosses:

• Incident type (cyber, physical, mixed)
• Data concerned (personal, financial, health)
• Authorities to notify + deadlines
• Form template for each authority

This matrix is an integral part of your incident response plan. ResiPlan automates this matrix by mapping each incident type to its notification obligations.

The 7 operational steps to meet deadlines

1. Detection and escalation (continuous)

• SIEM + EDR + SOAR tooling for proactive detection
• Clearly documented L1 → L2 → CISO escalation procedure
• 24/7 CISO on-call for essential entities

2. Qualification (D0)

• NIS2 checklist: thresholds exceeded? cross-border impact? malicious act suspected?
• Documented decision: significant incident YES / NO
• Official timestamp of awareness (ITSM timestamp)

3. Crisis cell mobilization (D0+1h to 4h)

• Active crisis cell: CISO, CIO, Executive, Legal, Communications, DPO
• Designated single point of contact for authorities
• Preparation of 24h early warning

4. Early warning (D0 to D+24h)

• Send the form via national portal (ANSSI, CCB, etc.)
• Timestamped archival of the submission
• Internal communication: instructions not to communicate externally without coordination

5. 72h notification (D+24h to D+72h)

• Progressive enrichment: forensics, logs, attacker behavior
• Impact estimation: number of victims, geographic scope, financial loss
• Preparation of external communication if relevant

6. Remediation and monitoring (D+3 to D+30)

• Corrective plans + continuous monitoring
• Regular updates to the authority upon request
• Coordination with other entities if supply chain incident

7. Final report and post-mortem (D+30)

• Final report submission
• Internal post-mortem: what worked, what must be improved?
• Playbook updates + team training

Common mistakes to avoid

Mistake 1 — Waiting for "completeness" before notifying No. NIS2 imposes milestones even if information is partial. It's better to notify early with available information and enrich afterward than to miss the deadline seeking exhaustiveness.

Mistake 2 — Not timestamping "awareness" The official timestamp is critical. It must be recordable in your ITSM or SIEM and enforceable in case of audit. A simple email to the CISO is not sufficient.

Mistake 3 — Confusing notification and external communication Notification to the NIS2 authority is a legal obligation. External communication (customers, press, media) is a separate strategic decision, to be coordinated with legal and leadership.

Mistake 4 — Treating notification as a purely technical matter NIS2 engages personal liability of executives. The decision to notify or not, the content of the report, and the deadlines must be validated by leadership, not only by the CISO.

Mistake 5 — Ignoring parallel sectoral notifications GDPR, DORA, CER directive, sectoral obligations… ensure your matrix is exhaustive.

How ResiPlan accelerates your NIS2 compliance

ResiPlan natively includes:

• An incident management module with automatic 24h/72h/1-month workflow
• Pre-filled forms for ANSSI, CCB, and other CSIRT authorities
• Awareness timestamp tracking timestamped and enforceable
• A notification matrix cross-referencing NIS2, GDPR, DORA by incident type
• A complete audit trail for authority controls

Start your 14-day free trial to see the incident module in action.

Conclusion

NIS2 transforms incident notification from an administrative exercise into a critical, timed process engaging executive liability. The 24h/72h/1-month deadlines are strict and sanctions in case of failure are substantial (up to 2% of global turnover for essential entities).

The operational key: prepare the process before an incident occurs. Clear playbooks, automated tools, pre-qualified crisis cell, established relationships with CSIRTs. On D-day, it's too late to improvise.

For deeper reading:

• NIS2 essential vs important entities
• DORA vs NIS2: which directive applies
• ISO 22301 in 10 Steps