ICT risk and resilience operations — DORA Articles 7–23

This page operationalises the heart of DORA: the ICT risk management framework set out in Articles 7–15 (with the simplified framework in Article 16), the ICT-related incident management process under Article 17, classification under Article 18, reporting under Articles 19–20, and operational / security payment-related incidents under Article 23. It quotes the most operationally critical Article wording verbatim from the published OJ text and explains how each obligation lands in Modulos.

Quick decision

• Setting up the ICT RMF → start with Article 6 (covered in Applicability and governance) then work through Articles 7–14 systematically. Delegated Regulation 2024/1774 specifies the technical standards.
• Eligible for the Article 16 simplified framework → the simplified RMF still applies Articles 17–19 reporting; only the RMF substance is adjusted.
• Detected an ICT-related incident → Article 17 governs detection and management; Article 18 governs classification; Article 19 governs reporting; Delegated Regulation 2025/301 sets content and time limits; Implementing Regulation 2025/302 sets forms and templates.
• Payment-related operational or security incident → Article 23 layers additional reporting obligations on top of Articles 17–19; PSD2 reporting expectations are integrated.
• Cross-applying with NIS2 Article 23 → DORA Article 1(2): for financial entities also identified as essential or important under national NIS2 transposition, DORA's Articles 17–19 regime applies in place of NIS2 Article 23 on the matters DORA covers.

TL;DR

• Articles 7–14 flesh out the ICT risk management framework: ICT systems and tools (Art 7); ICT asset and dependency identification (Art 8); protection and prevention (Art 9); detection (Art 10); response and recovery (Art 11); backup, restoration and recovery (Art 12); learning and evolving (Art 13); crisis communication (Art 14).
• Article 15 mandates Delegated Regulation (EU) 2024/1774 as the technical standards for the framework; Article 16(3) does the same for the simplified framework.
• Article 17 establishes the ICT-related incident management process; Article 18 sets classification criteria and materiality thresholds (with the RTS in Delegated Regulation (EU) 2024/1772); Article 19 sets the reporting regime, with content/time limits in Delegated Regulation (EU) 2025/301 and forms/templates in Implementing Regulation (EU) 2025/302.
• Article 20 is the Level 2 mandate that produced 2025/301 and 2025/302.
• Article 23 addresses operational or security payment-related incidents in addition to the Articles 17–19 regime.

Primary source

Regulation (EU) 2022/2554 on EUR-Lex (CELEX 32022R2554) — Articles 7–23 · Delegated Regulation (EU) 2024/1774 (ICT RMF + simplified RMF RTS) · Delegated Regulation (EU) 2024/1772 (incident classification RTS) · Delegated Regulation (EU) 2025/301 (incident report content/time limits RTS) · Implementing Regulation (EU) 2025/302 (incident report forms/templates ITS)

Articles 7–14 — the ICT risk management framework substance

Article 7 — ICT systems, protocols and tools

Article 7 requires financial entities to use and maintain updated ICT systems, protocols and tools that fulfil specific characteristics: appropriate to the magnitude of operations supporting their activities; reliable; equipped with sufficient capacity to accurately process the data necessary for the performance of activities and the timely provision of services; and technologically resilient to handle additional information processing needs as required under stressed market conditions or other adverse situations. Modulos ORF-367 (governance) and MRF-294 (execution) carry this obligation.

Article 8 — identification (asset and dependency inventory)

Article 8(1) is the asset-inventory cornerstone:

As part of the ICT risk management framework referred to in Article 6(1), financial entities shall identify, classify and adequately document all ICT supported business functions, roles and responsibilities, the information assets and ICT assets supporting those functions, and their roles and dependencies in relation to ICT risk. Financial entities shall review as needed, and at least yearly, the adequacy of this classification and of any relevant documentation.

Article 8(2)–(3) require continuous ICT risk identification of all sources of ICT risk, including from third-party providers, and continuous vulnerability assessment. Article 8(4)–(7) require an up-to-date inventory of information and ICT assets (including premises, off-site, and third-party-hosted), identification of critical dependencies, and the recording of all changes. Modulos ORF-368–ORF-369 (governance) and MRF-295–MRF-296 (execution).

Article 9 — protection and prevention

Article 9 requires financial entities to monitor and control the security and functioning of ICT systems, minimise the impact of ICT risk through deployment of appropriate tools, policies and procedures, and put in place mechanisms to promptly detect anomalous activities, including ICT network performance issues and ICT-related incidents. Article 9(2)–(4) detail the policies covering security of network and information systems, identity management, access management, ICT-related operations security, and ICT change management. Modulos ORF-370 and MRF-297.

Article 10 — detection

Article 10 requires financial entities to have mechanisms to detect anomalous activities, including ICT-network-performance issues and ICT-related incidents, and to identify potential material single points of failure. Article 10(2)–(3) require multiple layers of control, defined alert thresholds and criteria to trigger and initiate ICT-related incident response processes. Modulos ORF-371 and MRF-298.

Article 11 — response and recovery

Article 11(1) requires financial entities to put in place a comprehensive ICT business continuity policy as an integral part of the operational business continuity policy. Article 11(2)–(9) detail what the policy and the supporting plans must contain: ICT business continuity plans; ICT response and recovery plans; testing of those plans at least yearly; crisis management arrangements; communications with relevant stakeholders. Article 11(10)–(11) require financial entities (other than microenterprises) to estimate aggregated annual costs and losses caused by major ICT-related incidents and report them upon request. Modulos ORF-372, ORF-380 and MRF-299.

Article 12 — backup, restoration, and recovery

Article 12 requires financial entities to develop and document backup policies and procedures, and restoration and recovery procedures and methods. Article 12(2)–(7) cover backup tests, recovery objectives, redundant ICT capacities, the relationship between primary and backup processing sites, and the separation between primary and backup data. Modulos ORF-373 and MRF-300.

Article 13 — learning and evolving

Article 13(1) requires financial entities to have capabilities and staff to gather information on vulnerabilities and cyber threats, ICT-related incidents (in particular cyber-attacks), and analyse their likely impact on their digital operational resilience. Article 13(2)–(7) require post-incident reviews after major ICT-related incidents, awareness-raising programmes, and ICT security awareness programmes and digital operational resilience training. Modulos ORF-374 and MRF-301.

Article 14 — crisis communication

Article 14(1) requires financial entities, as part of the ICT risk management framework, to have in place crisis communication plans enabling a responsible disclosure of, at least, major ICT-related incidents or vulnerabilities to clients and counterparts and, as relevant, to the public. Article 14(2) requires the implementation of communication policies for staff and for external stakeholders. Article 14(3) requires the designation of at least one person tasked with implementing the communication strategy for ICT-related incidents and tasked with the public and media function. Modulos ORF-375.

Articles 15–16 — RTS mandates

Article 15 mandates the ESAs to develop the Article 6 ICT risk management framework RTS — delivered as Delegated Regulation (EU) 2024/1774. Article 16(3) does the same for the simplified framework, also covered by 2024/1774.

Article 17 — ICT-related incident management process

Article 17(1) sets the cornerstone obligation:

Financial entities shall define, establish and implement an ICT-related incident management process to detect, manage and notify ICT-related incidents.

Article 17(2) requires financial entities to record all ICT-related incidents and significant cyber threats. Article 17(3) lists the elements the process shall include — among others: early warning indicators; procedures to identify, track, log, categorise and classify ICT-related incidents according to their priority and severity and according to the criticality of the services impacted; roles and responsibilities for different incident types; communication plans pursuant to Article 14; reporting procedures pursuant to Article 19. Modulos ORF-376 and MRF-302.

Article 18 — classification of ICT-related incidents and cyber threats

Article 18(1) sets the classification framework:

Financial entities shall classify ICT-related incidents and shall determine their impact based on the following criteria:

(a) the number and/or relevance of clients or financial counterparts affected and, where applicable, the amount or number of transactions affected by the ICT-related incident, and whether the ICT-related incident has caused reputational impact;

(b) the duration of the ICT-related incident, including the service downtime;

(c) the geographical spread with regard to the areas affected by the ICT-related incident, particularly if it affects more than two Member States;

(d) the data losses that the ICT-related incident entails, in relation to availability, authenticity, integrity or confidentiality of data;

(e) the criticality of the services affected, including the financial entity’s transactions and operations;

(f) the economic impact, in particular direct and indirect costs and losses, of the ICT-related incident in both absolute and relative terms.

Article 18(2) similarly classifies cyber threats as significant by reference to a set of criteria. Article 18(3) mandates the ESAs to develop the RTS on classification criteria, materiality thresholds, and details of reports of major ICT-related incidents — delivered as Delegated Regulation (EU) 2024/1772. Modulos ORF-377 and MRF-303.

Article 19 — reporting of major ICT-related incidents

Article 19(1) is the reporting cornerstone:

Financial entities shall report major ICT-related incidents to the relevant competent authority as referred to in Article 46 in accordance with paragraph 4 of this Article.

Article 19(2) provides voluntary notification of significant cyber threats. Article 19(3) addresses notification to clients in the event of a major incident that has an impact on the financial interests of clients. Article 19(4) requires financial entities to submit:

• an initial notification within the time limit specified by the RTS adopted under Article 20;
• an intermediate report following the initial notification, no later than the time limit specified by the RTS, including any relevant status update;
• a final report, no later than the time limit specified by the RTS, including the root cause analysis.

The Article 20(a) RTS — Delegated Regulation (EU) 2025/301 — sets the content and time limits; Implementing Regulation (EU) 2025/302 lays down the standard forms, templates, and procedures for the initial, intermediate, and final reports.

Article 19(5) requires the competent authority to acknowledge receipt of the initial notification and, where feasible, provide feedback to the financial entity, and, where necessary, distribute the notification to other Union authorities (ECB, ENISA, EBA, EIOPA, ESMA, ESRB, the competent authority designated under NIS2, the single points of contact designated under NIS2). Modulos ORF-378–ORF-379, MRF-304.

Article 20 — harmonisation of reporting content and templates

Article 20(a) mandates the ESAs to develop, in consultation with the ECB and ENISA, common draft regulatory technical standards further specifying both (i) the content of the reports for major ICT-related incidents and the voluntary notifications for significant cyber threats, and (ii) the time limits for the initial notification, intermediate report and final report. That mandate produced Delegated Regulation (EU) 2025/301. Article 20(b) is a separate mandate for common draft implementing technical standards establishing the standard forms, templates and procedures — produced as Implementing Regulation (EU) 2025/302.

Article 23 — operational or security payment-related incidents

Article 23 layers additional obligations on financial entities providing payment services. For operational or security payment-related incidents, Article 23 references the application of Articles 17, 18 and 19, with sector-specific adjustments. Modulos ORF-381 carries the cohort-specific governance.

How to operationalize Articles 7–23 in Modulos

Layer	Modulos surface	Coverage
ICT RMF substance	OFF-16 ORF-367–ORF-375; MFF-16 MRF-294–MRF-301	Articles 7–14
Aggregated cost reporting	OFF-16 ORF-380	Article 11(10)–(11)
Incident management process	OFF-16 ORF-376; MFF-16 MRF-302	Article 17
Incident classification	OFF-16 ORF-377; MFF-16 MRF-303	Article 18 + Delegated Reg 2024/1772
Incident reporting	OFF-16 ORF-378; MFF-16 MRF-304	Article 19 + Delegated Reg 2025/301 (Art 20(a) RTS) + Implementing Reg 2025/302 (Art 20(b) ITS)
Voluntary cyber-threat notification	OFF-16 ORF-379	Article 19(2)
Payment-related incident reporting	OFF-16 ORF-381	Article 23 + PSD2 integration

A typical setup:

1. Requirements — each Article 7–23 obligation is recorded as a requirement on the relevant project. Fulfilment tracks through Not fulfilled → Fulfilled (with optional Out of scope for entity-type-specific exemptions).
2. Controls — implemented arrangements (ICT asset inventory, vulnerability-management programme, identity-and-access policy, change-management policy, BC/DR plan, crisis-communication plan, incident-handling SOP, classification methodology aligned with 2024/1772 criteria, reporting templates aligned with 2025/302 forms) are documented as named controls.
3. Evidence — ICT-asset inventory documents, vulnerability scan outputs, IAM matrix, change records, BC/DR test outputs, incident postmortems, classification worksheets, executed incident notifications (initial / intermediate / final) are recorded once and linked to multiple controls.
4. Readiness + fulfilment attestation — a requirement becomes ready for review once all linked controls are in a final state; the requirement owner attests fulfilment.
5. Operationalisation gaps to call out honestly: Modulos does not provide a dedicated DORA incident-reporting UI surface; incident notifications under Articles 19 / 23 are stored as evidence linked to the relevant requirement. The ICT asset inventory under Article 8(4)–(7) is modelled as evidence linked to MRF-295 rather than a dedicated inventory UI.

Cross-framework mapping (preview)

DORA area	NIS2 (Directive (EU) 2022/2555)	ISO/IEC 27001:2022 (Amd 1:2024)
Art 7 ICT systems and tools	Art 21(2)(a) policies, (e) acquisition / development / maintenance	Annex A.5, A.8
Art 8 asset identification	Art 21(2)(i) asset management	A.5.9 (inventory of information and other assets)
Art 9 protection and prevention	Art 21(2)(a), (h), (i)	A.5–A.8 controls family
Art 10 detection	Art 21(2)(b) incident handling (detection sub-element)	A.8.16 (monitoring activities)
Art 11 response and recovery + Art 12 backup	Art 21(2)(c) business continuity	A.5.29, A.5.30, A.8.13 (backup)
Art 13 learning	Art 21(2)(f) effectiveness assessment	A.5.27 (learning from incidents)
Art 14 crisis communication	Art 23(1) recipient notification	A.5.5 (contact with authorities)
Art 17 incident management	Art 23(1) and Art 21(2)(b)	A.5.24, A.5.25, A.5.26
Art 18 classification	Art 23(3) significance test	A.5.25 (assessment)
Art 19 reporting	Art 23(4) staged timelines	A.5.26 (response)
Art 23 payment incidents	(no NIS2 equivalent — sector specific)	(no direct equivalent)

For the pairwise NIS2↔DORA treatment see NIS2 vs DORA.

Related pages

Applicability and governance

Article 1–6, 16 — scope, proportionality, management body, ICT RMF foundation

Testing and third-party risk

Articles 24–30 — testing, TLPT, register of information, subcontracting

Information sharing and Level 2 acts

Article 45 + the eight Commission Delegated / Implementing Regulations

Operationalizing in Modulos

Practical rollout sequence for OFF-16 and MFF-16

NIS2 vs DORA

Where each applies and how Articles 17–19 compare to NIS2 Article 23

Source attribution

Regulation (EU) 2022/2554 (DORA) is published in the Official Journal of the European Union L 333, 27.12.2022, pp. 1–79. Articles 8(1), 17(1), 18(1) including the six criteria (a)–(f), and 19(1) on this page are quoted verbatim from that OJ text for legal-citation purposes. Commission Delegated Regulation (EU) 2024/1774 (ICT RMF + simplified RMF RTS), (EU) 2024/1772 (incident classification RTS), (EU) 2025/301 (incident report content / time limits RTS), and Implementing Regulation (EU) 2025/302 (incident report forms / templates ITS) are individually published on EUR-Lex.

Disclaimer

This page is for general informational purposes and does not constitute legal advice. DORA applies directly in every Member State; binding obligations and supervisory authorities are determined by the Regulation, the applicable Level 2 acts, and the competent authority designated under Article 46. For binding interpretation in your jurisdiction, consult the published EUR-Lex text and qualified counsel.