DORA Compliance Deadlines in 2026: What US-Based Vendors Serving EU Financial Clients Need to Know
DORA does not directly regulate a US company. It regulates EU financial entities — banks, insurers, investment firms, payment institutions — and those entities are now required to push DORA's contractual requirements down onto every ICT third party they rely on, wherever that vendor is based. If you sell software or managed services to an EU bank, insurer, or credit institution, you don't file anything with a European regulator. You sign a contract that already has DORA's requirements baked into it, or you lose the deal to a vendor who will.
The Digital Operational Resilience Act (Regulation (EU) 2022/2554) entered into force on January 16, 2023, and has applied since January 17, 2025, according to the European Securities and Markets Authority (ESMA, Digital Operational Resilience Act (DORA)). Eighteen months into applicability, 2026 is the year the enforcement phase is real rather than theoretical: the European Supervisory Authorities (ESAs) published their first list of designated Critical ICT Third-Party Providers (CTPPs) on November 18, 2025, and national regulators are now actively assessing financial entities' Registers of Information against the contracts those entities actually signed (ESMA, ESAs designate critical ICT third-party providers).
Who DORA actually regulates
DORA's Article 2 scope covers a long list of EU financial entities: credit institutions, payment institutions, investment firms, insurance and reinsurance undertakings, crypto-asset service providers, central securities depositories, and more, along with the ICT third-party providers that support them (Regulation (EU) 2022/2554, EUR-Lex). Notably, providers of payment-processing activities and payment infrastructure — including payment card schemes — are themselves treated as ICT third-party service providers under DORA's Recital 63, not as financial entities in their own right (EBA Single Rulebook Q&A, 2024_7290).
A US-based company is not a "financial entity" under Article 2 and has no direct registration or supervisory relationship with an EU regulator by default. That is the source of the common misconception that DORA is an EU-only problem. It isn't, because of how the obligation flows.
How the obligation actually reaches a US vendor
DORA's Article 30 requires every EU financial entity to build specific provisions into its contracts with ICT third-party providers — and those provisions apply regardless of where the provider is headquartered. Every contract for an ICT service, per Article 30(2), must include, at minimum:
- A clear description of the functions and services supplied, including any subcontracted components
- The locations where data will be processed and stored, and the conditions for any relocation
- Provisions covering the accessibility, integrity, security, and protection of data, including personal data
- The assistance the provider must supply in the event of an ICT incident affecting the service, at no additional cost or at a pre-agreed cost
- An obligation to cooperate fully with the financial entity's competent and resolution authorities
- Termination rights and minimum notice periods that satisfy supervisory expectations
Where the service supports a function the financial entity has classified as critical or important, Article 30(3) adds requirements for full service-level descriptions, incident notification timelines, exit strategies, and audit and access rights for the financial entity and its regulators (DORA and Third-Party ICT Providers: The Guide for Suppliers; text drawn from Regulation (EU) 2022/2554, Article 30). A US-based MSSP, SaaS vendor, or cloud provider does not need to file anything with an EU regulator to be affected by this — it needs to be prepared to sign a contract carrying these obligations, and to actually operate that way, because its EU financial-entity customer's own regulator will audit the contract and the vendor's performance against it.
The exception: becoming a Critical ICT Third-Party Provider
There is one path to direct EU oversight. If a provider's services are concentrated enough across the EU financial sector, the ESAs can designate it a Critical ICT Third-Party Provider under DORA Article 31, which brings it under direct oversight by a Lead Overseer drawn from the EBA, EIOPA, or ESMA (EBA, DORA Oversight). A provider not on that list can also proactively opt in under Article 31(11) by submitting a reasoned application in English, along with a fixed fee of €50,000, to the ESAs' shared oversight mailbox — the ESAs commit to responding within six months of a complete application (EBA, DORA Oversight). Opting in is a narrow, deliberate move for providers with enough EU financial-sector concentration to want a single, harmonized oversight relationship instead of dozens of individual customer audits; most US vendors serving a handful of EU clients have no reason to pursue it.
An implementation checklist for a US vendor with EU financial clients
- Inventory which of your contracts are actually in scope. Any agreement where an EU-regulated bank, insurer, investment firm, or payment institution is the customer is a candidate, regardless of your own location.
- Read your current contract language against Article 30(2) and, where applicable, 30(3). Most US vendor master service agreements were not drafted with DORA in mind and are missing specific incident-assistance, subcontracting-disclosure, and audit-rights language.
- Build an incident notification process that can meet your customer's regulatory timeline, not just your own SLA. Your EU financial-entity customer has its own DORA-driven incident reporting obligations upstream to its regulator, and your notification to them is the first link in that chain.
- Document your subcontracting chain. If you use a cloud provider, a sub-processor, or an offshore analyst team, your EU customer's Register of Information has to capture that chain. Be ready to disclose it accurately and keep it current.
- Confirm your data location and relocation commitments in writing. Article 30(2) requires this explicitly, and it is one of the first things a supervisory audit checks against the actual infrastructure.
- Map your existing controls to a recognized framework your customer's auditor will already understand. A SOC 2 Type II report and a NIST Cybersecurity Framework mapping won't satisfy DORA on their own, but they give your customer's compliance team a starting point instead of a blank page.
Where this connects to broader EU cyber regulation
DORA does not stand alone. Financial entities and their vendors operating in the EU are frequently navigating DORA alongside the NIS2 Directive's incident reporting and supply-chain requirements for essential and important entities. If your organization needs a combined DORA and NIS2 readiness program rather than treating them as separate compliance tracks, that overlap is exactly what our NIS2 and DORA compliance service is built around, delivered by a team resident in the EU for the regulatory and data-residency conversations that require it.
US-based financial services organizations without direct EU exposure still face their own parallel third-party risk pressure domestically — see how that plays out for credit unions under NCUA's vendor-risk expectations in our related coverage, and our financial services industry page for how US regulatory frameworks like GLBA Safeguards and FFIEC CAT compare to DORA's approach.
Frequently asked questions about DORA and US vendors
Does DORA apply to my US company if we only have one or two EU financial clients?
Not directly under DORA's Article 2 scope, which covers financial entities, not their vendors. But your contract with that EU financial entity is legally required to carry DORA's Article 30 provisions, and your customer's regulator can examine how you actually perform against them. In practice, that means yes, you need to comply with the contractual terms even without direct regulatory registration.
When did DORA actually become enforceable?
DORA entered into force on January 16, 2023 and has applied since January 17, 2025 (ESMA). The first Critical ICT Third-Party Provider designations followed in November 2025, meaning 2026 is the first full year of active oversight under the framework.
What is a Critical ICT Third-Party Provider, and should we try to become one?
A CTPP is a provider the European Supervisory Authorities have determined is systemically important enough to the EU financial sector to warrant direct oversight under DORA Article 31. Most US vendors with a handful of EU financial clients have no strategic reason to pursue this designation; it makes sense mainly for providers whose services are concentrated across many EU financial entities.
Does DORA reach our subcontractors and cloud providers too?
Yes. Article 30(2) requires your contract with the EU financial entity to describe any subcontracted components of the service, and your customer's Register of Information has to capture that full chain, not just your direct relationship with them.
Is a SOC 2 report or ISO 27001 certification enough to satisfy DORA?
No single existing certification fully satisfies DORA's contractual and operational-resilience requirements on its own, but a current SOC 2 Type II report or ISO 27001 certification gives your EU customer's compliance and audit teams a recognized starting point, which speeds up their own DORA-driven due diligence on your organization.
How is DORA different from NIS2 for a vendor serving both financial and non-financial EU clients?
DORA is sector-specific to financial entities and their ICT providers, with detailed contractual and third-party oversight requirements. NIS2 is broader, covering essential and important entities across many sectors, with its own separate incident reporting timelines. A vendor serving both financial and non-financial EU clients may need to track both frameworks in parallel rather than treating one as a subset of the other.