DORA Compliance for US Banks with EU Branches: ICT Risk Mandate

DORA compliance for US banks with EU operations became a legal obligation on January 17, 2025, when Regulation (EU) 2022/2554 — the Digital Operational Resilience Act (DORA) — entered full application across all 27 EU Member States. US institutions including the EU-licensed subsidiaries and branches of JPMorgan Chase, Citibank, Bank of America, Goldman Sachs, and Morgan Stanley are in scope. Non-compliance exposes those entities to fines of up to 2% of global annual turnover levied by national competent authorities (NCAs — the national financial regulators in each EU Member State, such as BaFin in Germany, the AMF in France, and the Central Bank of Ireland). This guide covers the five DORA pillars, the Register of Information (ROI) submission cycle, Threat-Led Penetration Testing (TLPT) obligations, mandatory third-party contract clauses, and the action steps your compliance team must take now.

// 01 DORA Compliance for US Banks: Jurisdictional Scope

DORA is a directly applicable EU regulation — it requires no national transposition and applies automatically to every qualifying financial entity. Article 2 of DORA lists 21 categories of in-scope entities: credit institutions, payment institutions, electronic money institutions, investment firms, central counterparties, trade repositories, insurance and reinsurance undertakings, crypto-asset service providers, and more.

For US-headquartered banking groups, scope is determined by the EU footprint of the group:

• EU subsidiaries licensed as credit institutions or investment firms under EU law must comply in full as standalone regulated entities.
• EU branches of third-country banks operating in any Member State — such as a US bank's Frankfurt branch licensed directly by BaFin or a Dublin branch authorised by the Central Bank of Ireland — are fully in scope.
• Intragroup ICT arrangements: if the US parent provides ICT services (data hosting, security operations, software platforms) to its EU subsidiary, those intragroup arrangements must satisfy DORA's third-party contracting requirements even though the US parent is not itself a regulated EU entity.
• US ICT service providers: US-based cloud hyperscalers, data centre operators, and SaaS vendors serving EU financial entities as critical or important function providers fall under DORA's third-party oversight framework regardless of where they are incorporated.

In practice, large US banks implement DORA controls group-wide rather than ring-fencing EU entities with separate control sets — partly because many DORA mandates (incident response procedures, third-party due diligence, penetration testing) align closely with NIST CSF 2.0 and FFIEC IT examination guidance already applied to their US operations, and partly because operational failures in a EU subsidiary carry reputational consequences that reach the global parent.

// 02 The Five Pillars of DORA

The three European Supervisory Authorities (ESAs — the EBA for banking, ESMA for securities and markets, and EIOPA for insurance and pensions) have published binding Regulatory Technical Standards (RTS — binding implementing rules that specify exactly how each DORA requirement must be met) and Implementing Technical Standards (ITS — standardised formats and templates) for each pillar. The five-pillar framework operates as follows.

Pillar 1: ICT Risk Management

Article 6 of DORA requires every in-scope entity to maintain a documented ICT risk management framework approved and overseen directly by the management body (board of directors or equivalent). The board — not just the CISO — is legally accountable for:

• Identifying, classifying, and documenting all ICT assets (hardware, software, data stores, network components) that support business operations
• Mapping the dependency between those assets and the entity's business functions, with a formal distinction between critical or important functions (CoIFs — services whose disruption would materially harm the entity's financial performance or its compliance with regulatory obligations) and non-critical ones
• Setting ICT risk tolerance levels in writing, with explicit board sign-off
• Allocating adequate budget for ICT resilience measures
• Ensuring business continuity and disaster recovery (BC/DR) plans are documented and tested at least annually

Smaller in-scope entities below defined size thresholds — certain payment institutions and electronic money institutions — may follow a simplified ICT risk management framework defined in a separate ESA RTS, with streamlined mandatory controls.

Pillar 2: ICT-Related Incident Reporting

Articles 17–23 require financial entities to classify ICT incidents using ESA-standardised criteria covering: number of clients affected, aggregate financial impact, data integrity consequences, geographic spread, and service downtime duration. Incidents meeting the threshold for classification as major trigger a mandatory three-stage reporting cascade to the national competent authority:

US banks must ensure their EU subsidiaries' Security Operations Centres (SOCs — teams that monitor IT systems 24/7 for threats and incidents) are equipped to classify incidents against DORA criteria and trigger this reporting chain without waiting for approval from the US parent, since the 4-hour initial deadline leaves no margin for transatlantic escalation cycles.

Pillar 3: Digital Operational Resilience Testing

All in-scope entities must run an annual basic testing programme covering:

• Vulnerability assessments and network security scans
• Open-source intelligence (OSINT — using publicly available sources to identify exposed assets, leaked credentials, or misconfigured services) reviews
• Configuration hardening checks against vendor baselines
• Failover and data recovery drills

Significant entities — including G-SIIs (Globally Systemically Important Institutions, the world's largest banks whose failure could destabilise the global financial system, designated annually under CRD V/CRR2) — must additionally complete TLPT at least every three years. TLPT is covered in full in the next section.

Pillar 4: ICT Third-Party Risk Management

Articles 28–32 require pre-contract due diligence on all ICT service providers, enhanced monitoring for providers supporting CoIFs, maintenance of the Register of Information (ROI), and compliance with prescriptive contract clause requirements. This pillar also establishes the ESA-level oversight mechanism for critical ICT third-party providers (CTPPs — the subset of ICT providers whose failure or disruption could destabilise the EU financial system). The ESAs designated 19 CTPPs in November 2025, including AWS, Microsoft Azure, Google Cloud, IBM, Oracle, SAP, and Deutsche Telekom — over 65% of EU financial entities rely on at least two of the top three hyperscalers for critical functions.

Pillar 5: Information Sharing

Article 45 encourages financial entities to participate in cyber threat intelligence-sharing communities. Participation is voluntary, but entities must cooperate with regulators on sharing data related to CTPPs and major ICT incidents. The ESAs have indicated that active participation in sharing communities will be treated positively in supervisory assessments.

// 03 TLPT: Threat-Led Penetration Testing Obligations

DORA compliance for US banks operating at significant scale requires completion of TLPT under Articles 26–27 of DORA. TLPT is not a standard penetration test. It is an intelligence-driven red team exercise aligned with the TIBER-EU framework (Threat Intelligence-Based Ethical Red Teaming — a methodology developed by the European Central Bank in which accredited testers simulate sophisticated adversaries against live production systems while the institution's defenders have no prior knowledge the test is running). ESA RTS published in February 2025 codified the TIBER-EU approach into binding DORA requirements.

Mandatory TLPT requirements under Articles 26–27:

• Accredited external testers — red team operators must meet TIBER-EU qualification criteria; an institution cannot conduct TLPT using internal staff alone
• Live production systems — test environments are insufficient; testers must target real infrastructure supporting critical or important functions
• Intelligence-driven scenarios — attack scenarios must be based on current threat intelligence relevant to the institution's sector and geographic footprint; generic test scripts do not satisfy the requirement
• Covert execution — the institution's blue team (defensive security operations) must not know the test is running, so detection and response capability is measured under realistic conditions
• CTPP participation — if a critical function runs on a CTPP's infrastructure (e.g., AWS or Azure), that CTPP must grant access and cooperate with the test scope
• Remediation attestation — following the exercise, the entity must remediate all critical findings and submit a written attestation to the competent authority under Article 27(6)

TLPT results are cross-border portable: a certificate issued by one Member State's competent authority can be recognised by others, allowing a G-SII to avoid running duplicate exercises for every EU jurisdiction in which it operates. CREST maintains a registry of DORA-qualified TLPT providers and accredited red team operators.

Understanding the adversary tactics TLPT exercises simulate helps security teams scope realistic scenarios. See our threat actor OPSEC playbook and evasion techniques guide for context on the attacker behaviours TLPT red teams replicate.

The diagram below maps the full ICT third-party risk assessment and contracting flow required under DORA's Pillar 4.

// 04 Pillar 4 in Depth: Register of Information

Every EU-licensed subsidiary of a US bank must maintain a continuously updated ROI covering all ICT contractual arrangements — at entity, sub-consolidated, and consolidated group levels. The ROI is not a simple vendor list. The ESA implementing technical standards on ROI reporting define a structured data model with mandatory fields across the following categories:

ROI Submission Timeline

The deadline structure for the ROI spans two reporting cycles. The figure below maps the key DORA compliance milestones for US banks with EU operations from the January 2025 application date through the 2026 reporting cycle.

The March 31, 2026 deadline is the most immediately pressing for US banks: NCAs in some Member States set internal cut-off dates earlier than this, so EU subsidiaries should confirm their NCA's specific submission window and ensure ROI data accurately reflects the December 31, 2025 reference snapshot.

// 05 Mandatory Contract Clauses for ICT Third-Party Providers

Article 30 of DORA sets minimum mandatory contract terms for all ICT service agreements entered into by EU-regulated entities. The requirements split into two tiers based on whether the service supports a critical or important function.

Baseline clauses — all ICT contracts (Article 30(2))

Every ICT service contract with an EU-regulated entity must include:

• A clear, complete description of all services provided and the locations from which they are delivered
• Provisions specifying where data is processed and stored, including restrictions on cross-border transfers outside approved jurisdictions
• The financial entity's rights to access, recover, and receive return of its data at contract termination or upon the provider's insolvency
• Incident notification obligations — the provider must alert the financial entity promptly to any ICT incident affecting the contracted service
• Cooperation requirements with the financial entity's competent authority, including participation in audits and on-site inspections
• Termination rights and orderly exit assistance provisions

Enhanced clauses — critical or important functions (Article 30(3))

Contracts for services supporting a critical or important function must additionally include all of the following:

Practical implication for US banks: Standard master service agreements (MSAs) and cloud service addenda from US vendors — including those from US hyperscalers serving EU subsidiaries — typically do not include all of these clauses. Procurement and legal teams must negotiate custom DORA-compliance schedules or addenda for every contract under which a US parent or third-party vendor provides ICT services to an EU-regulated entity.

Given that SAP — one of the 19 designated CTPPs — has been the target of supply chain compromises, US banks relying on SAP for ERP and finance functions must pay particular attention to subcontracting transparency and incident notification clauses. Our analysis of the SAP npm mini Shai Hulud supply chain attack illustrates precisely how a CTPP-tier vendor can be compromised through its software distribution chain — exactly the scenario DORA's third-party risk pillar is designed to surface and mitigate before it reaches a financial entity's production environment.

// 06 Penalties for DORA Non-Compliance

Administrative sanctions under Articles 50–51 of DORA are substantial and enforcement powers have been active since January 17, 2025:

Beyond financial penalties, NCAs can issue public censures, mandate the suspension of specific ICT services, temporarily or permanently ban individuals from management functions, and — in serious cases — revoke the regulated entity's authorisation to operate. A 2025 DLA Piper analysis found significant divergence in how EU Member States calculate and cap the 2% fine, making multi-jurisdiction penalty exposure difficult to model precisely — an argument for achieving full compliance rather than managing to a penalty budget.

For CTPPs, the ESA has the power to recommend cybersecurity measures, oppose subcontracting arrangements that threaten financial stability, and compel financial entities to suspend or terminate CTPP services as a last resort. This means a US bank's choice of cloud provider is now, in part, a regulatory decision subject to ESA review.

// 07 DORA Compliance Roadmap: Priority Actions for US Banks

The following steps are ordered by urgency for US banks whose EU subsidiaries are still working through the compliance programme.

Overdue — address immediately if not complete:

• Board-approved ICT risk management framework — must exist in writing, covering asset inventory, risk classification, CoIF mapping, BC/DR testing cadence, and board-level budget sign-off per Article 6
• Incident classification and 4-hour reporting procedure — SOC playbooks must embed DORA major-incident classification criteria and the NCA notification chain; validate the chain in a tabletop exercise with timed runs
• ICT contract inventory and remediation — audit all ICT service agreements used by the EU entity against Article 30(2) and 30(3) mandatory clause requirements; renegotiate or terminate every non-compliant contract
• Register of Information data population — build the ROI in the ESA-prescribed data model, capturing all ICT arrangements at entity, sub-consolidated, and consolidated levels, with LEIs, criticality flags, and subcontracting disclosures

Due March 31, 2026 — imminent:

• ROI accuracy audit against the December 31, 2025 reference date — systematically review the ROI against the actual state of all ICT arrangements as of that date; any vendor additions, contract renewals, or service changes in H2 2025 must be reflected before filing
• Confirm NCA internal submission deadline — national competent authorities may set cut-off dates earlier than March 31; contact the relevant NCA directly to confirm the actual filing window

Ongoing — 3-year cycle from 2025:

• TLPT planning and scoping — identify CREST-accredited red team providers, negotiate CTPP participation in the test scope, and align with the NCA on test parameters and intelligence sourcing before engaging the provider
• Annual basic testing programme — vulnerability assessments, configuration hardening reviews, OSINT exposure checks, and recovery drills must be completed, documented, and signed off each year as a baseline between TLPT cycles

Embedding zero-trust architecture controls into the ICT risk management framework addresses several DORA requirements simultaneously: continuous asset verification, least-privilege access for third parties, and data movement logging that satisfies both the ROI's service-mapping requirements and the major-incident investigation audit trail. See our zero-trust data movement security gaps guide for a practical implementation approach aligned to the visibility DORA requires.

// 08 Conclusion

DORA compliance for US banks with EU branches requires immediate and sustained operational action. The five pillars are not aspirational guidelines — enforcement began January 17, 2025, fines are live, and the ESA oversight framework for the 19 designated critical ICT providers is operational. The March 31, 2026 Register of Information submission deadline is the most pressing near-term milestone: US banks whose EU subsidiaries have not yet validated their ROI data against the December 31, 2025 reference snapshot should treat this as their highest-priority compliance task. For authoritative guidance on the ESA oversight framework for designated CTPPs, consult the ESA DORA Oversight Activities Guide (JC 2025/29).

Subscribe to the CiphersSecurity weekly threat and compliance digest for DORA regulatory updates, new ESA technical standards, and enforcement actions as they are published →