Article 23EU

EU NIS2 Directive (EU) 2022/2555 Incident Reporting Workflow

Implement 24h early warning, 72h notification, and 1 month final reporting.

Output: a regulator-ready workflow with triggers, owners, evidence capture, trust-service handling, and recipient communications.

Back to main artifact Review sources

Author

Sorena AI

Published

Feb 23, 2026

Updated

Feb 23, 2026

Sections

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published Feb 23, 2026

Updated Feb 23, 2026

Overview

Incident reporting under NIS2 is an operational capability, not a legal footnote. Article 23 requires entities to recognise when an incident is significant, trigger reporting quickly, preserve evidence, and communicate to authorities and affected recipients while facts are still developing.

Section 1

Reporting milestones under Article 23(4)

The reporting clock starts when the entity becomes aware of a significant incident. Your workflow must support speed without forcing certainty that you do not yet have.

Within 24 hours: send the early warning to the CSIRT or, where applicable, the competent authority.
Within 72 hours: send the incident notification with an initial assessment of severity and impact and indicators of compromise where available.
If requested: provide intermediate status updates.
Within 1 month after the incident notification: send the final report with the likely root cause or threat type, mitigation measures, and cross-border impact where relevant.
If the incident is still ongoing at that deadline: send a progress report instead, then submit the final report within 1 month after the incident is handled.

Section 2

What the early warning and incident notification must contain

Article 23 and the Commission guidance make the payload logic clear. The early warning is short and directional. The incident notification is the first structured assessment.

Early warning: whether the incident is suspected to be caused by unlawful or malicious acts and whether it is likely to have a cross-border impact, where applicable.
Incident notification: updates to the early warning, initial assessment of severity and impact, and indicators of compromise where available.
Final report: detailed description of severity and impact, likely root cause or threat type, mitigation measures, and any cross-border impact.

Recommended next step

Turn EU NIS2 Directive (EU) 2022/2555 Incident Reporting Workflow into an operational assessment

Assessment Autopilot can take EU NIS2 Directive (EU) 2022/2555 Incident Reporting Workflow from operationalizing response workflows and review cycles to a reusable workflow inside Sorena. Teams working on EU NIS2 Directive (EU) 2022/2555 can keep owners, evidence, and next steps aligned without copying this guide into separate documents.

Assessment workflow

Open Assessment Autopilot for EU NIS2 Directive (EU) 2022/2555 Incident Reporting Workflow

Start from EU NIS2 Directive (EU) 2022/2555 Incident Reporting Workflow and turn the guidance into owned tasks, evidence requests, and review checkpoints.

Explore next step

Talk to Sorena

Talk through EU NIS2 Directive (EU) 2022/2555

Review your current process, evidence gaps, and next steps for EU NIS2 Directive (EU) 2022/2555 Incident Reporting Workflow.

Explore next step

Section 3

Trust service providers and entities covered by Implementing Regulation (EU) 2024/2690

Trust service providers have a faster incident notification rule in Article 23(4). Relevant cross-border digital providers also need to align significance decisions with Implementing Regulation (EU) 2024/2690.

Trust service providers must notify significant incidents affecting trust services within 24 hours of becoming aware of them.
Implementing Regulation (EU) 2024/2690 applies to DNS service providers, TLD name registries, cloud providers, data centre providers, CDN providers, managed service providers, managed security service providers, online marketplace providers, online search engine providers, social networking services platforms, and trust service providers.
For those entities, incident triage should map directly to the significance cases and technical requirements in the implementing regulation.

Section 4

Workflow blueprint for real operations

Treat reporting as a pipeline with explicit checkpoints. You need clear accountability for awareness time, significance decisions, submissions, and recipient communications.

RACI: incident commander, SOC lead, service owner, legal or compliance, communications, DPO where personal data may be involved, and management escalation.
Evidence capture: awareness timestamp, affected services, logs, indicators of compromise, containment actions, and decision rationale for significance.
Authority route map: national CSIRT, competent authority, single point of contact, and portal access details by country.
Recipient communications: pre-approved notice flow for recipients likely to be adversely affected by the incident.
Post-incident review: corrective actions that feed back into Article 21 controls and management oversight.

Section 5

Operational artefacts you should keep ready

The best reporting workflow is the one your team can execute at 02:00 without improvising or waiting for a legal rewrite.

Significant incident decision log with time of awareness, thresholds applied, approver, and submission timestamps.
24h early warning template, 72h incident notification template, progress report template, and final report template.
Authority and portal runbook per jurisdiction, including access control and authentication steps.
Evidence vault structure for logs, screenshots, tickets, forensic records, and outbound notices.
Tabletop results showing that the workflow has been exercised and improved.

Primary sources