DORA ICT Risk Management Framework: Article-by-Article Guide

“Financial entities shall have in place an internal governance and control framework that ensures an effective and prudent management of ICT risk, in accordance with Article 6(4), in order to achieve a high level of digital operational resilience.”

DORA Article 5(1). Note the cross-reference to Article 6(4), the requirement for an independent ICT risk control function. It is routinely dropped when this sentence is quoted, and it is the part that has organisational consequences.

Why the RTS numbering matters

The cross-reference table is usually the cheapest thing in a framework document to spot-check, and it reveals whether the drafting was done from the text or from a summary of the text. A mapping that sends Chapter 4 to “RTS Articles 8 to 17” when the protection controls actually run across Articles 6 to 21 is a self-inflicted finding. Build the table from the Official Journal text, and keep it current, because these standards are amended.

Chapter 1

Governance and Responsibilities

Maps to: DORA Art. 5, Art. 6(1)-(7) | RTS (EU) 2024/1774 Art. 2, Art. 3

• Management body duties, mapped one by one to Article 5(2), points (a) to (i)
• The ICT risk control function and its independence (Art. 6(4))
• The ICT risk tolerance level, set as part of the resilience strategy (Art. 6(8)(b))
• Budget allocation (Art. 5(2)(g)) and the framework review cycle (Art. 6(5))
• The date of formal approval by the management body, which RTS Art. 2(2)(b) requires the security policy to state

Chapter 2

ICT Asset Management and Classification

Maps to: DORA Art. 8(1), 8(4), 8(6) | RTS (EU) 2024/1774 Arts. 4-5

• The ICT asset and information asset inventory
• The classification scheme and criticality mapping
• Links and interdependencies between assets, which Art. 8(4) requires you to map
• Inventory update triggers, including on each major change (Art. 8(3), 8(6))

Chapter 3

Risk Identification and Assessment Methodology

Maps to: DORA Art. 8(2), 8(3), 8(7) | RTS (EU) 2024/1774 Art. 3

• Continuous identification of ICT risk sources, with risk scenarios reviewed at least yearly (Art. 8(2))
• A risk assessment on each major change to infrastructure, processes or procedures (Art. 8(3))
• A yearly specific ICT risk assessment on all legacy ICT systems (Art. 8(7))
• Residual risk acceptance, recorded against a named accountable role

Chapter 4

Protection and Prevention Controls

Maps to: DORA Art. 9 | RTS (EU) 2024/1774 Arts. 6-21

• Information security policy (Art. 9(4)(a))
• Network and infrastructure management, including the ability to sever or segment connections instantaneously (Art. 9(4)(b); RTS Arts. 13-14)
• Limitation of physical and logical access (Art. 9(4)(c); RTS Arts. 18-21)
• Strong authentication and protection of cryptographic keys (Art. 9(4)(d); RTS Arts. 6-7)
• ICT change management, approved by appropriate lines of management (Art. 9(4)(e); RTS Arts. 15-17)
• Patch and update policies (Art. 9(4)(f); RTS Art. 10)

Chapter 5

Detection and Monitoring

Maps to: DORA Art. 10 | RTS (EU) 2024/1774 Art. 12, Art. 23

• Anomaly detection with multiple layers of control and defined alert thresholds (Art. 10(2))
• Logging: what is logged, how long it is kept, and how it is protected from tampering (RTS Art. 12)
• Identification of potential material single points of failure (Art. 10(1))
• Regular testing of the detection mechanisms themselves (Art. 10(1), second subparagraph)

Chapter 6

Response and Recovery

Maps to: DORA Art. 11, Art. 12 | RTS (EU) 2024/1774 Art. 22, Arts. 24-26

• The ICT business continuity policy and the response and recovery plans (Art. 11(1), 11(3))
• A business impact analysis using quantitative and qualitative criteria (Art. 11(5))
• Recovery time and recovery point objectives determined per function (Art. 12(6))
• A crisis management function (Art. 11(7)) and records of activity during disruption (Art. 11(8))
• Yearly testing, including cyber-attack scenarios and switchover to redundant capacity (Art. 11(6))

Chapter 7

Testing Programme

Maps to: DORA Arts. 24-27 | RTS on TLPT (EU) 2025/1190

• The resilience testing programme as an integral part of the framework (Art. 24(1))
• Yearly testing of all ICT systems and applications supporting critical or important functions (Art. 24(6))
• The test types listed in Art. 25(1), from vulnerability scans to end-to-end and penetration testing
• Threat-led penetration testing for the entities identified under Art. 26, governed by Delegated Regulation (EU) 2025/1190
• Procedures to prioritise, classify and remedy every issue the tests reveal, plus internal validation that they are fully addressed (Art. 24(5))

Chapter 8

Third-Party Risk Integration

Maps to: DORA Arts. 28-30 | RTS (EU) 2024/1773, RTS (EU) 2025/532, ITS (EU) 2024/2956

• The strategy on ICT third-party risk, including the policy on ICT services supporting critical or important functions (Art. 28(2); RTS (EU) 2024/1773)
• The pre-contractual assessment and due diligence in Art. 28(4)
• The preliminary assessment of ICT concentration risk (Art. 29)
• Subcontracting of services supporting critical or important functions (Art. 30(2)(a); RTS (EU) 2025/532)
• Exit strategies and transition plans (Art. 28(8))
• The register of information (Art. 28(3); ITS (EU) 2024/2956)

Chapter 9

Reporting and Communication

Maps to: DORA Art. 14, Arts. 17-19 | RTS (EU) 2024/1772, RTS (EU) 2025/301

• Crisis communication plans and the named person for the public and media function (Art. 14(1), 14(3))
• Incident classification against the criteria and materiality thresholds in Delegated Regulation (EU) 2024/1772 (Art. 18)
• The notification deadlines in Delegated Regulation (EU) 2025/301, Article 5, set out in Section 4 below
• Management body reporting: at minimum the yearly report from senior ICT staff (Art. 13(5)) and the reporting channels required by Art. 5(2)(i)

Chapter 10

Review and Continuous Improvement

Maps to: DORA Art. 6(5), Art. 13 | RTS (EU) 2024/1774 Art. 27

• The four review triggers in Art. 6(5): at least yearly, on major ICT-related incidents, following supervisory instructions, and on conclusions from resilience testing or audit
• Post-incident reviews, and the four effectiveness questions in Art. 13(2), points (a) to (d)
• Feeding testing and incident lessons back into the risk assessment process (Art. 13(3))
• Key performance indicators and key risk metrics, which Art. 6(8)(c) requires the resilience strategy to set out
• The format and content of the framework review report (RTS Art. 27)

The proportionality principle, in the words of the regulation

“Financial entities shall implement the rules laid down in Chapter II in accordance with the principle of proportionality, taking into account their size and overall risk profile, and the nature, scale and complexity of their services, activities and operations.”

DORA Article 4(1). Proportionality calibrates depth. It does not delete chapters. Article 4(3) adds that competent authorities “shall consider the application of the proportionality principle by financial entities when reviewing the consistency of the ICT risk management framework” on the basis of the reports submitted under Article 6(5). The rationale is itself reviewable, so write it down.

1. The board accountability chain

Article 5(2) does not say “the board approves the framework” and stop. It lists nine duties, points (a) to (i), and each one is an evidence question. Point (f) is the ICT internal audit plan. Point (g) is budget. Point (i) is a set of corporate-level reporting channels covering third-party arrangements, planned material changes to them, and at least major ICT-related incidents. If the management body appears in your framework only once, in an approval block, the document does not cover Article 5(2).

2. Inventory completeness

Article 8(4) requires you to identify all information and ICT assets “including those on remote sites, network resources and hardware equipment”, map those considered critical, and map “the links and interdependencies between the different information assets and ICT assets”. An asset list without the dependency map does not satisfy the article, and the dependency map is the part that takes time to build.

3. The risk, control, test, risk loop

Article 13(3) requires that lessons from resilience testing, from real incidents, and from the activation of continuity plans “shall be duly incorporated on a continuous basis into the ICT risk assessment process”, and that those findings “shall form the basis for appropriate reviews of relevant components of the ICT risk management framework”. A framework that describes risks in one chapter and controls in another, with no documented path between them, cannot evidence this.

4. Continuity testing that actually happened

Article 11(6)(a) requires the continuity plans and the response and recovery plans to be tested “at least yearly, as well as in the event of any substantive changes to ICT systems supporting critical or important functions”. For entities other than microenterprises, the testing plans must include scenarios of cyber-attacks and switchovers between the primary infrastructure and the redundant capacity.

5. The notification clock

The reporting deadlines are not in DORA Article 19, which defers them to the technical standards. They are in Article 5 of Delegated Regulation (EU) 2025/301, and the initial deadline has two limbs rather than one. If the framework prints the wrong clock, the incident response runbook underneath it will inherit the error.

6. Concentration risk, before you sign

Article 29(1) requires that when you perform the risk identification under Article 28(4)(c), you also take into account whether the envisaged contract would lead to the situations Article 29 lists. That makes it a pre-contractual gate in the procurement process, not a yearly reporting exercise, and the framework has to place it there.

The notification clock, stated correctly

DORA Article 19(4) requires an initial notification, an intermediate report and a final report, but it does not set the deadlines. It defers them to the technical standards. They are in Article 5(1) of Delegated Regulation (EU) 2025/301:

• Initial notification: “as early as possible, but in any case, within four hours from the classification of the ICT-related incident as a major ICT-related incident and no later than 24 hours from the moment the financial entity has become aware of the ICT-related incident”. Two limbs, not one. The four-hour clock starts at classification. The 24-hour clock starts at awareness.
• Intermediate report: “at the latest within 72 hours from the submission of the initial notification”, and it is due even where the status or handling of the incident has not changed.
• Final report: “no later than one month after either the submission of the intermediate report, or, where applicable, after the latest updated intermediate report”. The month runs from the intermediate report, not from the incident.

Article 5(4) allows a deadline that falls on a weekend or a bank holiday to move to noon of the next working day, and Article 5(5) withdraws that relief for the initial notification and the intermediate report from credit institutions, central counterparties, operators of trading venues, and entities identified as essential or important under Directive (EU) 2022/2555. A framework that prints “4h / 72h / 1 month” and stops is wrong in three separate places.

The test to apply to every sentence

For every policy statement in the framework, ask what artefact proves it is happening. If the answer is nothing, there are two honest options: change the statement to describe what you actually do, or build the process before the document goes to the board. A framework describing an organisation you do not have is worse than a thinner one describing the organisation you do, because Article 6(3) obliges you to provide complete and updated information on the framework to the competent authority upon request.

A board governance calendar earns its place

These duties are periodic, and the regulation says so. The phrase “approve and periodically review” recurs through Article 5(2). The framework review carries the four triggers in Article 6(5). Senior ICT staff report at least yearly under Article 13(5). An appendix that turns each of these into a dated board deliverable with a named owner converts an abstract obligation into something a company secretary can track, and into a minute that evidences it happened.

Recommended document hierarchy

Level 1, the ICT Risk Management Framework. Board-approved, strategic, reviewed on the Article 6(5) triggers.

Level 2, policies. Information security, ICT business continuity, access control, ICT third-party risk.

Level 3, standards. Cryptography, patching, logging, network segmentation.

Level 4, procedures. Incident response runbook, recovery switchover procedure, access certification, vulnerability scanning.