Start with scope and significance
Article 23 of the NIS2 Directive creates a staged reporting process for essential and important entities affected by a significant incident.
Before applying the reporting timeline, an organisation needs to establish two things:
- whether it is within the relevant national NIS2 regime; and
- whether the incident meets the significance threshold.
Under Article 23(3), an incident is significant if it has caused or is capable of causing severe operational disruption of services or financial loss for the entity, or if it has affected or is capable of affecting other people or organisations by causing considerable material or non-material damage.
Those are evaluative criteria. A workflow can collect service disruption, financial impact, affected parties, and damage estimates. The significance conclusion should retain its rationale and reviewer rather than appearing as an unexplained switch.
The staged timeline
Article 23(4) sets out a sequence rather than a single filing.
| Stage | Deadline | Core purpose |
|---|---|---|
| Early warning | Without undue delay and within 24 hours of awareness | Flag the significant incident and, where applicable, suspected unlawful or malicious acts or cross-border impact |
| Incident notification | Without undue delay and within 72 hours of awareness | Update the early warning and provide an initial assessment of severity, impact, and available indicators of compromise |
| Intermediate report | When requested by the CSIRT or competent authority | Provide relevant status updates |
| Final report | No later than one month after the incident notification | Provide a detailed description, likely threat or root cause, mitigation, and cross-border impact where applicable |
For an incident still ongoing when the final report would be due, Article 23 provides for a progress report at that time and a final report within one month after the incident is handled.
Trust service providers have a specific derogation in Article 23(4): for significant incidents affecting their trust services, the incident notification described in point (b) is due within 24 hours of awareness. Scope and sector details therefore cannot be an afterthought.
Three deadlines do not call for three disconnected forms. They call for one incident record with staged, immutable submissions.
Build one incident record
The early warning and later reports concern the same incident. Model them as stages attached to a stable incident identifier.
The incident record should retain:
- the original awareness timestamp and its basis;
- the significance assessment;
- every submission as it was sent;
- authority acknowledgements and reference numbers;
- subsequent updates without overwriting earlier content; and
- the current incident status and assigned owners.
A consolidated current view is useful operationally, but it should be generated from the history rather than replacing it. If the severity estimate changes between the early warning and final report, the record should show both estimates and when the team learned more.
Fields for each stage
Shared incident facts
- reporting entity, sector, and relevant service;
- CSIRT or competent authority;
- awareness time and rationale;
- incident summary and current status;
- significance assessment and supporting impact facts;
- cross-border impact;
- incident owner and reporting owner.
Early warning
- suspected unlawful or malicious cause, where applicable;
- possible cross-border impact;
- assistance requested;
- submission time, channel, and receipt.
The early warning is intentionally early. Avoid making a full root-cause analysis a blocking requirement at this stage.
Incident notification
- updated incident description;
- initial severity and impact assessment;
- indicators of compromise where available;
- changes since the early warning;
- submission time, channel, and receipt.
Final or progress report
- detailed description, severity, and impact;
- likely threat type or root cause;
- applied and ongoing mitigation;
- cross-border impact where applicable;
- whether the incident remains ongoing;
- follow-up deadline when a progress report is used.
National implementation matters
NIS2 is a directive. Member States transpose it into national law and establish competent authorities, procedures, portals, and potentially more specific requirements. The directive is the common starting point; the operational filing process depends on the national regime that applies to the entity.
A reusable schema should therefore separate:
- the common Article 23 structure;
- jurisdiction-specific scope questions;
- the authority and submission channel;
- national terminology and additional fields; and
- the effective version of the national implementation.
Do not label a generic EU workflow as sufficient for every Member State. A publisher can maintain a common base while releasing reviewed national variants.
Workflow design checks
Before using a NIS2 incident-reporting workflow, test whether it can answer these questions:
- Can the team record when it became aware without rewriting that timestamp later?
- Can an early warning be completed when root cause and exact impact remain unknown?
- Does the 72-hour stage reuse the incident facts rather than ask for contradictory re-entry?
- Can requested intermediate reports be added without changing the statutory sequence?
- Does an ongoing incident produce a progress report and a new final-report deadline?
- Can the authority receipt and external reference be stored for each submission?
- Does the workflow identify the national implementation and competent authority?
- Is the significance assessment preserved even when the conclusion changes?
The operational objective is not merely to display a countdown. It is to help the incident team submit the right stage, with the information available at that stage, while building a record that remains intelligible after the incident is over.