DORA for Banks: Obligations and Roadmap

Banks face the most demanding tier of obligations under the Digital Operational Resilience Act (Regulation (EU) 2022/2554). Since 17 January 2025, DORA compliance for banks has been a binding legal requirement across the EU, and credit institutions sit at the top of the supervisory priority list. The European Central Bank has identified ICT risk as a key supervisory focus for 2025-2026.

Unlike other financial entities that benefit from proportionality exemptions, significant institutions must implement the full suite of DORA obligations without simplification. Over 110 significant institutions under direct ECB supervision and approximately 2,100 less significant institutions supervised nationally fall within scope.

Why Do Banks Face the Strictest DORA Requirements?

Banks – particularly significant institutions – are excluded from the simplified ICT risk management framework available to smaller entities under Article 16. Three factors explain why:

Systemic importance. A major ICT disruption at a systemically important bank cascades through payment systems, interbank lending, and securities settlement. The ECB’s 2024 cyber resilience stress test found that 78% of tested banks had material gaps in ICT recovery capabilities.

Complexity of ICT dependencies. Significant institutions maintain an average of 1,200 ICT third-party contracts according to a 2025 EBA survey, compared to roughly 180 for mid-sized investment firms.

Regulatory precedent. Banks were already subject to the EBA Guidelines on ICT and Security Risk Management (EBA/GL/2019/04). DORA elevates these expectations from guidelines to binding law.

What Are the Core DORA Obligations for Banks?

DORA compliance for banks spans the regulation’s five pillars, but several obligations carry specific weight for credit institutions.

ICT risk management framework

Articles 5 through 15 require banks to establish a documented ICT risk management framework fully integrated into overall risk management, covering identification, protection, detection, response, and recovery. The ECB expects this framework to align with SREP assessments, meaning ICT risk findings directly affect capital adequacy evaluations.

The board bears personal, non-delegable responsibility for approving the framework and defining risk tolerance levels. Article 5(2) requires board members to maintain adequate ICT risk knowledge, which in practice means documented training programmes.

Threat-Led Penetration Testing every three years

Significant institutions must conduct advanced threat-led penetration testing (TLPT) at least every three years under Articles 26 and 27. TLPT follows the TIBER-EU framework and must be performed by qualified external testers simulating adversarial attacks against critical production systems.

This goes well beyond standard vulnerability assessments. Competent authorities can require more frequent testing based on risk profile. A single TLPT exercise typically costs EUR 200,000 to EUR 800,000 for a large bank.

Register of Information and incident reporting

Article 28(3) mandates a complete register of all contractual arrangements with ICT third-party service providers, reported annually to the competent authority. For significant institutions, this register feeds into the ECB’s sector-wide concentration risk assessment. Required data fields include services provided, functions supported (flagging critical or important functions), data processing locations, sub-contracting chains, and exit provisions. The ESAs published Regulatory Technical Standards specifying exact templates.

Banks must report major ICT incidents using harmonised timelines: initial notification within 4 hours, intermediate report within 72 hours, final report within one month. Significant institutions report directly to the ECB; less significant institutions report to national competent authorities. Approximately 64% of major ICT incidents in banking involve personal data, triggering parallel GDPR breach notification. Banks need integrated procedures satisfying both DORA and GDPR simultaneously.

How Does DORA Interact with Existing Banking Regulation?

DORA does not replace existing banking frameworks – it adds a specialised ICT resilience layer.

CRD/CRR, EBA Guidelines, and PSD2

CRD/CRR already require robust governance and operational risk controls, and SREP assessments evaluate ICT risk. DORA formalises these expectations into binding law. Article 1(2) confirms DORA applies without prejudice to CRD/CRR, but ICT failures under DORA can translate into Pillar 2 capital add-ons. A 2025 ECB communication indicated that 23% of SREP assessments included ICT-specific findings that could increase capital requirements.

The EBA Guidelines (EBA/GL/2019/04) were the primary ICT risk framework for banks since 2020. DORA supersedes and extends them. Banks that fully implemented the Guidelines have a head start, but must address the Register of Information, mandatory TLPT, and harmonised incident reporting.

Banks providing payment services also face PSD2’s operational resilience and incident reporting obligations (Articles 95-96). DORA’s recital 16 resolves this: for ICT-related matters, DORA acts as lex specialis. Banks must apply DORA’s classification criteria and timelines rather than PSD2’s for ICT incidents.

What Does the Supervision Structure Look Like?

Supervision follows a layered architecture:

ECB/SSM. The ECB directly supervises DORA compliance for approximately 110 significant institutions, embedding ICT risk in on-site inspections and the annual SREP cycle.

National competent authorities. Less significant institutions are supervised by national authorities (BaFin, ACPR, Banca d’Italia, etc.) following ECB methodological guidance.

ESAs. The EBA, ESMA, and EIOPA develop Regulatory Technical Standards and guidelines. For critical ICT third-party providers, a Lead Overseer conducts direct oversight with power to impose penalty payments of up to 1% of average daily worldwide turnover.

What Is the Ongoing Compliance Roadmap for Banks?

The transitional period is over. Banks must demonstrate ongoing compliance. Key workstreams for 2025-2026:

Q1-Q2 2025: Foundation and gap closure

• Complete the Register of Information using ESA templates for the first annual submission.
• Map all ICT third-party contracts, flagging critical or important function providers.
• Gap analysis between existing frameworks (EBA Guidelines) and DORA Articles 6-15.
• Document board-level ICT risk training.

Q3-Q4 2025: Testing and reporting readiness

• Implement harmonised incident classification and test escalation procedures.
• Establish the digital operational resilience testing programme (Articles 24-25), including scenario-based testing at least annually.
• Begin TLPT procurement. Coordinate scope with the competent authority per Article 26(2).
• Align DORA incident response with GDPR compliance processes.

2026 and beyond: Continuous improvement

• Complete the first TLPT cycle by January 2028.
• Incorporate DORA findings into SREP self-assessment and ICAAP.
• Update the Register of Information annually. Monitor evolving RTS – Level 2 measures will be revised based on supervisory experience.
• Use compliance platforms such as Legiscope to manage DORA-GDPR documentation overlap, particularly third-party risk registers and incident workflows.
• Participate in cyber threat information-sharing (Article 45).

How Should Banks Handle Third-Party Concentration Risk?

Article 29 requires banks to assess risks from concentration on a limited number of ICT providers. Over 70% of significant EU banks rely on the same three cloud providers for core operations according to a 2025 ESA report, creating systemic exposure.

Banks must independently assess concentration risk and maintain documented exit strategies for every critical provider. The Register of Information should capture the full sub-contracting chain to identify hidden concentration points.

What Are Common Compliance Gaps for Banks?

Supervisory experience has already revealed recurring gaps:

1. Incomplete Registers of Information. Many banks documented primary contracts but missed sub-contracting chains, particularly for cloud services with multiple intermediaries.
2. Board-level governance deficiencies. Generic risk committee oversight is insufficient. Regulators expect documented training, dedicated agenda time, and evidence of informed decision-making on ICT risk.
3. Testing programme immaturity. Banks relying solely on annual penetration testing must expand to scenario-based testing aligned with DORA’s resilience testing requirements.
4. Inconsistent incident classification. Applying classification criteria consistently across heterogeneous IT environments remains challenging, especially for banks that have grown through acquisition.

Frequently Asked Questions

Does DORA replace the EBA Guidelines on ICT risk for banks?

Yes. DORA elevates the EBA Guidelines (EBA/GL/2019/04) into directly applicable EU law and adds requirements beyond the Guidelines, including the Register of Information, mandatory TLPT, and harmonised incident reporting.

Which authority do banks report ICT incidents to?

Significant institutions under the SSM report directly to the ECB. Less significant institutions report to their national competent authority. Initial notification is due within 4 hours of classifying an incident as major, followed by an intermediate report within 72 hours and a final report within one month.

How does DORA affect bank contracts with cloud providers?

Article 30 requires mandatory clauses covering service-level descriptions, data locations, audit rights, incident notification, termination conditions, and exit strategies. Non-compliant contracts must be renegotiated. For critical third-party providers, the ESA-appointed Lead Overseer exercises direct supervisory authority.

What is the relationship between DORA and the GDPR for banks?

Both apply simultaneously. ICT incidents involving personal data trigger obligations under both DORA and GDPR. Third-party management and risk assessment overlap substantially. Banks should integrate rather than duplicate compliance processes. See also the DORA compliance guide and the compliance software buyer’s guide.