DORA ICT Risk Management Framework
A complete walkthrough of DORA Chapter II — the ICT risk management requirements that form the backbone of the Digital Operational Resilience Act for financial entities across the EU.
- 1
The management body bears ultimate, non-delegable responsibility for ICT risk management under DORA Article 5, including mandatory ICT risk training.
- 2
Financial entities must maintain a continuously updated ICT asset inventory with full dependency mapping, covering internal systems and third-party providers.
- 3
Detection capabilities must go beyond perimeter security — DORA expects behavioural analytics, anomaly detection, and near-real-time monitoring of critical systems.
- 4
Recovery procedures require defined RTOs and RPOs for critical functions, with annual testing that demonstrates the entity can meet those objectives.
- 5
Smaller entities may use the simplified framework under Article 16, but should build scalable foundations to avoid costly retrofits.
Chapter II at a Glance: The ICT Risk Management Core
Chapter II of DORA (Regulation 2022/2554) — spanning Articles 5 through 16 — establishes the foundational ICT risk management obligations for financial entities operating in the European Union. This chapter is not advisory guidance; it is directly applicable law that took effect on 17 January 2025. Every credit institution, insurance undertaking, investment firm, payment institution, and other financial entity within scope must implement an ICT risk management framework that meets the requirements laid out across these twelve articles.
The structure of Chapter II follows a deliberate logic. Article 5 sets the governance mandate, requiring the management body to take ultimate responsibility. Article 6 then prescribes the overall framework architecture. Articles 7 through 14 walk through the lifecycle phases — from asset identification and protection through detection, response, recovery, and communication. Article 15 mandates continuous learning and evolution, while Article 16 provides a proportionate, simplified framework for smaller entities.
Understanding this chapter is essential because it represents the floor, not the ceiling, of what regulators expect. The European Supervisory Authorities (ESAs) — EBA, EIOPA, and ESMA — have issued Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) that further specify many of these requirements. Financial entities should treat Chapter II as the structural blueprint and the RTS/ITS instruments as the detailed engineering specifications that fill in the gaps.
Governance and Framework Requirements (Articles 5-6)
Article 5 places ICT risk management squarely on the shoulders of the management body. This is not a delegation-friendly obligation: the management body must define, approve, oversee, and bear ultimate responsibility for the implementation of the ICT risk management framework. They must allocate adequate budget, approve the ICT business continuity policy, establish roles and responsibilities, and stay informed about ICT risk at all times. In practice, this means board-level reporting on ICT risk posture must become a regular cadence, not an annual checkbox exercise.
Article 6 prescribes the components of the framework itself. Financial entities must establish a comprehensive, well-documented ICT risk management framework that includes strategies, policies, procedures, ICT protocols, and tools necessary to protect all information assets and ICT assets. The framework must be reviewed at least annually — or after major ICT-related incidents — and be subject to internal audit. Crucially, the framework must ensure a high level of availability, authenticity, integrity, and confidentiality of data.
One of the most consequential aspects of Article 6 is the requirement for a digital operational resilience strategy. This strategy must explain how the framework supports the entity's business strategy, set risk tolerance levels for ICT risk, describe how the entity achieves its ICT security objectives, and outline the architecture for ICT third-party arrangements. The strategy must be approved by the management body and must evolve continuously based on lessons learned from incidents and testing.
DORA Article 5(2) explicitly states the management body must undergo specific training to understand and assess ICT risk. Failure to demonstrate adequate ICT competence at board level is a supervisory finding waiting to happen.
Identification: ICT Assets, Systems, and Dependencies (Articles 7-8)
Article 7 requires financial entities to identify, classify, and document all ICT-supported business functions, information assets, and ICT assets. This includes mapping the interdependencies between these assets, both internally and with ICT third-party service providers. The entity must maintain an up-to-date inventory and must review the classification of assets at least annually. For many organisations, this is where the hard work begins — years of organic IT growth, shadow IT, and undocumented integrations make comprehensive asset identification a significant undertaking.
The identification obligation extends beyond hardware and software inventories. Financial entities must identify all sources of ICT risk, including risks arising from ICT third-party dependencies. They must assess the potential impact of ICT disruptions on business functions and must map the critical business processes that depend on ICT systems. This dependency mapping is not just an internal exercise — it feeds directly into the ICT third-party risk management requirements in Chapter V (Articles 28-44).
Article 8 complements identification with explicit protection and prevention requirements. Entities must implement ICT security policies that define rules to protect the confidentiality, integrity, availability, and authenticity of data and ICT assets. These policies must cover access management, encryption, network security, and change management, among other domains. The protection measures must be proportionate to the criticality of the assets and the risk profile of the entity — but "proportionate" does not mean "optional" for any category of asset.
Protection and Detection: Security Controls and Monitoring (Articles 8-10)
Article 8's protection requirements are extensive and prescriptive compared to most principle-based regulation. Financial entities must implement policies on identity management and access control, including strong authentication mechanisms. They must deploy ICT solutions and tools that minimise the impact of ICT risk, and establish policies on change management for ICT systems — covering development, maintenance, and acquisition. Encryption of data at rest and in transit is expected where appropriate to the classification of the asset. Physical security of ICT infrastructure is also explicitly within scope.
Article 9 addresses detection head-on. Financial entities must establish mechanisms to promptly detect anomalous activities, including ICT network performance issues and ICT-related incidents. Detection mechanisms must be capable of multi-layered monitoring: network activity, transactions, and access patterns. The entity must define alert thresholds and criteria that trigger incident response procedures. Article 9 also requires that detection capabilities are tested periodically as part of the broader digital operational resilience testing programme under Chapter IV.
The detection obligation represents a material step up from what many financial entities have historically implemented. Basic perimeter security and antivirus are insufficient. DORA expects behavioural analytics, anomaly detection, and near-real-time monitoring of critical systems. The RTS on ICT risk management tools (delegated under Article 15) further specifies expectations around Security Information and Event Management (SIEM) capabilities, log correlation, and threat intelligence feeds. Financial entities that have not yet invested in mature Security Operations Centre (SOC) capabilities should treat this as a priority remediation area.
The EBA, EIOPA, and ESMA joint RTS on ICT risk management framework (published under Article 15) provides granular specifications for detection tools, including expectations around log retention periods, correlation capabilities, and automated alert classification.
Response, Recovery, and Communication (Articles 10-14)
Articles 10 and 11 mandate that financial entities establish comprehensive ICT incident response and recovery capabilities. The response framework must include early warning indicators, clear escalation and communication procedures, and defined roles and responsibilities for incident handling teams. Entities must classify ICT-related incidents according to criteria set out in Article 18 and the related RTS, and must activate response plans proportionate to the severity classification. The goal is not just containment — DORA explicitly requires root cause analysis and post-incident review.
Recovery under Article 11 is equally prescriptive. Financial entities must develop, document, and implement ICT business continuity policies and ICT response and recovery plans. These plans must be subject to independent review, must be tested at least annually, and must cover scenarios including severe business disruptions and cyberattacks. Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs) must be defined for critical functions, and the entity must demonstrate that it can meet those objectives through testing. Backup policies must ensure that backups are sufficient to restore operations and that restoration procedures are periodically tested.
Articles 13 and 14 address communication obligations. Article 13 requires entities to establish communication plans for ICT-related incidents, including designated spokespersons and clear internal and external notification protocols. Critically, financial entities must have policies on disclosure of ICT-related incidents to clients and counterparties where those incidents may affect their interests. Article 14 focuses on the continuous learning cycle — entities must conduct post-incident reviews, feed lessons learned back into the ICT risk management framework, and report the root causes and remediation actions to the management body.
The response-recovery-communication triad forms a closed loop that regulators will scrutinise during supervisory reviews. An entity that can detect an incident but cannot demonstrate tested recovery procedures and structured communication protocols will be found non-compliant. The practical implication is that tabletop exercises, crisis simulation drills, and DR failover testing must become recurring operational activities, not once-a-year compliance rituals.
Continuous Learning and Framework Evolution (Article 15)
Article 15 requires financial entities to gather information on vulnerabilities, cyber threats, and ICT-related incidents — particularly cyberattacks — and to analyse their likely impact on digital operational resilience. This is not passive consumption of threat intelligence bulletins. Entities must integrate these insights into the ICT risk assessment process, update their protection and detection measures accordingly, and ensure the management body is informed of material developments.
The continuous learning obligation also mandates post-incident reviews after major ICT-related incidents or after digital operational resilience testing reveals significant weaknesses. These reviews must assess whether the established procedures were followed, whether the response was effective, whether the entity could have detected the incident earlier, and what structural improvements are needed. The findings must be reported to the management body and must drive tangible improvements to the framework.
In practice, Article 15 creates a regulatory expectation of a mature threat intelligence function and a structured improvement cycle. Financial entities should maintain a lessons-learned register, track remediation actions to completion, and be able to demonstrate — with documentation — how their ICT risk management framework has evolved over time in response to the threat landscape. Supervisors will look for evidence of this evolution during on-site inspections, and static frameworks that have not changed since initial implementation will attract scrutiny.
Simplified ICT Risk Management Framework (Article 16)
Article 16 provides a proportionate, simplified ICT risk management framework for certain smaller entities. The entities eligible for this simplified regime include small and non-interconnected investment firms, payment institutions exempted under PSD2, institutions exempted under AMLD, small institutions for occupational retirement provision, and certain other entities identified in Article 16(1). These entities are not exempt from DORA — they must still implement an ICT risk management framework — but the requirements are scaled to their size and risk profile.
The simplified framework requires these entities to put in place an ICT risk management framework that identifies and documents ICT-supported business functions and their risks, that protects ICT assets through appropriate measures, and that detects and responds to ICT-related incidents. However, the specific prescriptions around digital operational resilience strategy, formal testing programmes, and advanced detection capabilities are relaxed. The entity must still report major incidents and must still manage ICT third-party risk, but the depth and formality of the framework can be proportionate to their operational profile.
Financial entities considering reliance on Article 16 should exercise caution. The simplified framework is a floor, not a safe harbour. Competent authorities retain full supervisory powers and can require additional measures where they assess that the entity's ICT risk profile warrants them. Furthermore, entities that grow beyond the thresholds or lose their exemption status must transition to the full framework — and doing so retroactively under time pressure is significantly more costly than building a scalable framework from the outset. The prudent approach is to implement a framework that can scale, even if Article 16 permits a lighter touch today.
Even if your entity qualifies for the Article 16 simplified framework, consider implementing the full framework from the start. It avoids a costly retrofit if you grow beyond the thresholds, and it signals maturity to counterparties conducting due diligence on your operational resilience.
When did DORA ICT risk management requirements become applicable?
DORA (Regulation 2022/2554) became directly applicable across all EU Member States on 17 January 2025. Unlike a directive, it does not require national transposition — the ICT risk management requirements in Articles 5-16 are binding law from that date. Financial entities should have completed their gap analysis and implementation by this deadline.
Does Article 16 exempt small financial entities from DORA entirely?
No. Article 16 provides a simplified, proportionate framework — not an exemption. Eligible entities must still implement ICT risk management, report major incidents, and manage ICT third-party risk. The simplification applies to the depth and formality of certain requirements, particularly around advanced detection capabilities and formal testing programmes. Competent authorities can still require additional measures if warranted by the entity's risk profile.
How often must the ICT risk management framework be reviewed?
Article 6(5) requires the ICT risk management framework to be reviewed at least once a year, as well as upon the occurrence of major ICT-related incidents, following supervisory instructions, or based on conclusions drawn from digital operational resilience testing or audit findings. The review must result in documented updates where deficiencies are identified.
What is the relationship between DORA Chapter II and the RTS on ICT risk management?
Chapter II sets the legislative requirements. The RTS (Regulatory Technical Standards) issued by the ESAs under Article 15 provide granular, binding specifications that flesh out how those requirements must be implemented — covering areas like ICT security tools, detection capabilities, logging, and testing methodologies. Financial entities must comply with both the regulation text and the applicable RTS.
Can the management body delegate ICT risk management responsibilities?
While day-to-day implementation can be delegated to a dedicated ICT risk management function (often headed by a CISO or CRO), Article 5 is clear that the management body retains ultimate responsibility. They must approve the framework, allocate budget, oversee implementation, and undergo specific ICT risk training. Delegation of execution does not transfer accountability.
Ready to Operationalise This?
Turn this guide into working compliance workflows. Create an account or schedule a personalised demo.