NIS2 Article 23 Incident Reporting Workflow

NIS2 requires essential and important entities to notify a significant incident without undue delay to the CSIRT or, where applicable, the competent authority designated by the relevant Member State. The workflow record should show when the entity became aware of the incident, why the incident was or was not significant, and which notifications or communications were sent.

Treat incident handling as the priority. The reporting workflow should collect enough information for the authority and for later review without pulling responders away from containment, recovery, and mitigation work.

Confirm the reporting entity and controlling law first. NIS2 is a directive implemented through Member State law, so the competent authority, portal, form, language, and any additional national fields can differ. A sector-specific Union act with requirements at least equivalent in effect can displace the corresponding NIS2 risk-management, reporting, supervision, and enforcement provisions for the same entity and duty.

Open a significance triage as soon as the incident lead has enough information to suspect an impact on a NIS2-covered service. Under Article 23, an incident is significant if it has caused or is capable of causing severe operational disruption or financial loss for the entity, or if it has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage.

For DNS, TLD registry, cloud, data centre, CDN, managed service, managed security service, online marketplace, online search engine, social networking platform, and trust-service providers covered by Implementing Regulation (EU) 2024/2690, add the regulation's incident-significance criteria to the triage. Do not apply those sector-specific criteria to other entity types unless the relevant law or authority guidance says to do so.

If the incident is significant, prepare the early warning for the CSIRT or competent authority without undue delay and in any event within 24 hours of becoming aware of the significant incident. The early warning is not a full root-cause report. Article 23 asks it to state, where applicable, whether unlawful or malicious acts are suspected and whether the incident could have a cross-border impact.

Keep the submission receipt, exact time sent, recipient authority, and information set available at the time. Record later corrections as updates rather than silently changing the submitted version.

Follow the early warning with the incident notification without undue delay and in any event within 72 hours of becoming aware of the significant incident. This notification updates the early warning and adds an initial assessment of severity and impact, plus indicators of compromise where available.

Trust service providers have a specific Article 23 derogation for significant incidents affecting their trust services: the incident notification must be made without undue delay and in any event within 24 hours of awareness. Keep that trust-service branch explicit in the workflow so the wrong deadline is not applied.

After the early warning, the CSIRT or competent authority must respond without undue delay and, where possible, within 24 hours of receiving it. The response includes initial feedback and, if the entity asks, guidance or operational advice on possible mitigation measures and additional technical support. Route that feedback into incident command and record the decision on each recommendation.

Keep two recipient duties separate. Where appropriate, notify service recipients without undue delay when a significant incident is likely to adversely affect their service. Where applicable, tell potentially affected recipients what measures or remedies they can take against a significant cyber threat and, where appropriate, inform them of the threat itself. Cross-border handling occurs through the authorities; the entity's job is to supply enough information for them to determine cross-border impact.

Be ready to provide an intermediate report on relevant status updates if the CSIRT or competent authority requests one. Do not wait for root-cause certainty before maintaining the reporting record; distinguish confirmed facts from working hypotheses.

Submit the final report not later than one month after the 72-hour incident notification. If the incident is still ongoing at that point, provide a progress report and then submit the final report within one month of handling the incident.

Close the workflow only when the reporting timeline, authority route, significance rationale, recipient-communication decision, and evidence package agree. The record should be understandable to an auditor, regulator, customer assurance reviewer, or new incident commander without relying on unwritten project history.

Keep Member State implementation differences visible. NIS2 sets EU-level obligations, but the practical portal, authority name, national forms, and additional local instructions can vary by jurisdiction.