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.

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 the full root-cause report; it should make the authority aware of the incident and enable assistance where needed.

The early warning should state, where applicable, whether unlawful or malicious acts are suspected and whether cross-border impact could exist. Keep the submission receipt, the exact time sent, the recipient authority, and the information set that was available at the time.

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 should provide initial feedback without undue delay and where possible within 24 hours, including guidance or operational advice if requested. Route that feedback into the incident command channel and record any action taken or rejected.

Where appropriate, notify recipients of services that are likely to be adversely affected by the significant incident or significant cyber threat. If the incident concerns two or more Member States, expect cross-border handling through the CSIRT, competent authority, or single point of contact; your record should preserve the facts needed 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 file 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.