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.
Banks should establish their precise DORA scope and supervisory arrangements rather than infer obligations solely from size. Article 4 proportionality still applies, while Article 16 eligibility depends on specified regulatory categories. Ordinary credit institutions cannot elect the simplified framework merely because they are small.
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 disruption to a bank can affect payment, settlement and other services used by customers and counterparties. Identify these dependencies in the business impact analysis and recovery priorities.
Complexity of ICT dependencies. A bank’s service chain can include group technology companies, cloud providers, payment processors and subcontractors. Reconcile the inventory with contracts and architecture records; do not use an industry-average contract count as a completeness target.
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. Retain evidence of governance, controls and remediation that the relevant banking supervisor can examine.
The management body bears ultimate responsibility for approving the framework and defining risk tolerance levels. Article 5(4) requires management-body members to maintain sufficient ICT risk knowledge and skills, which in practice means documented training programmes.
Threat-Led Penetration Testing every three years
Entities identified under Article 26 and Delegated Regulation (EU) 2025/1190 must conduct TLPT at least every three years; competent authorities can adjust the frequency under the Regulation. Confirm the identification, scope and schedule with the TLPT authority. Do not assume one universal first-test deadline of January 2028.
TLPT covers several critical or important functions on live production systems, with appropriate safeguards and qualified testers. Significant credit institutions under the SSM use external testers. The updated TIBER-EU framework supplies operational guidance aligned with DORA. Budget from an agreed scope and supplier proposal; there is no statutory test price.
Register of Information and incident reporting
Article 28(3) requires an up-to-date register of contractual arrangements with ICT third-party providers, distinguishing those supporting critical or important functions. It must be available on request; annual reporting on new arrangements and supervisory register collections have their own requirements. Implementing Regulation 2024/2956 supplies the templates. Follow the relevant authority’s submission instructions and maintain the underlying records between collections.
Banks must report major ICT-related incidents under the applicable authority channel. Initial notification is as early as possible, within four hours of major classification and normally within 24 hours of awareness; an intermediate report is due within 72 hours of the initial notification, with the final-report clock tied to the intermediate or latest updated intermediate report. The reporting guide explains the exceptions and trigger evidence. Assess GDPR notification independently where personal data is involved.
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 governance and prudential requirements remain relevant alongside DORA. Map each policy and control to the actual obligation rather than attributing that relationship to DORA Article 1(2), which concerns its sector-specific relationship with NIS2. Supervisory ICT findings should feed into the bank’s broader risk governance.
The EBA has amended the scope of its ICT and security risk-management guidelines in light of DORA. Use the applicable consolidated text when mapping any remaining payment-service security requirements; do not simply rename the old guideline checklist “DORA”.
For payment services, the EBA repealed its PSD2 major-incident reporting guidelines on 17 January 2025. DORA Article 23 addresses operational or security payment-related incidents for the listed providers. Retire obsolete reporting instructions while preserving other applicable PSD2 obligations.
What Does the Supervision Structure Look Like?
Supervision follows a layered architecture:
ECB/SSM. Follow the supervisory allocation for significant institutions under the Single Supervisory Mechanism, including the relevant reporting arrangements and ICT-risk review process.
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 application date has passed. Organise ongoing work around decisions and evidence, not obsolete quarters in an implementation timeline.
| Workstream | Current decision | Evidence to retain |
|---|---|---|
| Governance | Which material ICT risks remain unresolved? | Management-body decisions, resources, accountable owners and follow-up |
| Register | Does each required arrangement and relationship match the current service estate? | Reconciled inventory, validated submission and correction log |
| Reporting | Can the bank classify and submit outside office hours? | Exercise timestamps, authority acknowledgements and fallback results |
| Testing | Which critical systems are covered and which TLPT obligations apply? | Approved scope, schedule, completed tests, findings and retests |
| Suppliers | Can critical services continue through failure or exit? | Contract gaps, concentration assessment and tested transition assumptions |
Run one service through the controls
Select a customer-facing payment service and follow it from business owner to application, infrastructure, provider and material subcontractor. Confirm that the function’s criticality decision matches the testing scope and register. Ask the incident team to explain which business-impact data it can obtain during an outage and how quickly.
Next, rehearse the loss of the principal provider. Validate recovery objectives with measured evidence, not only contract service levels. Check that the fallback does not share the same failed dependency and that customer communications have an accountable owner. Record actions with dates and verification criteria; a supplier assurance report cannot close a customer-side configuration gap.
Present unresolved dependencies to the relevant governance forum. Preserve the decision, interim safeguards and retest outcome. This produces a reviewable chain of evidence across risk management, reporting and supplier oversight without duplicating every document. Use the resilience testing guide for the distinction between the ongoing programme and a designated TLPT exercise.
How Should Banks Handle Third-Party Concentration Risk?
Article 29 requires assessment of concentration and substitution risks in ICT arrangements. Examine shared providers and underlying services across the group, including dependencies hidden behind different direct suppliers. Document the actual exposure rather than asserting a percentage of the market is concentrated.
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:
- Incomplete Registers of Information. Many banks documented primary contracts but missed sub-contracting chains, particularly for cloud services with multiple intermediaries.
- 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.
- Testing programme immaturity. Banks relying solely on annual penetration testing must expand to scenario-based testing aligned with DORA’s resilience testing requirements.
- 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?
DORA introduces directly applicable requirements and the EBA has amended the scope of its related guidelines. Map the applicable versions and retained obligations; this is not a blanket statement that every previous EBA provision has disappeared.
Which authority do banks report ICT incidents to?
Use the incident-reporting channel specified for the bank by its competent authority. The four-hour period runs from major classification, subject to the awareness limit and late-classification rule; the 72-hour intermediate period starts with the initial notification.
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 require separate trigger assessments 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.
When a supervisory finding identifies non-compliance, record the obligation, national sanction provision, authority and remedial action. The DORA enforcement guide distinguishes financial-entity sanctions from periodic penalties against critical ICT providers; there is no universal EU-wide bank fine to insert into a risk paper.
FAQ
Which DORA obligations are most critical for banks?
Banks must implement: a comprehensive ICT risk management framework (Arts. 5-16), a major incident reporting process to competent authorities (Art. 19), threat-led penetration testing (TLPT) every 3 years for significant institutions (Art. 26), and a register of all third-party ICT arrangements (Art. 28).
What is the DORA Register of Information for banks?
Article 28(3) DORA requires financial entities to maintain a detailed register of all ICT third-party service providers (TSPs), including sub-contractors supporting critical functions. The register must include contracts, SLAs, concentration risk assessments, and exit strategies.
How does DORA affect banks’ cloud migration strategies?
DORA introduces strict requirements for cloud provider contracts (Art. 30 DORA): full access and audit rights, business continuity guarantees, data portability and exit provisions. Banks must assess concentration risk if using a single cloud provider for critical functions.
What is TLPT and which banks must undertake it?
TLPT is required for entities identified under Article 26 and the applicable technical standards. It uses threat intelligence and controlled testing of live production systems, at the frequency required by the Regulation and the competent authority. Confirm the bank’s identification and schedule rather than relying on a generic size label.
Related reading: