Incident reporting and communications — NIS2 Article 23

NIS2 Article 23 sets out the incident-reporting obligations that essential and important entities must follow. The Article is structured in stages: paragraph (1) frames the duty to notify the CSIRT or competent authority and the duty to notify recipients of the services; paragraph (2) addresses communication of mitigation measures for cyber threats; paragraph (3) defines what makes an incident "significant"; paragraph (4) establishes the four-stage timeline (24-hour early warning, 72-hour notification, intermediate report on request, one-month final report, with progress reporting for ongoing incidents); paragraph (5) requires authority feedback; paragraphs (6)–(11) deal with cross-border information sharing, public notification, voluntary notification, and the implementing-act overlay.

This page quotes the most operationally important Article 23 wording — paragraphs (1), (3), and (4) including all five sub-paragraphs and the trust-service derogation — verbatim from the published OJ text, and explains how each duty lands in Modulos.

Quick decision

• Detected a security event → start the classification clock at the moment the entity becomes aware. Under Article 23(4)(a), an early warning is owed without undue delay and in any event within 24 hours from awareness if the event qualifies as a significant incident under Article 23(3).
• Confirmed a significant incident → within 72 hours of awareness, submit the Article 23(4)(b) incident notification (initial assessment, indicators of compromise where available, update of the early warning). A final report is due no later than one month after the notification.
• Trust service provider → the Article 23(4) derogation from point (b) applies: within 24 hours of awareness of significant incidents that have an impact on the provision of trust services.
• Recipients of the service affected → Article 23(1) requires the entity to notify recipients without undue delay where the significant incident is likely to adversely affect the provision of those services; Article 23(2) addresses communication of mitigation measures for significant cyber threats.
• Operating across Member States → Article 23(6) requires the CSIRT or competent authority that received the notification, where the significant incident concerns two or more Member States, to inform without undue delay the other affected Member States and ENISA. Article 23(8) then provides for SPOC-to-SPOC forwarding at the request of the competent authority or the CSIRT. ENISA receives Article 23(9) quarterly anonymised summaries.

TL;DR

• Article 23(3) defines the significance test: severe operational disruption or financial loss to the entity, or considerable material or non-material damage to others. Both prongs include capability of causing the effect, not only actual occurrence.
• Article 23(4) stages the reporting sequence: 24-hour early warning, 72-hour incident notification, intermediate report on request, one-month final report, and progress reporting for ongoing incidents.
• The Article 23(4) trust-service derogation (from point (b)) sets a 24-hour notification deadline for trust service providers in respect of significant incidents that have an impact on the provision of their trust services.
• Article 23(1) and 23(2) add a recipient-notification duty (where the significant incident is likely to adversely affect provision of services) and a communication duty for mitigation measures in respect of significant cyber threats.
• Article 23(5) requires the CSIRT or competent authority to provide feedback to the entity without undue delay and where possible within 24 hours of the early warning. Article 23(7) allows the authority, after consulting the entity, to inform the public where necessary.
• For specific digital-infrastructure entity types and trust service providers, Commission Implementing Regulation (EU) 2024/2690 further specifies the cases in which an incident is considered significant for Article 23 purposes.

Primary source

Directive (EU) 2022/2555 on EUR-Lex (CELEX 32022L2555) — Article 23 · Commission Implementing Regulation (EU) 2024/2690 (significant-incident criteria for digital-infrastructure entity types)

Article 23(1) — notification to CSIRT / authority and to recipients

Article 23(1) carries multiple duties on the entity. The first subparagraph requires notification to the CSIRT or competent authority for any incident having a significant impact on the provision of the entity's services, and conditional recipient notification. The second subparagraph requires reporting of cross-border-impact information and shields the notifying entity from increased liability for the notification itself:

Member States shall ensure that essential and important entities notify, without undue delay, their CSIRT or, where applicable, their competent authority, in accordance with paragraph 4, of any incident that has a significant impact on the provision of their services as referred to in paragraph 3 (significant incident). Where appropriate, the entities concerned shall notify, without undue delay, the recipients of their services of significant incidents that are likely to adversely affect the provision of those services.

Member States shall ensure that those entities report, inter alia, any information enabling the CSIRT or, where applicable, the competent authority to determine any cross-border impact of the significant incident. The mere act of notification shall not subject the notifying entity to increased liability.

The recipient notification limb is conditional ("where appropriate" and "likely to adversely affect"), unlike the unconditional authority-notification trigger.

In Modulos: ORF-350 (significant incident determination governance, Art 23(3)) plus ORF-351 (recipient communication, Art 23(1)–(2)).

Article 23(2) — communicating mitigation measures for cyber threats

Article 23(2) attaches a parallel communication duty when a significant cyber threat is detected:

Where applicable, Member States shall ensure that essential and important entities communicate, without undue delay, to the recipients of their services that are potentially affected by a significant cyber threat any measures or remedies that those recipients are able to take in response to that threat. Where appropriate, the entities shall also inform those recipients of the significant cyber threat itself.

Article 23(2) is distinct from Article 23(1): it triggers on a significant cyber threat (not an incident), and the obligation is communication of measures and remedies, with the recipient information element conditional.

In Modulos: ORF-351 and MRF-287.

Article 23(3) — when an incident is "significant"

Article 23(3) sets the two-prong significance test:

An incident shall be considered to be significant if:

(a) it has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned;

(b) it has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage.

Both prongs include "has caused or is capable of causing" / "has affected or is capable of affecting", making the test forward-looking. For the specific digital-infrastructure entity types listed in Article 1 of Commission Implementing Regulation (EU) 2024/2690, the Implementing Regulation further specifies — through quantitative and qualitative criteria in its Annex — the cases in which an incident is considered to be significant for Article 23 purposes.

In Modulos: ORF-350 (determination governance) and MRF-286 (AI-service detection and impact assessment).

Article 23(4) — the four-stage reporting timeline

Article 23(4) sets the operative timeline. The opening sentence and each of the five sub-paragraphs are quoted verbatim below.

Member States shall ensure that, for the purpose of notification under paragraph 1, the entities concerned submit to the CSIRT or, where applicable, the competent authority:

Article 23(4)(a) — 24-hour early warning

(a) without undue delay and in any event within 24 hours of becoming aware of the significant incident, an early warning, which, where applicable, shall indicate whether the significant incident is suspected of being caused by unlawful or malicious acts or could have a cross-border impact;

In Modulos: ORF-352 (governance) and MRF-288 (AI-service workflow).

Article 23(4)(b) — 72-hour incident notification

(b) without undue delay and in any event within 72 hours of becoming aware of the significant incident, an incident notification, which, where applicable, shall update the information referred to in point (a) and indicate an initial assessment of the significant incident, including its severity and impact, as well as, where available, the indicators of compromise;

In Modulos: ORF-353 (governance) and MRF-289 (AI-service workflow).

Trust-service derogation from point (b). Article 23(4) contains a derogation paragraph following point (e) that displaces the 72-hour rule for trust service providers:

By way of derogation from the first subparagraph, point (b), a trust service provider shall, with regard to significant incidents that have an impact on the provision of its trust services, notify the CSIRT or, where applicable, the competent authority, without undue delay and in any event within 24 hours of becoming aware of the significant incident.

In Modulos: MRF-292 (AI-service execution requirement for the trust-service 24-hour path).

Article 23(4)(c) — intermediate report on request

(c) upon the request of a CSIRT or, where applicable, the competent authority, an intermediate report on relevant status updates;

Article 23(4)(d) — one-month final report

(d) a final report not later than one month after the submission of the incident notification under point (b), including the following:

(i) a detailed description of the incident, including its severity and impact;

(ii) the type of threat or root cause that is likely to have triggered the incident;

(iii) applied and ongoing mitigation measures;

(iv) where applicable, the cross-border impact of the incident;

Article 23(4)(e) — progress report and later final report for ongoing incidents

(e) in the event of an ongoing incident at the time of the submission of the final report referred to in point (d), Member States shall ensure that entities concerned provide a progress report at that time and a final report within one month of their handling of the incident.

In Modulos: ORF-354 (intermediate, final, and progress reporting governance) and MRF-290 (AI-service workflow).

Article 23(5) — authority feedback

Article 23(5) imposes a duty on the receiving CSIRT or competent authority. It requires that, without undue delay and where possible within 24 hours of receiving the early warning referred to in Article 23(4)(a), the CSIRT or competent authority provides a response to the notifying entity. The response shall include initial feedback on the significant incident and, upon request, guidance or operational advice on the implementation of possible mitigation measures. Where appropriate, additional technical support shall be offered, and where the significant incident is suspected of being of criminal nature the CSIRT or competent authority shall also provide guidance on reporting the significant incident to law enforcement.

The receiving-side governance lives on the CSIRT or competent authority, not on the entity. The Modulos surface relevant on the entity side is the inbound-response capture: authority feedback received under Article 23(5) is recorded as evidence against the corresponding Article 23(4)(a) requirement.

Article 23(6)–(11) — cross-border, public information, voluntary notification, implementing acts

• Article 23(6) — where the significant incident concerns two or more Member States, the CSIRT, competent authority, or single point of contact that received the notification shall, without undue delay, inform the other affected Member States and ENISA, while protecting the security and commercial interests of the entity.
• Article 23(7) — public information. After consulting the entity concerned, the CSIRT, competent authority, or other authority designated may inform the public about the significant incident, or require the entity to do so, where public awareness is necessary to prevent or address an ongoing significant incident, or where disclosure of the significant incident is otherwise in the public interest.
• Article 23(8) — the single point of contact shall, at the request of the competent authority or the CSIRT, forward notifications received under Article 23(1) to the single points of contact of other affected Member States.
• Article 23(9) — single points of contact submit summary reports to ENISA every three months including anonymised and aggregated data on significant incidents, cyber threats, near misses, and significant cyber threats.
• Article 23(10) — where critical entities within the meaning of Directive (EU) 2022/2557 (CER) have notified significant incidents, incidents, cyber threats and near misses under Article 23(1) and Article 30, the CSIRTs or competent authorities provide that information to the competent authorities designated under the CER Directive.
• Article 23(11) — the Commission may adopt implementing acts further specifying the type of information, the format and the procedure of a notification submitted under Article 23(1) and Article 30, and of a communication submitted under Article 23(2). Article 23(11) is the legal basis on which Implementing Regulation (EU) 2024/2690 (significant-incident criteria for digital-infrastructure entity types) was adopted.

How to operationalize Article 23 in Modulos

Layer	Modulos surface	Coverage
Organization-level governance	OFF-15 with ORF-350–ORF-354, ORF-358–ORF-360	Art 23(1)–(4), authority feedback capture, recipient notification; supervisory cooperation under Articles 32–33
AI-service execution	MFF-15 with MRF-286–MRF-290, MRF-291, MRF-292	Art 23(3) determination, four-stage timeline, trust-service derogation, Implementing Reg 2024/2690 criteria
Voluntary / information-sharing	OFF-15 ORF-358 (Art 29 information-sharing arrangements) and ORF-359 (Art 30 voluntary notification)	Conditional applicability — when the organisation participates

A typical setup:

1. Requirements — Article 23 obligations are recorded as requirements on the relevant project (OFF-15 organisation, MFF-15 AI service). Fulfilment tracks through Not fulfilled → Fulfilled (with optional Out of scope).
2. Controls — implemented procedures (significance-classification SOP, early-warning template, 72-hour notification template, final-report template, recipient-communication template, authority feedback intake) are documented as named controls and mapped to one or more requirements.
3. Evidence — actual notification artefacts (timestamped early warnings, 72-hour notifications, intermediate reports, final reports, recipient communications, authority responses) are recorded as evidence and linked to the relevant Article 23 requirements. This is how the staged reports persist for audit.
4. Readiness + fulfilment attestation — a requirement becomes ready for review once all linked controls are in a final state; the requirement owner attests fulfilment for the project scope.
5. No dedicated incident-reporting UI surface. Modulos does not provide a dedicated incident-reporting workflow surface; the staged reports themselves are stored as evidence against the relevant Article 23 requirement, with timestamp and authority recipient captured.

Cross-framework mapping (preview)

NIS2 area	ISO/IEC 27001:2022 (Amd 1:2024)	DORA (Regulation (EU) 2022/2554)	EU AI Act (Regulation (EU) 2024/1689)
Significance determination (Art 23(3))	Annex A.5.25 (assessment of information security events)	Art 18 (classification of ICT-related incidents), 2024/1772 (incident classification RTS)	Art 73 (serious incident reporting)
24-hour early warning (Art 23(4)(a))	(no direct equivalent)	(DORA initial reporting is sequenced through 2025/301 RTS time limits)	Art 73(2) reporting timeframes (where applicable)
72-hour incident notification (Art 23(4)(b))	A.5.24 (planning), A.5.25	2025/301 (RTS on content and time limits); 2025/302 (ITS on forms and templates)	(not directly mapped)
One-month final report (Art 23(4)(d))	A.5.27 (learning from incidents)	DORA final reporting under 2025/301	(not directly mapped)
Recipient notification (Art 23(1)–(2))	(transparency / communication controls)	(no direct equivalent for the recipient notification limb)	Art 50 (transparency to natural persons for in-scope AI)
Public information (Art 23(7))	(not directly mapped)	(not directly mapped)	(not directly mapped)

For the pairwise treatment with DORA see NIS2 vs DORA.

Related pages

NIS2 overview

Framework structure, dates, OFF-15 / MFF-15 split

Scope and applicability

Article 2 scope, Article 3 classification, jurisdiction

Cybersecurity measures (Article 21)

The ten Article 21(2) categories quoted verbatim

Operationalizing in Modulos

Practical rollout sequence for OFF-15 and MFF-15

NIS2 vs DORA

Where each applies and how Article 23 reporting compares to DORA Articles 17–19

Source attribution

Directive (EU) 2022/2555 of the European Parliament and of the Council of 14 December 2022 on measures for a high common level of cybersecurity across the Union (NIS2) is published in the Official Journal of the European Union L 333, 27.12.2022, pp. 80–152. Article 23(1) (first subparagraph), Article 23(2), Article 23(3), the Article 23(4) opening sentence, Article 23(4)(a)–(e), and the trust-service derogation paragraph in Article 23(4) on this page are quoted verbatim from that OJ text for legal-citation purposes. Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 is published in OJ L 2024/2690 of 18.10.2024.

Disclaimer

This page is for general informational purposes and does not constitute legal advice. NIS2 takes effect in each Member State through national transposing law; in particular, the identity of the CSIRT and the competent authority, sectoral notification routing, and any national-specific reporting templates are matters of national law. For binding interpretation in your jurisdiction, consult the published EUR-Lex text and qualified counsel.