DORA for the Banking Sector

DORA for banks, in short

DORA applies to all EU banks: ECB-supervised significant institutions, less significant institutions, and EU branches of third-country banks. Since 17 January 2025 they must run an ICT risk-management framework, classify and report major incidents (4h / 72h / 1-month), maintain a Register of Information, oversee ICT third parties under Article 30, and perform threat-led penetration testing (TLPT) where designated.

Building your DORA team? Banks hire the DORA Compliance Officer first, a verifiable certification for exactly the profile supervisors and hiring teams look for. Browse all DORA certifications.

Why DORA Matters for Banks

Banks operate at the intersection of two structural realities that make DORA particularly consequential. First, modern retail and corporate banking is fundamentally a digital service: core banking platforms, payment rails, mobile channels, anti-money-laundering screening, fraud detection and trading desks all run on ICT stacks where a 30-minute outage can produce hundreds of millions of euros in lost transactions, supervisory notifications and reputational damage. Second, banks are systemically connected, a failure at a single bank can propagate through correspondent banking, payment systems and counterparty exposures across the European financial system.

Before DORA, ICT risk supervision was fragmented across the EBA Guidelines on ICT and security risk management (EBA/GL/2019/04), the EBA Outsourcing Guidelines, sectoral PSD2 incident reporting, and national supervisory practices. This fragmentation produced inconsistent expectations, double-reporting and gaps. DORA replaces the patchwork with a single, directly-applicable Regulation (EU) 2022/2554 with technical standards binding across all 27 Member States.

For credit institutions specifically, DORA elevates ICT risk to the same level of supervisory attention historically reserved for credit and market risk. The ECB's 2025-2027 supervisory priorities placed "operational resilience and digitalisation" as a top-three concern, alongside credit risk and business model sustainability. National competent authorities (BaFin, ACPR, DNB, Banco de España, Banca d'Italia, Finansinspektionen, FMA, CSSF and others) coordinate with the ECB Joint Supervisory Teams (JSTs) to inspect ICT risk frameworks during regular SREP cycles and on-site inspections.

DORA Scope in the Banking Sector

DORA applies directly to all credit institutions authorised under Directive 2013/36/EU (CRD). Within that universe, three supervisory tiers shape how the regulation is enforced day-to-day:

Article-by-Article Requirements for Credit Institutions

DORA's 64 articles map onto five operational pillars. Below is what each pillar means specifically for a credit institution, with the binding article references and the related RTS that operationalise them.

Pillar 1: ICT Risk Management Art. 5–16

Credit institutions must maintain an ICT risk management framework that is documented, board-approved, and integrated with overall risk management. The framework covers identification of ICT-supported business functions, classification of information assets, protection through layered controls (Article 9), continuous threat detection (Article 10), response and recovery procedures (Articles 11–12), and learning from incidents (Article 13). The Commission Delegated Regulation 2024/1774 (RTS on ICT risk framework) specifies minimum content for security policies, network segmentation, identity and access management, encryption, change management and ICT business continuity policy.

For banks, integration with ICAAP and the operational risk inventory under CRR is critical. The board must define ICT risk appetite as part of the broader risk appetite statement and validate that ICT risk is captured in stress testing scenarios.

Pillar 2: Incident Management & Reporting Art. 17–23

Banks must operate an end-to-end incident management process that detects, classifies, contains, recovers and reports ICT-related incidents. Major incidents trigger external reporting under harmonised criteria (RTS on classification): clients affected, geographic spread, duration, data integrity impact, economic impact, reputational impact, and impact on critical services. Significant cyber threats (not yet incidents) are reported on a voluntary basis under Article 19.

Reporting timelines are uniform: initial notification within 4 hours of classification (max 24h after detection), intermediate report within 72h, final report within one month. Banks already submitting PSD2 incident reports use the consolidated DORA template, no double reporting.

Pillar 3: Digital Operational Resilience Testing Art. 24–27

All banks must conduct an annual programme of digital operational resilience testing including vulnerability assessments, scenario-based tests, network security assessments, gap analyses, source code reviews where relevant and physical security tests. Testing must cover all critical or important ICT systems and be performed by independent parties, internal testers are acceptable provided independence safeguards are documented. Significant banks designated under Article 26 also conduct Threat-Led Penetration Testing (TLPT) at least every 3 years (see below).

Pillar 4: ICT Third-Party Risk Management Art. 28–44

This is where banks face the largest operational lift. Article 28 sets the principles, Article 29 mandates the Register of Information, Article 30 lists the mandatory contractual clauses (audit rights, exit strategies, sub-outsourcing rules, data location), Article 31–44 establish the Oversight Framework for Critical ICT Third-Party Providers (CTPPs). For banks heavily reliant on cloud, SaaS providers, market data vendors and payment infrastructure, this means renegotiating hundreds of contracts, building a real-time register and aligning vendor management with the lead overseer regime.

Pillar 5: Information Sharing Art. 45

Voluntary participation in trusted communities for cyber threat information sharing. Banks typically join via FS-ISAC, national CERT-Bank arrangements (e.g., DSGV CERT in Germany, ABE-Lab in Spain) or the European Cyber Resilience Information Sharing Platform. Article 45 explicitly authorises sharing of cyber threat indicators and tactics, techniques and procedures (TTPs), removing prior legal uncertainties under GDPR for legitimate cyber-defence sharing.

ECB SREP Integration: How DORA Affects Capital

For SSM-supervised banks, the most consequential reality is that DORA does not exist in a regulatory silo. The ECB has integrated DORA-aligned ICT risk assessment into the Supervisory Review and Evaluation Process (SREP), the cycle that determines Pillar 2 Requirements (P2R) capital add-ons. This means weak ICT risk management directly translates into higher capital requirements.

SREP Element mapping

• SREP Element 1 (Business Model): ICT-driven business model risk, over-reliance on a single core banking vendor, lack of cloud strategy, declining digital channel resilience.
• SREP Element 2 (Internal Governance & Risk Management): Primary home of DORA assessment. The full ICT risk framework is evaluated here, including board-level oversight, three-lines-of-defence implementation, ICT risk appetite definition.
• SREP Element 3 (Capital): Operational risk capital under Pillar 1 plus add-ons from ICT risk findings flowing through Pillar 2.
• SREP Element 4 (Liquidity): ICT failures affecting payment systems, treasury platforms and intra-day liquidity monitoring trigger liquidity-side findings.

Capital impact: how ICT findings reach the P2R

A weak SREP score on ICT risk (3 or 4 on the 1-4 scale) feeds the Pillar 2 Requirement through the operational risk assessment. The ECB's published P2R methodology names ICT risk, third-party risk, business continuity risk and internal risk controls among the drivers considered, and the Joint Supervisory Team sets the add-on case by case using constrained supervisory judgement. The decision ranges that convert a SREP score into basis points are not published, so no public scale exists: treat any bank-level figure you are quoted as an estimate, not a supervisory expectation.

What the ECB does publish is the aggregate. After the 2025 SREP cycle, CET1 Pillar 2 requirements applicable in 2026 stayed broadly stable at 1.2% of risk-weighted assets, and the average overall SREP score improved to 2.5 from 2.6 (ECB Banking Supervision, 18 November 2025).

CRR3 Operational Risk: The Draft RTS and Your DORA Evidence

The SREP section above is about Pillar 2. This one is about the framework that sits underneath it. On 26 August 2026 the European Banking Authority opened a consultation on draft Regulatory Technical Standards specifying the operational risk management framework banks must have in place, under the mandate in Article 323(2) of the Capital Requirements Regulation as amended by Regulation (EU) 2024/1623. The reference is EBA/CP/2026/18, and responses are due by 31 December 2026.

Article 2 lets you rely on what DORA already built

The draft opens, before its definitions, with a provision on ICT risk. Article 2(1) requires ICT risk management under DORA and Directive (EU) 2022/2556 to form an integral part of the overall risk management framework. Article 2(2) then allows institutions to rely on strategies, policies, procedures, controls and tools already established under DORA where the RTS asks for arrangements DORA already specifies in detail.

Recital 5 explains why: ICT risk, including ICT third-party risk, is a material component of operational risk, so ICT-related incidents in the scope of operational risk should be identified and treated as operational risk events, drawing on the information already produced by the DORA incident reporting arrangements. In practice that means your incident register has to reach the operational risk event register with a loss amount, a taxonomy category and, under Article 15(3) of the draft, a reconciliation against the accounting records.

What has no DORA equivalent

• The loss data set. DORA never asks what an incident cost. The draft works in euros: losses above EUR 20,000 under the CRR regime, plus relevant losses below that threshold, with the relevance criteria written into your own internal documents.
• The business indicator. Article 7(1) requires the business indicator component, and the annual operational risk loss at or above EUR 750 million. That is Article 314 CRR machinery, owned by finance rather than by resilience.
• The operational risk taxonomy. DORA classifies incidents by impact. The draft wants events classified by type for loss aggregation, governed with named ownership and change control.
• Boundary cases. Events where operational risk contributes to losses booked under credit, counterparty or CVA risk, with market risk already inside the operational risk perimeter under Article 317(6) CRR.
• Everything that is not ICT. Legal risk events, misconduct, process and people failures. Your DORA controls cover one driver of operational risk well and the others not at all.

The EUR 750 million line

Almost all of the proportionality in the draft runs through one number, the business indicator calculated under Article 314 CRR. Six obligations change with it.

Two free tools cover this ground: the OpRisk RTS readiness check scores what your DORA arrangements already answer in eight questions, and the consultation response framework sets out all 16 questions with room for your own position. The full mapping, article by article, is in what your DORA work already covers.

TLPT for Banks: Who, When, How

Threat-Led Penetration Testing under Article 26 is the most operationally demanding DORA requirement for designated banks. Unlike traditional penetration testing, TLPT simulates realistic adversaries (red team) operating against the live production environment, with only a small "white team" aware. The methodology aligns with the TIBER-EU framework that several NCAs already operated as a voluntary regime.

Designation criteria for banks

Article 26(8) requires NCAs to designate financial entities for TLPT based on size, risk profile and systemic importance. In practice for the banking sector this means:

• All Global Systemically Important Institutions (G-SIIs)
• Most Other Systemically Important Institutions (O-SIIs): exact threshold by NCA
• Significant Institutions in the SSM with material critical functions, even if not O-SII
• Industry estimate: ~100-120 banks across the EU in scope, with first-cycle testing running 2025-2027

The 5 phases at bank-specific scale

1. Preparation (2-3 months): Scoping critical/important functions, stakeholder onboarding, NCA notification, white team activation. For banks, this typically covers core banking, payment systems (TARGET2/T2/T2S/SEPA participation), trading platforms, customer-facing apps and the cloud control plane.
2. Threat Intelligence (4-6 weeks): Targeted Threat Intelligence Report (TTIR) profiling realistic adversaries, typically financially-motivated organised crime groups, nation-state actors targeting SWIFT operations, and supply-chain attackers via cloud or core banking vendors.
3. Red Team execution (10-14 weeks): Live attack simulation. Initial access (phishing, supply chain, exposed services), lateral movement, privilege escalation and objective achievement (e.g., simulated wire transfer manipulation, customer data access, trading platform disruption, without actual harm).
4. Closure (3-4 weeks): Detailed reporting, blue team replay, gap analysis, remediation roadmap.
5. Remediation (variable, typically 6-12 months): Implementation of fixes, retesting of priority gaps, supervisory attestation submitted to NCA.

Cloud and Third-Party Concentration Risk

European banking is now massively cloud-dependent. EBA's 2024 risk dashboard reported that over 70% of significant banks rely on at least one of the three hyperscalers (AWS, Microsoft Azure, Google Cloud) for at least one critical or important function. DORA Article 29 forces this concentration into the open and subjects it to active supervisory oversight.

What changes in 2026 for cloud-heavy banks

• Pre-contract concentration assessment (Art. 29): Before signing any new contract for a critical/important function, the bank must document its assessment of vendor-level and group-level concentration, plus impact-of-failure analysis.
• Article 30 mandatory clauses: Audit rights, sub-outsourcing notice/veto, data location, business continuity guarantees, exit strategies. Hyperscalers have published "DORA addendums" but banks must verify line-by-line: generic SaaS contracts rarely meet Article 30 out of the box.
• Sub-outsourcing register: The RTS on subcontracting requires visibility down to all sub-contractors performing material parts of the service. Hyperscaler edge networks, CDN providers, identity sub-processors, support providers, all in scope.
• Lead Overseer regime: Designated CTPPs are subject to direct ESA oversight under Articles 31-44. Banks remain accountable but can rely on Lead Overseer assessments for the underlying provider, a meaningful reduction in due-diligence duplication.

Practical exit strategy expectations

Article 28(8) and the related RTS require documented, tested exit strategies for every contract supporting a critical or important function. For cloud, "exit" rarely means "lift-and-shift back to on-premises in a weekend", supervisors accept that realistic exit horizons are 12-36 months for core platforms, but they expect: an alternative provider identified, contracted reversibility (data extraction at no extra cost), tested data export (annual extraction validation), defined transition period, and budget reserved.

Incident Reporting: The Banking Workflow

Major incident classification under the RTS on incident classification uses six primary criteria and three secondary criteria. For banks, the most frequently triggering criteria are:

The 4h / 72h / 1-month workflow

The clock starts at classification as major, not at detection, but a major incident must be classified within 24 hours of detection. The internal challenge for banks is the speed of classification governance: a clear playbook, an empowered duty officer, and pre-cleared escalation channels to the executive team and NCA contact.

• 4 hours after classification: Initial notification (max 24h after detection). Submitted via the harmonised template through the NCA portal (BaFin MVP, ACPR OneGate, DNB-DLR, etc.).
• 72 hours after detection: Intermediate report with updated impact assessment, root cause analysis preliminary findings, mitigation actions taken.
• 1 month after detection: Final report covering full root cause, lessons learned, structural remediation plan, governance follow-up.

Full incident reporting workflow →

The Register of Information for Banks

Article 29 requires every authorised legal entity to maintain a Register of Information covering all contractual arrangements for the use of ICT services. The register is the single most data-intensive DORA artefact, and the most frequent source of supervisory findings.

Mandatory dimensions

• Entity-level fields: reporting entity, LEI, jurisdiction, type of authorisation
• Contract-level fields: counterparty LEI, type of service, function supported (critical/important flag), contract dates, termination rights, data location, sub-outsourcing chain
• Service-level fields: ICT service taxonomy (uniform across the EU per RTS), criticality classification, substitutability rating, contingency arrangements
• Group-level consolidation: intragroup arrangements, group-level concentration metrics

Annual submission

The register must be submitted to the competent authority annually by 30 April, in XBRL/XML format following the Commission Implementing Regulation template. The first full submission cycle (2025) revealed material data quality issues at most banks: missing LEIs, inconsistent service taxonomy, gaps in sub-outsourcing data, unclear function-to-contract mapping.

Penalties & Supervisory Measures

DORA's enforcement architecture combines direct administrative fines with supervisory measures applied through existing prudential channels. For banks under SSM supervision, the ECB's Section 13 enforcement powers, public censures, and Pillar 2 add-ons amplify the formal DORA fine framework.

12-Month Banking Implementation Roadmap

For a mid-to-large bank starting from a CRD/EBA baseline, full DORA alignment realistically takes 12-18 months. The following sequence reflects what works in practice, the deliverable order matters because several streams have hard dependencies.

5 Common Banking-Specific Pitfalls

1. Treating DORA as a CISO projectBanks that scope DORA as a security-team programme miss the third-party risk lift, the procurement contract renegotiation, the board governance refresh and the SREP integration. DORA is a CRO-sponsored, board-owned, cross-functional programme, not a CISO deliverable.
2. Under-classifying incidentsThe reporting threshold under the RTS is materially lower than most banks' historical "major incident" definition. Several banks materially under-reported in 2025 simply because their internal classification used outdated thresholds: generating supervisory findings during the first inspection cycle.
3. Treating the Register of Information as a once-a-year exerciseArticle 29 requires the register to reflect the current state at any moment, not just at 30 April submission. New contracts, terminations, sub-outsourcing changes, all must update the register in near-real-time. Banks running it as an annual data-collection campaign fail mid-year supervisory dip checks.
4. Missing the cloud sub-outsourcing visibilityThe RTS on subcontracting requires visibility down to all material sub-contractors. With hyperscalers, this means understanding where the support team is located, which sub-processors handle identity, which CDN sits in front. Banks that stop at "Tier 1 = AWS" miss the obligation entirely.
5. Skipping documented exit testingHaving an exit strategy on paper is no longer enough. Supervisors expect at least annual partial extraction tests: pulling representative data, validating restoration in an alternative environment, measuring time-to-recover. Banks without this evidence are receiving findings on Article 28(8).

Banking FAQ

Further Reading