Three EU regulations have turned sovereign cloud from a preference into a hard compliance requirement for specific industries and workload types. DORA entered full enforcement in January 2025 and targets financial entities. NIS2 applies to essential services — energy, healthcare, and more. The EU AI Act reaches full application in August 2026 and creates data governance obligations for high-risk AI systems that flow directly into infrastructure decisions.
If you’re running FinTech, HealthTech, or regulated SaaS, your cloud infrastructure is no longer purely a technical call. For certain workloads, it’s a regulatory one.
If you need the basics on what sovereign cloud actually means and how providers differ, start with understanding sovereign cloud.
Why Are EU Regulations Now Directly Shaping Cloud Strategy?
Until recently, GDPR was the primary data protection baseline for EU organisations — but it left cloud infrastructure choices largely to each organisation’s own risk assessment. DORA, NIS2, and the EU AI Act each add specific obligations around exit strategies, supply chain sovereignty, and AI data governance that directly constrain the infrastructure decisions you can make.
Things tightened further in October 2025 when the European Commission published its Cloud Sovereignty Framework, defining sovereignty objectives for EU institutions procuring cloud services. The context matters here: US hyperscalers control more than 70% of the EU cloud market and they’re subject to US extraterritorial laws — the CLOUD Act and FISA — that allow US authorities to compel data access regardless of where the servers physically sit. Regulators have taken note and are building that reality into compliance frameworks.
Before we get into each regulation, let’s be precise about the terminology, because it matters:
- Data residency: Servers are physically located within a geographic boundary. Location alone doesn’t guarantee legal protection.
- Data localisation: A policy mandate that specific data categories cannot leave national borders.
- Data sovereignty: Data is subject to the laws and governance of a specific jurisdiction, with no foreign government access.
Most regulated workloads now require sovereignty, not just residency. A US hyperscaler running EU-based servers gives you data residency. It does not give you data sovereignty when US law can compel disclosure regardless of server location.
What Does DORA Require for Financial Entity Cloud Strategy?
DORA applies to all financial entities regardless of company size — FinTech companies, banks, payment processors, insurance firms, and investment firms. If you’re a 50-person FinTech processing payments, you’re in scope. Same as the major banks.
The mandatory exit strategy under Article 28 requires financial entities to maintain documented, tested, and auditable plans to migrate away from any critical ICT provider without service disruption. Audits are already happening. If your institution can’t demonstrate operational resilience, you’re looking at remediation requirements.
DORA’s ICT concentration risk rules also require that critical functions not be too heavily concentrated with a single provider. Running your entire platform on one hyperscaler’s managed services creates a compliance problem if those services are critical functions.
Here’s where the practical challenge bites: if your platform is tightly coupled to proprietary APIs from a single vendor, your documented exit plan may require a multi-year migration. That’s not a contingency plan — that’s lock-in with a compliance label on it.
DORA Article 28 also mandates specific contractual provisions with all critical ICT providers: audit rights, data access guarantees, and incident support obligations. The EU Data Act’s cloud switching regime, effective September 2025, complements DORA — customers can initiate a provider switch on two months’ notice, with transitions completing within 30 days and switching charges eliminated from January 2027.
Here’s what you should be doing right now:
- Audit all existing cloud provider contracts against DORA Article 28 requirements
- Classify workloads by criticality and identify which depend on single-provider managed services
- Begin documenting exit strategy architecture at the enterprise level, before a crisis forces your hand
- Ensure your ICT third-party risk register covers all cloud providers with ongoing monitoring
Does NIS2 Require Sovereign Cloud for Essential Services?
NIS2 expanded cybersecurity obligations across two entity categories:
- Essential entities: Large operators in critical sectors — energy, transport, healthcare, digital infrastructure, and finance
- Important entities: Typically midsize organisations or those supporting critical supply chains in the same sectors
NIS2 doesn’t use the words “sovereign cloud.” But its supply chain security obligations create de facto sovereignty requirements for many organisations in scope. Under Article 21, risk assessments may require choosing EU-based providers, particularly where a provider’s exposure to foreign government data access poses supply chain security concerns.
The practical effect: NIS2 makes you accountable for your entire supply chain’s sovereignty posture. The US CLOUD Act exposure of US-headquartered providers becomes an explicit input into that assessment. And because classification thresholds vary by member state transposition, compliance gets more complicated if you’re operating across multiple EU jurisdictions.
For HealthTech companies, NIS2 is compounded by the European Health Data Space (EHDS), Regulation (EU) 2025/327. The EHDS allows EU member states to require that health data be stored and processed exclusively within the EU, unless a GDPR adequacy decision exists for the destination country. HealthTech companies within the EHDS framework face additional constraints on where health data can be hosted, layered on top of NIS2’s baseline obligations.
How Does the EU AI Act Create Cloud Sovereignty Requirements for SaaS Companies?
The EU AI Act (Regulation 2024/1689) reaches full application on August 2, 2026, with penalties reaching 7% of global annual turnover for high-risk AI system violations. It classifies AI systems by risk: prohibited systems (unacceptable risk), high-risk systems in Annex III categories (biometric identification, critical infrastructure, education, employment, access to essential services), limited-risk systems with transparency requirements, and minimal-risk systems.
Here’s the thing: many SaaS products in FinTech (creditworthiness assessment), HR tech (CV screening), and HealthTech (medical-device-adjacent AI) deploy features that may qualify as high-risk under Annex III. If you haven’t checked, now’s the time.
If a system is high-risk, the data governance obligations kick in: complete audit trails for training data provenance, data quality protocols across training, validation, and testing datasets, detailed technical documentation, ongoing risk management, and human oversight mechanisms.
The infrastructure implication is direct. SaaS platforms using shared hyperscaler managed AI services often can’t provide the infrastructure-level provenance required for compliance. Self-hosted or sovereign environments enable the complete data lineage documentation the EU AI Act requires. Most SaaS companies haven’t yet connected their EU AI Act obligations to their cloud infrastructure decisions. That link exists. The August 2026 deadline doesn’t wait.
If you’re in FinTech deploying AI, you’re likely facing both DORA and the EU AI Act simultaneously. HealthTech adds NIS2 and potentially EHDS on top. These regulations stack. Plan accordingly.
What Is the Difference Between BSI C5 and SecNumCloud Certification?
BSI C5 (Cloud Computing Compliance Criteria Catalogue) is the German Federal Office for Information Security certification, with Type I (design attestation) and Type II (operational effectiveness) audit levels. It focuses on operational security practices but doesn’t exclude non-European providers — US hyperscalers can and do hold it. AWS European Sovereign Cloud holds BSI C5. You can verify certifications at https://www.bsi.bund.de.
SecNumCloud is the French ANSSI certification with stricter sovereignty requirements. It requires the cloud provider to be immune to requests from public authorities of third countries, store and process client data exclusively within the EU, and have its registered office within the EU. Those requirements effectively exclude US-headquartered providers in their native form. SecNumCloud is required for French government and critical infrastructure workloads.
The practical difference is straightforward. BSI C5 certifies operational security practices. SecNumCloud certifies both operational security and legal sovereignty. A provider holding SecNumCloud guarantees no foreign government data access. A provider holding BSI C5 does not — US hyperscalers with BSI C5 remain subject to the CLOUD Act.
The EUCS (European Cybersecurity Certification Scheme for Cloud Services) from ENISA was supposed to harmonise these national schemes into a single EU-level framework. Political controversy over whether the highest assurance level should require EU-headquartered providers has blocked its finalisation. As of late 2025, the EUCS had not been adopted.
What Does Each Regulation Mean for Your Cloud Strategy?
If you’re in FinTech, DORA compliance is the immediate priority and audits are already happening. Audit existing cloud contracts for Article 28 provisions — switch notice rights, data portability guarantees, and zero switching charges from January 2027. Classify workloads by DORA criticality and document exit strategy architecture now.
If you’re in HealthTech, you need to determine whether you classify as essential or important entity under NIS2 for your member state’s transposition. Assess whether your current cloud providers satisfy Article 21 supply chain security obligations. Then layer EHDS on top: health data may need to be stored and processed exclusively within the EU. Where NIS2 or EHDS push you toward full legal isolation, EU-native providers that meet these certification requirements are the practical answer.
If you’re in SaaS and deploying AI, assess whether any AI system falls into the high-risk Annex III categories. If it does, your current infrastructure must support complete data lineage documentation, audit trails, and human oversight mechanisms by August 2026.
The Transfer Impact Assessment (TIA) applies across all three scenarios. Under GDPR Chapter V, a TIA is required whenever data is accessible by entities in jurisdictions without adequate data protection. The US CLOUD Act means any US-headquartered cloud provider triggers this requirement — even when data is stored in EU data centres.
For most organisations, a hybrid sovereign model is a practical response: regulated and mission-critical workloads in a sovereign environment, less sensitive internal applications on standard public cloud. See how to integrate these requirements into your workload classification for a systematic approach to sorting it all out.
FAQ
Which EU regulations specifically require sovereign cloud?
No single EU regulation uses the term “sovereign cloud” as a mandate. But DORA’s exit strategy and concentration risk requirements, NIS2’s supply chain security obligations, and the EU AI Act’s data governance framework collectively make sovereign cloud effectively mandatory for regulated workloads in financial services, essential services, and high-risk AI deployments.
Does DORA apply to FinTech startups or only large banks?
DORA applies to all financial entities regardless of size. Scope is determined by function (financial services), not company size. A 50-person FinTech processing payments is in scope alongside major banks.
Can AWS or Azure satisfy DORA sovereign cloud requirements?
US hyperscalers can satisfy many DORA technical requirements. AWS European Sovereign Cloud holds BSI C5 certification. However, US-headquartered companies remain subject to the US CLOUD Act, which allows US authorities to compel data access regardless of server location — a risk that must be assessed in any DORA exit strategy and Transfer Impact Assessment.
What is the difference between data residency and data sovereignty?
Data residency means data is physically stored within a geographic boundary. Data sovereignty means data is subject to the laws and governance of a specific jurisdiction with no foreign government access. A US hyperscaler with EU-based servers provides data residency — but the CLOUD Act can compel disclosure regardless of server location.
What is a DORA exit strategy and what must it include?
Under DORA Article 28, financial entities must maintain documented, testable, regulator-auditable plans to migrate away from any critical ICT provider without service disruption. Requirements include switch notice rights (two months), 30-day transitional periods, data portability provisions, and zero switching charges from January 2027.
Is SecNumCloud required for all EU sovereign cloud deployments?
No. SecNumCloud is required for French government and critical infrastructure workloads. For German regulatory contexts, BSI C5 is the relevant standard. Which certification matters depends on your operational jurisdiction and the specific regulation creating the sovereignty obligation.
How does the EU AI Act affect cloud infrastructure decisions?
The EU AI Act requires operators of high-risk AI systems to implement data governance frameworks with documented data sources, quality controls, and complete audit trails. SaaS platforms running on shared managed AI services typically can’t provide the infrastructure-level provenance required for compliance. August 2026 is the enforcement deadline.
What is the EU Cloud Sovereignty Framework from October 2025?
The EU Cloud Sovereignty Framework was published by the European Commission in October 2025 to define sovereignty objectives for EU institutions procuring cloud services. Key criteria include whether the cloud service is headquartered outside the EU, processes data outside the EU, or is exposed to foreign government influence.
Do I need a Transfer Impact Assessment if I use a US cloud provider in Europe?
Yes. Under GDPR Chapter V, a TIA is required whenever data is accessible by entities in jurisdictions without adequate data protection. The US CLOUD Act means a TIA is required even when data is stored in EU data centres.
What is BSI C5 and where can German companies verify it?
BSI C5 (Cloud Computing Compliance Criteria Catalogue) is the German Federal Office for Information Security certification scheme for cloud services. It has Type I (design attestation) and Type II (operational effectiveness) audit levels. Verify provider certifications at https://www.bsi.bund.de.
What workloads actually require sovereign cloud under these regulations?
DORA covers financial transaction processing, payment systems, and critical ICT functions in financial entities. NIS2 covers workloads in essential services — energy, health, transport, digital infrastructure. The EU AI Act covers training data and inference infrastructure for high-risk AI systems. Non-regulated internal tooling typically falls outside these requirements.
What is the EHDS and how does it affect HealthTech cloud decisions?
The European Health Data Space (EHDS) is Regulation (EU) 2025/327, regulating primary and secondary use of electronic health data. It allows EU member states to require that health data be stored and processed exclusively within the EU. HealthTech companies within the EHDS framework face additional constraints on where health data can be hosted, layered on top of NIS2’s baseline obligations.
For a complete overview of data residency, sovereignty, and jurisdictional control across all these dimensions, see our sovereign cloud explained guide.
