Building and evidencing ICT risk management under the DORA full framework

This page applies to the full framework under Articles 5 to 15 DORA, for example for CRR credit institutions, insurance undertakings, fund management companies and payment institutions. Which framework applies to you is covered on our page DORA applicability. Institutions under the simplified framework, including factoring and leasing firms from 1 January 2027, apply Article 16, there too with a BIA and recovery objectives, see DORA Article 16: the simplified framework.

What does DORA require for ICT risk management?

DORA requires a sound, comprehensive and well-documented ICT risk management framework as part of the overall risk management system (Article 6(1)), with strategies, policies, procedures, ICT protocols and tools (Article 6(2)). Articles 5 to 14 build it up, specified by Title II of Delegated Regulation (EU) 2024/1774 (“RTS” below, Articles 2 to 27) on the basis of Article 15.

The principle of proportionality applies to the whole of Chapter II, that is Articles 5 to 15 (Article 4(1)). Relief for microenterprises is covered in the FAQ below.

What does the management body have to do?

The management body bears the ultimate responsibility for managing ICT risk (Article 5(2)(a)). Among other things, it sets the roles and responsibilities of all ICT-related functions, approves the DOR strategy, the business continuity policy, the audit plans and the policy on the use of ICT services, allocates budget and sets up reporting channels (Article 5(2)). Its members keep their ICT knowledge up to date through regular training (Article 5(4)).

Article 5(3) also requires a role or a member of senior management to monitor the arrangements with ICT third-party service providers, see Managing ICT third-party service providers.

What goes into the DOR strategy?

The digital operational resilience strategy (DOR strategy) is part of the framework and sets out how it is implemented (Article 6(8)). It must cover eight points:

1. how the framework supports the business strategy and objectives,
2. the risk tolerance level for ICT risk and the impact tolerance for ICT disruptions,
3. clear information security objectives with key performance indicators and key risk metrics,
4. the ICT reference architecture and any changes needed,
5. the mechanisms used to detect and defend against incidents,
6. the current state of resilience, based on the major incidents reported and the effectiveness of preventive measures,
7. the implementation of resilience testing under Chapter IV,
8. a communication strategy for ICT-related incidents under Article 14.

An ICT multi-vendor strategy is optional (Article 6(9)).

DOR strategy and IT strategy: one or two?

DORA only requires the DOR strategy. The Regulation does not require an IT strategy as defined in BAIT or VAIT (BaFin’s supervisory requirements for IT in banks and insurers). Even so, the two cannot be treated as the same. BaFin sees the DOR strategy as focused on ICT risk management and the IT strategy as a broader strategy covering IT as a whole, “so that the two strategies cannot be equated” (supervisory notice of 8 July 2024, section 1.1, our translation). It sees the IT strategy as a possible link between the business strategy and the DOR strategy. DORA says nothing about form, and according to BaFin strategies can still be combined as appropriate.

What follows depends on the sector.

In a combined document, points a to h of Article 6(8) must be identifiable. We recommend a separate “DOR strategy” section so that the tolerance level and the testing programme do not get lost in IT planning. There is no DOR strategy under the simplified framework of Article 16. For the IT strategy there, see DORA Article 16: the simplified framework. Further interfaces with MaRisk are shown on our page MaRisk and DORA.

Who is the ICT risk control function?

Financial entities other than microenterprises assign the responsibility for managing and overseeing ICT risk to a control function with an appropriate level of independence (Article 6(4)). ICT risk management, control and internal audit must be segregated according to the three lines of defence model or an internal model. BaFin sees the function as very similar to the information security officer in position and independence, but not identical, because the information security officer is responsible for information security as a whole. It considers it sensible to develop the information security officer into the control function, in that case with the tasks of ICT risk management (supervisory notice of 8 July 2024, section 2.2). How the BAIT chapter on the information security officer maps to DORA is shown on our page BAIT and DORA.

Combining the compliance function and the control function: For institutions under MaRisk this is provided for: the explanatory note to AT 4.4.2 para. 3 names the ICT risk control function as an example of a function with which the compliance function may be combined. For this, the compliance function needs a direct reporting line to the management board and independence from the front office and trading units (AT 4.4.2 para. 3). For the control function, the requirement remains the appropriate independence under Article 6(4), evidenced for example by its own task description and a reporting line to the management board. There is no ICT risk control function under the Article 16 framework. There the RTS requires appropriate segregation and independence of control functions and internal audit (RTS Article 28(4)), see DORA Article 16.

In addition, for entities other than microenterprises, internal audit reviews the framework with ICT expertise in line with the audit plan, and critical findings go through a formal follow-up process (Article 6(6) and (7)). The frequency and outsourcing of the review are covered in the FAQ below.

Which policies and procedures does the framework need?

The RTS requires policies or procedures with general requirements for each topic (RTS Article 2(2)). Among other things, they must be aligned with the objectives of the DOR strategy, contain the date of approval by the management body, responsibilities and a register of the required documentation, and set out the segregation of duties. They are complemented by an inventory of residual risks with explanations, reviewed annually (RTS Article 3(d)).

The RTS does not specify how many documents this results in. In our reading, combining topics is permissible as long as every element of the RTS can still be found (example below).

Identification, protection and detection: Articles 8 to 10

In addition to the table above, some deadlines and specific requirements:

Identification (Article 8): Classification and risk scenarios are reviewed at least annually (paragraphs 1 and 2). Entities other than microenterprises assess legacy ICT systems annually and whenever new systems are connected (paragraph 7). How to classify the functions is shown on our page classifying critical or important functions.

Protection and prevention (Article 9, RTS Articles 6 to 21): Access rights for systems supporting critical or important functions must be updated at least every six months, for all other systems at least annually (RTS Article 21(e)(iv)). Privileged access is granted only on a need-to-use or ad hoc basis (RTS Article 21(e)(ii)), described in technical terms on our company page on privileged access under DORA (in German). For assets supporting critical or important functions, a register of all certificates must be kept, and certificates are renewed before they expire (RTS Article 7(4) and (5), see certificate register under RTS Article 7(4), in German).

Detection (Article 10): multiple layers of control and alert thresholds that trigger response processes.

Response and recovery: BIA and recovery objectives

Article 11 requires an ICT business continuity policy (paragraph 1), plans for the continuity of critical or important functions (paragraph 2), ICT response and recovery plans, subject to independent internal audit review for entities other than microenterprises (paragraph 3), and business continuity plans also for outsourced functions (paragraph 4). Testing takes place at least annually and after substantive changes to systems supporting critical or important functions, for entities other than microenterprises with scenarios of cyber-attacks and switchovers to redundant capacity (paragraph 6). Entities other than microenterprises need a crisis management function (paragraph 7).

Business impact analysis (Article 11(5)): It assesses the impact of severe business disruptions using quantitative and qualitative criteria and takes into account criticality, supporting processes, third-party dependencies and information assets.

Recovery objectives (Article 12(6)): For each function, financial entities set recovery time and recovery point objectives, taking into account whether it is a critical or important function. They are based on the BIA (RTS Article 24(1)(a)(i)) and recorded in the business continuity policy (RTS Article 24(1)(b)(ii)). The plans must meet these objectives and cover the scenarios in RTS Article 26(2), such as cyber-attacks or the failure of a service provider. The register of information also asks for them (template B_06.01).

Article 12 also requires segregated restoration systems (paragraph 3), redundant capacity for entities other than microenterprises (paragraph 4) and integrity checks (paragraph 7).

Learning and communication: Articles 13 and 14

After major incidents, the causes, response and communication are reviewed, and senior ICT staff report to the management body at least annually on findings from tests and incidents (Article 13(2) and (5)). Training applies to all staff and to senior management (Article 13(6)). Article 14 requires communication plans for clients, other financial entities and the public, and a designated person for the public and the media. Reporting to BaFin is covered on our page DORA incident reporting.

Example: framework outline of Muster-Kreditbank AG

Fictitious example, not a client. Muster-Kreditbank AG is a CRR credit institution with 140 employees, doing lending and deposit business with corporate and retail customers. A data centre service provider runs the core banking system, and a managed service provider (MSP) runs workstations and the network. After the first review of its framework, it restructured its documents as follows:

From the BIA, the bank has derived recovery objectives for its critical or important functions. The values are example values, DORA sets no figures for credit institutions:

Three typical gaps

How we help

For entities under the full framework, we start with the DORA gap analysis. It sets your framework against Articles 5 to 15 and the RTS and ranks the measures by urgency. Legal questions in an individual case are for you to clarify with your legal counsel.