How to Achieve DORA-Compliant Operational Resilience Without US Cloud Provider Dependency
The Digital Operational Resilience Act (DORA, Regulation EU 2022/2554) became enforceable on January 17, 2025, establishing uniform requirements for ICT security across the European financial sector. DORA structures its requirements around five pillars: ICT risk management, incident management and reporting, digital operational resilience testing, third-party ICT risk management, and cyber threat information sharing. Each pillar assumes that financial entities maintain genuine control over their ICT infrastructure and the data it processes.
That assumption creates a fundamental problem for European financial institutions relying on US-headquartered cloud providers. When a bank’s critical data exchange platforms are operated by providers subject to the CLOUD Act and FISA Section 702, the institution’s operational resilience is contingent on a foreign legal regime it cannot control. A US government demand for data access does not trigger the bank’s incident response processes. It bypasses them entirely. The provider complies without notifying the bank, and the bank cannot demonstrate the data sovereignty that DORA’s resilience framework implicitly requires.
This guide examines each DORA pillar through the lens of US cloud provider dependency and explains how European financial institutions can achieve genuine operational resilience through sovereign architecture that eliminates, rather than manages, the foreign access risk.
Executive Summary
Main Idea: DORA’s five pillars require European financial institutions to demonstrate operational resilience across ICT risk management, incident handling, resilience testing, third-party oversight, and information sharing. Each pillar is undermined when critical data platforms are operated by providers subject to foreign government access laws. Achieving DORA-compliant resilience requires sovereign architecture: customer-controlled encryption, single-tenant European deployment, and operational independence from US provider infrastructure.
Why You Should Care: DORA penalties reach up to 10% of annual turnover for financial entities and up to €5 million for critical ICT providers. In November 2025, the European Supervisory Authorities designated 19 ICT service providers as critical, including AWS, Microsoft Azure, and Google Cloud, subjecting them to direct EU supervisory oversight. BaFin expects initial DORA compliance findings by late 2025. Institutions whose resilience depends on providers they cannot fully oversee face both regulatory penalties and the operational risk DORA was designed to prevent.
5 Key Takeaways
- DORA’s ICT risk management pillar requires control you cannot delegate to a US provider. Financial entities must identify, protect, detect, respond to, and recover from ICT risks. When the provider holds encryption keys and is subject to foreign access laws, the institution has a residual risk it cannot mitigate through contractual measures alone.
- Incident reporting obligations assume full visibility into data access events. DORA requires classification and reporting of major ICT incidents within strict timelines. If a US provider complies with a government data demand without notifying the bank, the bank cannot report what it cannot see.
- Resilience testing must cover foreign government access scenarios. DORA mandates vulnerability assessments, penetration testing, and scenario-based testing. Institutions should include CLOUD Act data demands as a test scenario for any critical platform operated by a US provider.
- Third-party risk management requires evaluating provider jurisdiction, not just security certifications. DORA explicitly requires oversight of ICT third parties, including risk assessments that account for the provider’s legal exposure to foreign government demands.
- Sovereign architecture eliminates dependency rather than managing it. Customer-controlled encryption keys, single-tenant European deployment, and policy-enforced data residency remove the foreign access risk at the architectural level, satisfying all five DORA pillars simultaneously.
DORA’s Five Pillars and the US Provider Dependency Problem
Pillar 1: ICT Risk Management
DORA Article 6 requires financial entities to establish comprehensive ICT risk management frameworks covering identification, protection, detection, response, and recovery. The framework must address internal and external risks, including those posed by third-party providers, with governance oversight extending to board level.
For German banks, BaFin’s BAIT framework (applicable through December 2026 for transitioning institutions) has long required IT risk management. DORA’s Article 6(4) introduces a dedicated ICT risk control function with defined independence requirements that BaFin has noted resembles but is not identical to the existing BAIT information security officer.
The fundamental challenge is this: an ICT risk management framework that identifies “US government data access via cloud provider” as a risk but treats it as acceptable because of Standard Contractual Clauses or the EU-US Data Privacy Framework is building resilience on uncertain legal ground. SCCs and the DPF are legal transfer mechanisms, not technical protections. They do not prevent a CLOUD Act demand from succeeding. DORA requires financial entities to implement measures that genuinely manage ICT risks, not merely document them. Where the risk is architectural, the response must be architectural.
Pillar 2: Incident Management and Reporting
DORA mandates structured processes for detecting, classifying, and reporting major ICT incidents. The EBA’s reporting timeline requires initial notification within 4 hours of classification, an intermediate report within 72 hours, and a final report within one month. Significant incidents must be reported to national competent authorities.
This pillar assumes complete visibility into events affecting the institution’s data. When a US provider receives a National Security Letter or FISA court order compelling data production, the provider may be legally prohibited from notifying the customer. The financial institution has no visibility into the access event and therefore cannot classify or report it. This creates a structural gap in the institution’s incident management capability that no process improvement can close, because the gap is built into the provider relationship itself.
Sovereign architecture resolves this by ensuring the provider cannot access decrypted data regardless of legal demands. When the institution controls encryption keys in its own HSM, a government demand to the provider produces only ciphertext. The institution’s audit logging captures all legitimate access events, providing the complete visibility DORA’s incident reporting requires.
Pillar 3: Digital Operational Resilience Testing
DORA requires regular testing of operational resilience, including vulnerability assessments, penetration tests, and scenario-based exercises. Critical entities may be required to conduct Advanced Threat-Led Penetration Testing (TLPT) aligned with the TIBER-EU framework.
Resilience testing that excludes foreign government data access scenarios provides an incomplete picture for any institution using US-operated cloud services. A comprehensive test program should model the scenario where a critical data platform provider is compelled to produce customer data, evaluating whether the institution’s architecture prevents data exposure, whether monitoring systems detect the attempt, and whether incident response procedures activate correctly.
With customer-controlled encryption, this test has a definitive outcome: the provider cannot produce readable data. The scenario becomes a validation of architectural controls rather than an exposure of unmitigable risk.
Pillar 4: Third-Party ICT Risk Management
DORA’s third-party risk management requirements are among its most consequential provisions. Financial entities must assess and continuously monitor risks from ICT providers, ensure contractual agreements include security provisions, audit rights, termination rights, exit strategies, and incident notification procedures. The European Supervisory Authorities designated 19 providers as critical ICT third-party providers (CTPPs) in November 2025, bringing AWS, Microsoft Azure, Google Cloud, and others under direct EU supervisory oversight.
DORA Article 28(3) requires financial entities to maintain a Register of Information documenting all contractual arrangements with ICT third-party providers. BaFin required German institutions to submit their initial registers by April 11, 2025. This register must capture not just the existence of the relationship but the nature of services, data locations, and risk classifications.
For institutions using US-operated platforms for sensitive data exchange, the third-party risk assessment must honestly evaluate the provider’s jurisdictional exposure. The EBA has stated that relying solely on certifications like ISO 27001 is insufficient for risk assessment. The assessment must address whether the provider can be compelled to produce customer data under foreign law and whether the institution’s architecture prevents readable data exposure in that scenario.
DORA also requires viable exit strategies. Financial institutions must demonstrate they can transition away from any ICT provider without operational disruption. This requirement directly addresses the vendor dependency risk that concentrating critical functions with a small number of US hyperscale providers creates. Institutions should evaluate whether their current architecture supports migration and whether alternative providers can deliver equivalent functionality under European jurisdiction.
Pillar 5: Cyber Threat Information Sharing
DORA encourages financial entities to participate in threat intelligence sharing arrangements. While participation is not mandatory, institutions must inform regulators about their information-sharing activities. Effective sharing requires institutions to understand their own threat landscape. An institution lacking visibility into potential government-compelled data access through its cloud providers has an incomplete threat model. Sovereign architecture clarifies the landscape by eliminating foreign access ambiguity, allowing the institution to focus sharing efforts on genuine external cyber threats.
What Sovereign Architecture Looks Like Under DORA
Achieving DORA-compliant operational resilience without US cloud provider dependency requires three architectural capabilities that align with the GTM principle that data sovereignty is a technical architecture, not a contract clause.
Customer-Controlled Encryption Keys
The institution generates and stores encryption keys in its own hardware security module, located on premises or in an institution-controlled European data center. The cloud platform processes encrypted data but never possesses decryption keys. This is fundamentally different from Bring Your Own Key (BYOK) arrangements where the provider retains access to key material. The test is straightforward: if the provider receives a legal demand, can it produce decrypted data? If yes, the encryption model does not satisfy DORA’s risk management requirements for critical functions.
Single-Tenant European Deployment
Multi-tenant platforms serve thousands of customers from shared infrastructure optimized for the provider’s global footprint. Single-tenant deployment on dedicated European infrastructure serves one customer from isolated systems where access controls are governed by European law. Combined with customer-controlled encryption, single-tenant deployment eliminates both the logical access path (encryption keys) and the physical access path (shared infrastructure) that create provider dependency.
Operational Independence and Exit Capability
DORA requires viable exit strategies for all ICT third-party arrangements supporting critical functions. This means financial institutions need platforms built on standard protocols that support data portability and operational independence. The architecture should allow the institution to deploy on premises, in a European private cloud, or in provider-hosted European infrastructure, with the flexibility to migrate between options without data loss or operational disruption. This addresses DORA’s concentration risk concerns and BaFin’s expectation that outsourced functions can be repatriated.
DORA Pillar Alignment: US Provider Dependency vs. Sovereign Architecture
| DORA Pillar | Risk With US Provider Dependency | Sovereign Architecture Response |
|---|---|---|
| ICT Risk Management | Residual foreign access risk cannot be mitigated contractually | Risk eliminated at architectural level; provider cannot access data |
| Incident Management | Government demands may bypass institution’s visibility and reporting | Complete audit trail; all access events visible to institution |
| Resilience Testing | Foreign access scenario exposes unmitigable risk | Foreign access scenario validates architectural controls |
| Third-Party Risk | Provider jurisdiction creates structural dependency | Customer-controlled keys and single-tenant deployment remove dependency |
| Information Sharing | Incomplete threat model due to provider-level access ambiguity | Clear threat landscape; focus on genuine external threats |
Implementation: Transitioning to DORA-Compliant Sovereign Architecture
Phase 1: Map Critical ICT Dependencies
Use the DORA Register of Information as the starting point. Identify every ICT third-party arrangement supporting critical or important functions, then evaluate each provider’s jurisdiction, encryption model, and key management architecture. For each US-operated service, document whether the provider can access decrypted customer data under any circumstances, including legal compulsion. This assessment feeds directly into your ICT risk management framework and satisfies BaFin’s expectation for honest risk evaluation.
Phase 2: Prioritize by Regulatory Exposure
Not all ICT services carry equal DORA risk. Prioritize services processing the most sensitive data: customer financial records, managed file transfer for regulatory submissions, internal audit communications, cross-border transaction records, and board-level correspondence. These are the functions where a foreign government data access event creates the greatest regulatory, reputational, and operational exposure.
Phase 3: Deploy Sovereign Architecture
Transition prioritized functions to platforms providing customer-controlled encryption, single-tenant European deployment, and policy-enforced data residency with geofencing. Validate through independent testing that the provider cannot access decrypted data. Configure comprehensive audit logging to support DORA’s incident reporting timelines and ongoing monitoring obligations. Establish incident response procedures that account for the new architecture’s capabilities.
Phase 4: Demonstrate Compliance Through Evidence
DORA compliance is demonstrated through evidence, not assertions. Maintain documentation showing encryption key generation in the institution’s HSM, single-tenant deployment configuration, geofencing enforcement, and complete audit trails. Prepare this evidence package for BaFin examinations, ECB supervisory reviews, and the periodic resilience testing DORA requires. Sovereignty you can prove is sovereignty that protects.
Operational Resilience Requires Operational Sovereignty
DORA’s five pillars describe what operational resilience looks like. But resilience cannot exist where control does not. When a financial institution’s critical data platforms are operated by providers subject to foreign government access laws, the institution’s resilience framework has a structural gap that no contractual provision, certification, or process improvement can close.
Sovereign architecture, built on customer-controlled encryption, single-tenant European deployment, and genuine operational independence, closes that gap by eliminating the dependency rather than managing it. European financial institutions that implement this architecture are not merely complying with DORA. They are building the zero trust resilience infrastructure that Europe’s financial regulators envision.
Kiteworks Helps European Financial Institutions Achieve DORA-Compliant Operational Resilience
The Kiteworks Private Data Network delivers sovereign architecture purpose-built for DORA’s five-pillar framework. Kiteworks operates on a customer-managed encryption model where the institution generates and retains encryption keys in its own HSM. Kiteworks cannot access decrypted content and cannot comply with foreign government demands to produce readable data because it does not possess the keys.
Kiteworks deploys as a single-tenant instance on dedicated European infrastructure, including on-premises, private cloud, and hardened virtual appliance options, giving institutions the deployment flexibility and exit capability DORA requires. Built-in geofencing enforces data residency at the platform level. Comprehensive audit logging supports DORA’s incident reporting timelines and provides the continuous monitoring evidence that regulators expect. Kiteworks supports DORA compliance across all five pillars through a unified approach to ICT risk management for sensitive content.
The platform unifies secure file sharing, email protection, managed file transfer, and web forms under a single governance framework, enabling financial institutions to address DORA’s third-party risk requirements across all data exchange channels with one architecture, one set of controls, and one supervisory evidence package.
To learn more about achieving DORA-compliant operational resilience without US cloud provider dependency, schedule a custom demo today.
Frequently Asked Questions
No. DORA does not prohibit using US-headquartered ICT providers, but it requires institutions to manage the risks these relationships create. The regulation mandates comprehensive risk assessment, contractual controls including exit strategies, and continuous monitoring for all ICT third-party arrangements. For US-operated services supporting critical functions, the risk assessment must evaluate CLOUD Act and FISA 702 exposure. Institutions can continue using US providers if they implement architectural controls, such as customer-controlled encryption keys, that eliminate the provider’s ability to access decrypted data, thereby neutralizing the foreign access risk at the technical level.
Financial entities face penalties of up to 10% of annual turnover or €10 million for serious breaches, while individual senior managers can face fines up to €1 million. DORA penalties apply from the January 17, 2025 enforcement date with no grace period. Competent authorities can impose inspections, demand cessation of non-compliant practices, and issue public statements identifying the non-compliant entity. Beyond financial penalties, institutions face reputational damage and potential loss of customer trust. BaFin has stated it will intensify outsourcing oversight in 2025 and expects first compliance findings by late 2025, making prompt implementation of sovereign architecture a priority.
The ESA designation of 19 critical providers in November 2025 subjects them to direct EU supervisory oversight, but it does not reduce banks’ own compliance obligations. Banks must still conduct independent risk assessments, maintain contractual controls, and implement exit strategies for these providers. The designation means regulators are now examining both the bank’s risk management and the provider’s operations. Banks should view this as heightened scrutiny of their third-party risk arrangements rather than a regulatory endorsement of these providers. Implementing customer-controlled encryption and single-tenant deployment demonstrates that the bank has addressed the specific risks these designated providers carry.
German banks should focus on three priorities: completing the DORA Register of Information, ensuring contractual compliance for ICT arrangements, and documenting architectural risk mitigations. BaFin required initial register submissions by April 11, 2025, and has signaled that contract adjustments for third-party ICT arrangements are an immediate priority. BaFin expects a risk-based timeline for compliance where institutions demonstrate progress. Banks should document their encryption key management architecture, data residency controls, and data governance frameworks as evidence of genuine risk management. For institutions transitioning from BAIT to DORA, BaFin’s gap analysis document provides a practical comparison of pre-existing and new ICT risk management requirements.
Sovereign cloud offerings address some dependency concerns but often involve partnerships with US hyperscale providers, potentially retaining US technology dependencies in the underlying infrastructure. DORA requires institutions to assess the full supply chain, including sub-outsourcing arrangements. A sovereign cloud built on Microsoft Azure technology may still involve US code dependencies and operational touchpoints. Institutions should evaluate whether the sovereign offering provides genuine independence, customer-controlled encryption keys, and full operational control, or whether sovereignty comes with reduced features and premium pricing. The key question remains whether any party in the chain can access decrypted data under foreign legal compulsion, regardless of how the service is branded. Institutions evaluating alternatives should apply the same zero trust data exchange criteria to sovereign cloud offerings as they would to any other provider.
Additional Resources