Contents

ICT Risk Management under DORA and Delegated Regulation (EU) 2024/1774

ICT Risk Management under DORA and Delegated Regulation (EU) 2024/1774

ICT Risk Management has become a core supervisory focus in the EU financial sector. With the Digital Operational Resilience Act (DORA), ICT risk is no longer a side-topic of operational risk – it is a fully fledged regulatory discipline with its own rules, controls and reporting duties.

This article explains how ICT risk management is understood under DORA and how Commission Delegated Regulation (EU) 2024/1774 (“RTS on ICT risk management”) translates these principles into very concrete tools, methods, processes and policies.

What is ICT Risk Management?

In simple terms, ICT risk management is the set of strategies, processes and controls that ensure:

the confidentiality, integrity and availability of data and systems, and
the ability of a financial entity to withstand, respond to and recover from ICT incidents without losing critical services.

Under DORA, this is not just “good practice” – it is a binding, harmonised EU requirement for a wide range of financial entities (banks, insurers, investment firms, payment institutions, CCPs, CSDs, trading venues and more).

DORA’s ICT Risk Management Framework (Article 6 DORA)

1. ICT risk management as the first DORA pillar

DORA is built on five pillars:

ICT risk management framework
ICT incident management, classification and reporting
Digital operational resilience testing
ICT third-party risk management and oversight
Information sharing on cyber threats

The ICT risk management framework is the first pillar and the foundation for all other requirements.

2. Core obligation: a sound, comprehensive and documented framework

Article 6 DORA requires financial entities to maintain a sound, comprehensive and well-documented ICT risk management framework as part of their overall risk management system. It must enable entities to address ICT risk quickly, efficiently and comprehensively and ensure a high level of digital operational resilience.

This framework must cover:

Strategy and governance for digital operational resilience (Article 6 DORA)
Systems, protocols and tools for ICT risk (Article 7 DORA)
Identification, protection, detection, response, recovery and learning (Articles 8–13 DORA)
Internal and external communication during ICT incidents (Article 14 DORA)

In other words: ICT risk management is not a single policy – it is a closed control loop from strategy to continuous improvement.

What Delegated Regulation (EU) 2024/1774 Adds

Article 15 DORA mandated the ESAs (EBA, EIOPA, ESMA) to draft Regulatory Technical Standards (RTS) to further harmonise ICT risk management tools, methods, processes and policies and to create a simplified framework for smaller entities.

This resulted in Commission Delegated Regulation (EU) 2024/1774, which:

details the “ordinary” ICT risk management framework for all in-scope entities, and
defines a simplified ICT risk management framework for smaller entities under Article 16 DORA.

The RTS therefore answers the practical question:

“What exactly has to be in our ICT policies, procedures and tools to be DORA-compliant?”

Key Elements of ICT Risk Management under Delegated Regulation 2024/1774

Below is a structured overview of what the RTS expects from an ICT risk management framework in practice.

1. ICT security policies, procedures, protocols and tools

The RTS requires financial entities to develop a coherent set of ICT security policies and procedures, embedded in the ICT risk management framework and aligned with the digital operational resilience strategy.

These policies must, at a minimum:

secure networks and protect against intrusions and data misuse
preserve availability, authenticity, integrity and confidentiality of data (including cryptography)
guarantee accurate and prompt data transmission without undue disruption

They must also include:

clear responsibilities across the three lines of defence, including segregation of duties
indicators and measures to monitor implementation and handle exceptions
recognition of leading industry standards (e.g. ISO/EN standards)
documentation, review and update procedures in line with DORA Article 6(5).

2. ICT risk management policy and procedures

The RTS translates the high-level DORA obligation into concrete requirements for ICT risk management processes, including:

Risk tolerance level for ICT risk, formally approved and documented
A methodology for ICT risk assessment:
- identification of vulnerabilities and threats to business functions, systems and assets
- qualitative or quantitative impact and likelihood indicators
A structured ICT risk treatment process, including:
- documentation of chosen measures
- monitoring of their effectiveness and alignment with risk tolerance
Residual ICT risk management:
- inventory of accepted residual risks, justification, annual review
- roles for risk acceptance and re-assessment
Continuous monitoring of:
- ICT risk and cyber-threat landscape
- internal and external vulnerabilities
- changes in business strategy or digital operational resilience strategy

This transforms ICT risk management into a living process, not a onetime assessment.

3. ICT asset management

The RTS requires a full inventory and lifecycle management of ICT assets, with special focus on:

unique identifiers, locations, owners and supported business functions
classification of assets and their criticality
exposure to external networks (e.g. internet-facing systems)
end dates of vendor or third-party support, especially for critical systems (legacy risk)

This enables targeted risk assessments and supports decisions on upgrades, decommissioning and compensating controls.

4. Encryption, cryptographic controls and key management

Under Articles on encryption, entities must:

define a policy on encryption and cryptographic controls, based on data classification and ICT risk assessment
cover encryption of data at rest, in transit and, where necessary, in use
secure internal and external network connections
define criteria for selecting cryptographic techniques (aligned with recognised standards)
implement cryptographic key management across the full key lifecycle (generation, storage, renewal, revocation, destruction)

The RTS explicitly recognises evolving cryptanalysis and quantum threats, requiring periodic review and, if necessary, compensating monitoring measures.

5. ICT operations, vulnerability & patch management, logging and network security

The RTS provides very detailed expectations for operational ICT controls, including:

ICT operations: secure installation, configuration and de-installation; backup and restore; error handling; separation of production and non-production environments; exceptional testing in production under strict conditions.
Vulnerability and patch management: weekly automated scans for critical/important assets; tracking of third-party libraries; oversight of ICT third-party fixes; prioritised patch deployment.
Data & system security: secure baselines, anti-malware, endpoint protection, secure deletion and disposal of media, data-loss prevention, telework safeguards.
Logging: defined log events, retention periods, integrity protection of log data, time synchronisation.
Network security: segmentation, dedicated admin networks, encrypted connections, firewall rule governance and regular review of rules for systems supporting critical functions.

In practice, this reads like a minimum security configuration baseline for any DORA-regulated entity.

6. Physical, environmental, human and access-control aspects

The RTS also extends ICT risk management into non-technical dimensions:

Physical and environmental security of premises, data centres and sensitive areas
Human resources policy covering ICT responsibilities, awareness and asset return on exit
Identity management and access control:
- unique identities and account lifecycle management
- least-privilege and need-to-know access
- restrictions on shared accounts, strong authentication, periodic review of access rights
- physical access controls, logging and monitoring

This ensures that ICT risk management is fully integrated into the organisation and culture, not only technology.

7. ICT business continuity, response & recovery and reporting

Finally, the RTS specifies detailed requirements for:

ICT business continuity policies and their components (objectives, scope, governance, activation criteria, alignment with overall BCM, crisis communication)
Testing of ICT business continuity plans, including severe but plausible scenarios, ICT third-party disruptions and switchovers to redundant capacity
ICT response and recovery plans with defined scenarios (cyber-attacks, system failures, staff unavailability, power outages, disasters, political risk, etc.)
Formal reports on the review of the ICT risk management framework, to be submitted in searchable electronic format and approved by the management body.

Simplified ICT Risk Management Framework (Title III RTS)

For smaller entities listed in Article 16(1) DORA, Delegated Regulation 2024/1774 defines a simplified ICT risk management framework that is lighter but still robust.

Key features:

A clear internal governance and control framework with the management body ultimately responsible for ICT risk.
A single information security policy setting out principles for confidentiality, integrity, availability and authenticity of data.
Basic but mandatory controls for:
- classification of information and ICT assets
- ICT risk identification, assessment and mitigation
- physical and environmental security
- access control and logging
- ICT operations, vulnerabilities, patching and threat monitoring
- data, system and network security
- ICT security testing
- ICT system acquisition, development and maintenance
- ICT project and change management
- ICT business continuity and regular testing
- periodic review and reporting on the simplified framework

In essence, smaller entities receive a scaled-down but complete control set that mirrors the logic of the full framework.

Practical Implications for Financial Entities

For institutions subject to DORA, ICT risk management under 2022/2554 and 2024/1774 means:

No more generic IT security: controls must be traceably aligned with Articles 6–15 DORA and the RTS.
Clear roles and responsibilities, including segregation of duties and integration with existing governance (e.g. BAIT/VAIT in Germany).
End-to-end documentation of policies, procedures, tools, assets, risks, residual risks and test results.
Evidence-ready reports for supervisors showing how ICT risk is identified, assessed, mitigated and reviewed.
Integration with ICT third-party risk and business continuity – ICT risk management can no longer be looked at in isolation.

How to Build a DORA-Compliant ICT Risk Management Framework

From an implementation perspective, a pragmatic approach typically follows these steps:

Gap analysis vs. DORA & RTS 2024/1774
Map existing IT/IS controls, policies and governance against DORA Articles 5–16 and the detailed RTS requirements.
Define ICT risk appetite & tolerance
Make ICT risk explicit in the risk appetite statement and define risk tolerance levels for ICT risk, as required by the RTS.
Design or refine the ICT risk management process
Ensure a documented, repeatable process covering identification, assessment, treatment, residual risk acceptance and review.
Build the core control set
Implement or align controls for asset inventory, cryptography, operations, vulnerabilities, logging, network security, access control, physical security and HR.
Integrate BCM, incident management and testing
Ensure ICT BCM, incident response, crisis communication and resilience testing are consistent across DORA and local regulations.
Prepare for supervisory scrutiny
Design templates and workflows for the ICT risk management framework review report and, where applicable, the simplified framework report.

ICT risk management policies

ICT risk management procedures

OJ_L_202401774_EN_TXT Herunterladen

Source: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R1774