DORA ICT Risk Management for EU Banks in 2025: The Complete Chapter II Compliance Guide

DORA (Regulation EU 2022/2554) entered into force on 17 January 2025. For CROs and IT Risk Managers at EU banks and payment institutions, Chapter II — ICT Risk Management (Articles 5 to 16) — is the heaviest compliance lift: it mandates a board-owned, documented ICT risk framework covering governance, asset identification, protection, detection, response, recovery and independent review. The EBA, ESMA and EIOPA published final RTS on ICT risk management in January 2024. Yet the EBA reported in Q1 2025 that 34% of EU banks had not yet completed their DORA gap assessment. This guide breaks down every obligation in Articles 5-16, the most common gaps, and how to close them before your next supervisory review.

What Changed: ICT Risk Rules Before and After DORA

Before DORA, EU banks were subject to a fragmented patchwork: EBA Guidelines on ICT and Security Risk Management (EBA/GL/2019/04), NIS Directive obligations for operators of essential services, and national supervisory expectations that varied significantly between the ECB Single Supervisory Mechanism, the Banco de Espana (BdE) for Spanish entities, and other national competent authorities. DORA replaces and supersedes all of these with a single, directly applicable EU regulation — binding without transposition — and raises the bar considerably.

Who Is Affected by DORA ICT Risk Requirements?

DORA applies to 21 categories of financial entities. For ICT risk purposes (Chapter II), all credit institutions are in full scope regardless of size. Payment institutions, e-money institutions, investment firms, asset managers, insurance undertakings, crypto-asset service providers, and central counterparties are also covered. Microenterprises (fewer than 10 employees and annual turnover below €2M) may apply the simplified ICT risk management framework under Art. 16 and Delegated Regulation 2024/1773. The BdE issued its own supervisory communication in 2024 clarifying expectations for Spanish entities under ECB supervision and for less significant institutions (LSIs) under national oversight. Entities in Spain must align their DORA implementation with BdE's existing Resolution on ICT governance (Circular 2/2016) to the extent it has not been superseded.

DORA Chapter II: The 5 Pillars of ICT Risk Management (Articles 5-16)

Article 5: ICT Governance — What Supervisors Are Actually Checking

Article 5 is the most scrutinised provision in supervisory assessments. It requires the management body — not the IT department — to define, approve, and actively oversee the digital operational resilience strategy. This means board minutes must show substantive discussion of ICT risk, not just routine sign-offs. Supervisors from the ECB Single Supervisory Mechanism, CNMV, and BdE are requesting: (a) evidence of annual board approval of the ICT risk policy; (b) records of board-level training in cybersecurity and ICT risk; (c) documentation that the ICT budget allocation was reviewed and approved with reference to the institution's risk profile; and (d) at minimum one annual written report from the CISO (or equivalent function) received by the management body. In Spain, the BdE has additionally flagged that the management body's responsibility cannot be satisfied merely by establishing a Risk Committee — the full board or equivalent collegial body must retain direct accountability.

Article 8: ICT Asset Identification — The Minimum Required Register Fields

Article 8 requires institutions to maintain and regularly update a complete register of all ICT assets — hardware, software, data repositories, and dependencies on ICT third-party service providers — classified by criticality. Delegated Regulation 2024/1774 (RTS on ICT risk management tools) specifies the minimum mandatory fields for each registered asset: unique asset identifier, asset type, supported business function, criticality classification (critical / important / standard), accountable owner, physical or logical location, supporting contract reference, and end-of-support date. The register must be reviewed at least annually and following any significant infrastructure change. The most widespread compliance gap: cloud SaaS subscriptions procured directly by business units (HR, marketing, finance) that are not captured in the central IT asset management system. Art. 8(1) is explicit — all ICT assets supporting business functions must be mapped, irrespective of whether the vendor is classified as a critical ICT third-party provider under Chapter V.

Articles 9-13: Protection, Detection and Recovery in Practice

Art. 9 mandates that for systems classified as critical, multi-factor authentication (MFA) is mandatory with no exceptions. Other required controls include: network segmentation to isolate critical systems, encryption of data in transit and at rest equivalent to AES-256 or stronger, patch management with defined SLAs tied to CVSSv3 severity scores (critical patches at CVSSv3 9.0 or above must be applied within 24-72 hours), quarterly access privilege reviews, and a formally board-approved cryptography and key management policy.

Art. 10 requires near-real-time anomaly detection across all critical ICT infrastructure, including monitoring of third-party access points. In practice this means a SIEM (Security Information and Event Management) system with documented baseline behaviour for critical systems, automated alerting for deviations, correlation of security events across the estate, and a formally documented escalation path with defined response times. Institutions relying on cloud infrastructure must extend monitoring to provider-side logs.

Art. 11 requires Business Continuity Plans (BCP) and Disaster Recovery Plans (DRP) with defined and tested Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) for every critical system. Plans must be tested at least annually — or following a major incident or significant infrastructure change — and test results, including deficiencies found and corrective actions taken, must be formally documented and reported to the management body. Art. 12 requires daily backups as a minimum, with offline copies for critical systems and annual full restoration tests. Art. 13 mandates post-incident reviews for all major incidents and integration of threat intelligence into the continuous improvement cycle of the framework.

DORA ICT Risk Compliance Checklist for Banks (2025)

How IgeraRegTech Closes the Gap: Article-Level Answers in Under 3 Seconds

The EBA finding that 34% of EU banks had not completed their DORA gap assessment by Q1 2025 reflects a real operational bottleneck: compliance teams are overwhelmed by the volume and specificity of Article-level queries, and legal counsel costs are substantial. IgeraRegTech clients in banking have seen the RAG bot answer DORA Article-level queries in under 3 seconds with exact regulatory citations, reducing compliance team queries by 58% in the first month of deployment.

For a deeper look at how DORA regulates your ICT third-party providers and what contract clauses are now mandatory, see our companion guide: DORA and ICT Third-Party Risk: The Complete Guide for EU Banks and Asset Managers. For the full DORA product overview and how IgeraRegTech maps to all five DORA chapters, visit the IgeraRegTech DORA hub page.

Frequently Asked Questions: DORA ICT Risk Management for Banks

Can the board delegate its DORA Article 5 ICT governance responsibilities to the CTO or CISO?

No. Art. 5 DORA is explicit: the management body is directly responsible for defining, approving, and actively overseeing the ICT risk strategy. Operational management and day-to-day execution can be delegated, but strategic approval of the ICT risk policy, budget allocation, and receipt of the annual CISO report are non-delegable. ECB supervisors and national competent authorities including the BdE are now examining board minutes and training records as evidence of substantive engagement, not just formal sign-off.

What are the mandatory fields in a DORA-compliant ICT asset register under Article 8?

Delegated Regulation 2024/1774 (RTS on ICT risk management tools) sets the minimum fields: unique asset identifier, asset type (hardware / software / data / ICT service), supported business function, criticality classification (critical / important / standard), accountable owner, physical or logical location, contractual support reference, and end-of-support or end-of-life date. All ICT assets supporting any business function must be included — not only those linked to critical or important functions. Business-unit SaaS tools, HR platforms, marketing automation software, and cloud storage services are all in scope if they process business data.

What RTO and RPO targets are acceptable under DORA Article 11?

DORA does not prescribe specific numeric RTO/RPO values. The regulation requires that RTO and RPO be defined in proportion to the criticality and the potential business impact of each system's disruption, and — critically — that they be demonstrated as achievable through actual tests. The EBA has indicated in its supervisory priorities that for payment systems and essential services, supervisors will expect RTOs measured in hours rather than days. Objectives that have never been tested are non-compliant regardless of the documented values.

Does internal audit satisfy the independent review requirement in DORA Article 15?

Not automatically. Art. 15 requires that the ICT risk management framework be reviewed by parties independent of the function being reviewed, with sufficient technical expertise in cybersecurity. Internal audit can qualify if it has the requisite independence and technical capability. However, many institutions' internal audit functions lack specialist ICT security expertise, and some institutions' internal audit teams directly supported the framework implementation — which compromises independence. External review by a qualified third party is often required to satisfy the Art. 15 standard, and supervisors are beginning to request evidence of reviewer qualifications.

How does DORA Article 9 define the minimum protection requirements for critical ICT systems?

Art. 9 requires, for systems classified as critical: mandatory multi-factor authentication with no exception pathways, network segmentation isolating critical systems from general IT infrastructure, encryption of all data in transit and at rest using algorithms meeting current cryptographic standards (RTS 2024/1774 refers to ENISA recommendations), a formally board-approved cryptography and key management policy, patch management SLAs defined by CVSSv3 severity (critical-rated vulnerabilities within 24-72 hours), and quarterly reviews of access privileges. The information security policy itself — not just the cryptography sub-policy — must be formally approved by the management body and reviewed annually.

Do smaller EU banks and payment institutions have lighter DORA ICT risk obligations?

Yes, but only if they qualify. Art. 16 DORA and Delegated Regulation 2024/1773 establish a simplified ICT risk management framework for microenterprises (fewer than 10 employees, annual turnover below €2M) and entities classified as small and non-complex. Under the simplified regime, certain governance and documentation requirements are proportionate. However, the incident reporting obligations (Arts. 17-23), the third-party ICT risk management requirements (Chapter V), and the digital operational resilience testing obligations (Chapter IV) apply without simplification to all entities. Misidentifying your institution as eligible for the simplified regime is one of the most common compliance errors observed post-January 2025.

What is the EBA's assessment of DORA readiness among EU banks as of Q1 2025?

The EBA reported in Q1 2025 that 34% of EU banks had not yet completed their DORA gap assessment — a significant compliance lag given that the regulation became applicable on 17 January 2025. The most frequently incomplete areas were the Art. 8 ICT asset register (particularly coverage of third-party SaaS dependencies), Art. 11 BCP/DRP testing evidence, and Art. 15 independent review. Supervisory letters were issued to a number of significant institutions by the ECB reminding them of their obligations and requesting remediation timelines by Q3 2025.

Conclusion: DORA ICT Risk Compliance Is Supervisory Priority No. 1 in 2025

DORA Chapter II ICT risk management is no longer a future compliance exercise — supervisory assessments are live across the EU, with the ECB, ESMA, EIOPA and national authorities including the BdE actively reviewing compliance. With 34% of EU banks still completing gap assessments in Q1 2025, the compliance window is narrowing. The five-pillar structure of Arts. 5-16 creates a clear compliance map: governance, identification, protection, detection/response/recovery, and independent review. Institutions that invest in structured compliance tooling — rather than relying on manual legal research for every Article-level question — are closing gaps faster and at lower cost.