PowerQuantEUSend your AI questionnaire

Article 23 of Directive (EU) 2022/2555 sets a three-stage notification flow for significant incidents. The template below lists the fields you should be prepared to submit at each stage, and what the regulator is actually looking for at that moment in the incident lifecycle. Pre-build the stage-1 and stage-2 templates inside your incident-response platform — the 24-hour clock is real.

Timeline at a glance

StageDeadlineRecipient
Stage 1Within 24 hours of becoming awareCSIRT or competent authority designated under NIS2 in your Member State
Stage 2Within 72 hours of becoming awareSame CSIRT or competent authority
Intermediate report (on request)On request of the CSIRT or competent authoritySame
Stage 3Within one month of the stage-2 notification (or one month after incident resolution if still ongoing)Same

Stage 1 — Within 24 hours of becoming aware

Early warning — speed over completeness. The objective is to let the authority know an incident is happening and to flag two specific facts: whether it is suspected to be caused by unlawful or malicious acts, and whether it could have a cross-border impact.

Notifying entity (legal name + sector + NIS2 classification: essential / important) Pre-fill in a stored template — do not write it under pressure.

Reporter (name + role + 24/7 contact) A single accountable human, not a team mailbox.

Time of first awareness (UTC) The clock for the 24h, 72h and 1-month deadlines starts here. Document how awareness was established.

Short narrative (1–3 sentences) Plain language. What service is affected, what kind of incident, what is the current operational state.

Suspected malicious or unlawful cause? (yes / no / unknown) Article 23(4)(a) requires this flag. 'Unknown' is an acceptable answer in stage 1.

Possible cross-border impact? (yes / no / unknown) Article 23(4)(a) again — triggers the authority's information-sharing duties.

Ticket / case reference (yours) Re-used in stage 2 and stage 3 so the authority can chain the reports.

Stage 2 — Within 72 hours of becoming aware

Incident notification — an initial assessment of severity, impact and indicators of compromise. This is the substantive notification, building on stage 1.

Same identifiers as stage 1 (notifying entity, reporter, case reference)

Updated assessment of severity and impact Operational disruption, financial loss, material or non-material damage to natural or legal persons.

Number of users / customers affected Best estimate is acceptable; document how the estimate was made.

Geographic scope (Member States and third countries) Drives the authority's onward notification to other CSIRTs and to ENISA.

Affected services and asset classes Map to the services you registered under Article 27 NIS2 register-of-entities.

Threat type and known indicators of compromise (IOCs) TLP-classified. Hashes, IPs, domains, malware family if known. Indicate confidence level.

Initial root-cause hypothesis Hypothesis only — confirmed root cause goes in the final report.

Mitigation measures applied so far Containment, eradication, recovery actions with timestamps.

Whether suppliers or customers must be notified Article 23(2) duty to inform service recipients of significant cyber threats where appropriate.

Intermediate report (on request)

Article 23(4)(c) lets the authority request a status update between the 72h notification and the one-month final. Use the stage-2 fields with updated values.

Status update against the stage-2 fields Delta-only is acceptable — call out what has changed since the previous submission.

Newly identified affected systems, users or third parties

Changes to mitigation status

Stage 3 — Within one month of the stage-2 notification (or one month after incident resolution if still ongoing)

Final report — confirmed root cause, full impact picture, the mitigation measures that worked, and any cross-border effects. If the incident is still ongoing at the one-month mark, submit a progress report and the final report within one month of resolution.

Detailed description of the incident, including severity and impact Timeline-based narrative; chain together stages 1, 2 and any intermediate updates.

Type of threat or confirmed root cause Move from hypothesis (stage 2) to confirmed cause supported by evidence.

Mitigation measures applied and effectiveness What worked, what did not, what residual risk remains.

Cross-border impact, if applicable Confirmed scope across Member States and third countries.

Lessons learned and changes to controls Map back to Article 21 NIS2 risk-management measures — which controls failed, which were strengthened.

Operating notes

  • Pre-build stages 1 and 2 as fillable templates in your incident-response platform. The 24-hour clock is real; you cannot draft format from scratch under pressure.
  • Use UTC for every timestamp. Member-State authorities operate in their own time zones and will normalise — UTC removes ambiguity.
  • Article 23 talks about 'significant' incidents. A separate triage rubric (your own, based on Article 23(3) criteria) should decide whether to notify at all. Notifying everything dilutes signal; notifying too little risks the upper-tier fines (EUR 10M or 2% of worldwide turnover for essential entities, EUR 7M or 1.4% for important).
  • Article 23(1) also obliges entities to notify recipients of their services about significant cyber threats where appropriate, and the measures or remedies they can take. Capture this as a separate workflow with its own template.
  • National transpositions vary. Check the specific channel, format and language requirements published by your Member-State CSIRT — e.g. Denmark uses the Centre for Cyber Security (CFCS) under lov nr. 434 of 6 May 2025 (in force 1 July 2025).

What "significant incident" means

Article 23(3) 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 concerned, or has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage. The Implementing Regulation (EU) 2024/2690 (sector-specific thresholds for DNS providers, TLD registries, cloud providers and several other digital-infrastructure sectors) gives concrete thresholds for the entities it covers; entities outside its scope must apply the Article 23(3) criteria on a case-by-case basis with documented reasoning.

Sources

Note: PowerQuant supplies templates and documentation for use in your internal incident-response process — not legal advice. National transpositions of NIS2 vary in scope, language and channel; verify the specific submission requirements with your Member-State CSIRT.

PowerQuant Module 1

Where NIS2 Article 21 risk-management measures and the Article 23 notification flow overlap with your AI Act deployer obligations, Module 1 produces the joined-up evidence pack in 5 working days.