The EU data sovereignty debate has spent five years stuck in a binary: US cloud bad, EU cloud good. That framing was always too simple, and in 2026 it is actively misleading. The organisations making the most defensible architecture decisions have moved past it. They are asking sharper questions — not "where is my data?" but "who can compel access to my data, and what technical controls prevent that access even under legal compulsion?"
The answer is rarely straightforward. The EU-US Data Privacy Framework, adopted in July 2023, provides a legal basis for transatlantic data transfers but faces ongoing legal challenges that could produce another Schrems-style invalidation. US hyperscalers now operate EU sovereign cloud variants with varying degrees of genuine operational separation. And EU-native infrastructure providers offer alternatives that eliminate extraterritorial legal risk but sometimes lack the service breadth and operational maturity of hyperscaler platforms.
What has not changed is the underlying regulatory reality: GDPR Articles 44-49 restrict international data transfers, NIS2 emphasises the security of network and information systems in a way that implicates infrastructure sovereignty, and DORA Article 28(7) explicitly addresses data location requirements for financial entities. Organisations must navigate these requirements while building systems that actually work at scale, serve customers across jurisdictions, and do not cost three times what a straightforward hyperscaler deployment would.
This post takes a practical architecture position. Sovereignty is a spectrum, not a binary. The right position on that spectrum depends on your regulatory obligations, your data classification, and your threat model. Most organisations need a nuanced approach — not ideological purity.
The Sovereignty Landscape in 2026
Three years after the EU-US Data Privacy Framework's adoption, the legal ground remains unstable. The framework survived its first legal challenge before the CJEU — a preliminary reference that the Court addressed without invalidating the adequacy decision — but privacy advocates continue to contest the adequacy of US surveillance safeguards. The fundamental tension remains: Executive Order 14086, which underpins the DPF, is an executive order, not a statute. A future administration could revoke or modify it without congressional approval. The CJEU's adequacy assessment rests partly on that executive order's durability.
For organisations conducting data protection impact assessments, the DPF provides a current legal basis for transfers but not a guarantee of long-term stability. Architectures designed today should be viable if the DPF survives and if it does not.
Meanwhile, the political context has shifted. The EU's strategic autonomy agenda has intensified, particularly in digital infrastructure. The European Commission's cloud sovereignty initiatives, Gaia-X's evolution from a federated cloud concept to a more focused set of compliance standards, and national cloud sovereignty requirements in France (SecNumCloud), Germany (C5), and the Netherlands (government cloud policy) all reflect a regulatory environment that increasingly values — and in some cases mandates — European infrastructure for certain categories of data and workloads.
This does not mean every organisation must abandon hyperscalers. It means the risk calculus has additional variables that did not exist five years ago, and architecture decisions must account for regulatory trajectory, not just current requirements.
Data Location vs Operational Sovereignty
The distinction between data location and operational sovereignty is the most important concept in the sovereignty discussion, and the one most frequently conflated.
Data location answers the question: in which country or region is the data physically stored? All major hyperscalers offer EU region deployments. Your data can reside in Frankfurt, Paris, Dublin, or Amsterdam. This satisfies the most basic interpretation of data residency requirements and eliminates concerns about data transiting through non-EU jurisdictions during storage.
Operational sovereignty answers a harder set of questions. Who administers the infrastructure? Under which legal jurisdiction are the administrators based, and which governments can compel them? Who holds the encryption keys, and can the infrastructure operator access plaintext data without the customer's cooperation? Who can deploy software updates to the infrastructure, and could those updates alter data access controls? Who manages the identity and access management layer, and can access be granted to data without the customer's knowledge?
A workload running in AWS eu-west-1 is located in the EU. But AWS, as a US-incorporated company, is subject to the CLOUD Act, which allows US law enforcement to compel disclosure of data held by US companies regardless of where that data is stored. AWS is also subject to FISA Section 702, which allows intelligence agencies to compel access to communications data for foreign intelligence purposes. The data is in Ireland. The legal compulsion originates in Virginia.
The practical significance depends on the data type, the applicable regulatory requirements, and the threat model. For many commercial workloads, the risk of a CLOUD Act demand is statistically low and the DPF provides a legal framework for the transfer that such access would constitute. For workloads involving sensitive personal data, critical infrastructure data, or government data, the risk calculus is different. Several EU member states now explicitly restrict the use of US-controlled infrastructure for certain government workloads — not because the risk is imminent but because the legal exposure is incompatible with the assurance level required.
The Encryption Key Question
Encryption is the technical control that transforms data sovereignty from a legal argument into an engineering one. But not all encryption architectures are equal.
Provider-managed keys. The default configuration for most cloud services. The cloud provider generates, stores, and manages encryption keys. Data is encrypted at rest and in transit, but the provider can decrypt it — and can be compelled to do so under applicable laws. This satisfies baseline encryption requirements but provides no sovereignty benefit. It is security theatre from a sovereignty perspective.
Customer-managed keys (BYOK/CMEK). The customer generates encryption keys and provides them to the cloud provider's key management service. The customer controls key lifecycle — creation, rotation, revocation. But the keys are still accessible to the provider's infrastructure. In most BYOK implementations, the cloud provider's key management service holds a copy of the key in memory during cryptographic operations. This is operationally convenient but means the provider can technically access plaintext data during processing.
External key management (HYOK/EKM). The customer holds keys in an external hardware security module (HSM) or key management service that the cloud provider cannot access. Cryptographic operations occur either in the external HSM or in a secure enclave controlled by the customer. The cloud provider never holds the key in plaintext. This provides genuine operational sovereignty — even under legal compulsion, the provider cannot decrypt data without the customer's HSM.
The tradeoff is functionality. External key management limits which cloud services can be used (many managed services require provider-managed keys to function), increases latency for cryptographic operations, and adds operational complexity. It is the correct architecture for genuinely sovereign workloads. It is unnecessary overhead for most commercial applications.
The HSM sovereignty dimension. Even external key management has a sovereignty consideration: where is the HSM located, and who manufactures and maintains it? A customer-managed HSM running on a cloud provider's CloudHSM service is still, ultimately, a virtual HSM running on the provider's infrastructure. A dedicated, customer-owned physical HSM in a customer-controlled facility provides the highest sovereignty assurance — and the highest operational complexity.
Architecture Patterns for Practical Sovereignty
Sovereignty architecture is not one-size-fits-all. We see three tiers in practice, each appropriate for different regulatory and risk profiles.
Tier 1: Full EU-Native
All infrastructure runs on EU-headquartered, EU-operated providers with no US legal nexus. Data, keys, administration, and code deployment are entirely within EU jurisdiction.
Providers: Scaleway (France), OVHcloud (France), Hetzner (Germany), IONOS (Germany), UpCloud (Finland), Exoscale (Switzerland/EU presence).
When appropriate: Government workloads with explicit sovereign cloud requirements. Critical infrastructure operators with national security implications. Organisations in member states with mandatory EU infrastructure rules for regulated sectors. Companies that have made strategic commitments to eliminate all extraterritorial legal exposure.
Tradeoffs: Narrower service catalogue compared to hyperscalers. Fewer managed services, which means more operational responsibility. Smaller partner ecosystems and less community tooling. Some services that hyperscalers offer as one-click configurations require custom engineering on EU-native providers.
Practical reality: Full EU-native is viable and increasingly mature, but it requires organisations to accept greater operational responsibility. You will write more infrastructure code, manage more components yourself, and operate with smaller support teams from your provider. For organisations with strong platform engineering capabilities, this is entirely manageable. For those accustomed to fully managed hyperscaler services, the transition is significant.
Tier 2: EU-Controlled on Hyperscaler
Workloads run on a hyperscaler's EU regions with additional sovereignty controls: customer-managed or external encryption keys, EU-based administration, contractual restrictions on data access, and potentially a sovereign cloud variant (such as Google Sovereign Cloud with T-Systems, or AWS European Sovereign Cloud).
When appropriate: Organisations that need hyperscaler service breadth but face regulatory pressure to demonstrate operational sovereignty. Financial entities subject to DORA Article 28(7) data location requirements. Organisations whose compliance teams need the assurance of sovereignty controls without the operational shift to EU-native providers.
Tradeoffs: Cost premium for sovereign cloud variants (typically 20-40% above standard pricing). Reduced service catalogue — sovereign cloud variants often launch with a subset of the provider's full service offering. Contractual sovereignty provisions may be untested under actual legal compulsion. The fundamental legal nexus (US parent company) remains.
Practical reality: This tier is where most large enterprises land in 2026. The sovereign cloud variants are maturing rapidly, and the combination of hyperscaler operational maturity with EU-controlled access provides a defensible position for most regulatory contexts. The key is reading the contracts carefully — "sovereign" is a marketing term until the contractual provisions are specific about data access, key management, and administrative jurisdiction.
Tier 3: Hybrid With Sovereign Controls
Most workloads run on standard hyperscaler infrastructure with EU region selection. Specific workloads — those involving regulated data, sensitive personal data, or critical security functions — are isolated on EU-native or sovereign-tier infrastructure. Data classification drives placement.
When appropriate: Most commercial organisations. Companies with mixed data sensitivity profiles. Organisations balancing sovereignty requirements against cost and operational efficiency. Businesses where 80% of workloads have no sovereignty concern and 20% have a genuine one.
Tradeoffs: Architectural complexity from operating across multiple infrastructure tiers. Data flow controls must enforce classification-based routing. More complex disaster recovery and business continuity planning.
Practical reality: This is the pragmatic choice for most organisations. It applies sovereign controls where they matter and avoids the cost and complexity of full sovereignty for workloads that do not require it. The architectural challenge is real — you need clean data classification, enforced routing policies, and clear operational procedures — but it is an engineering problem with known solutions, not an unsolvable constraint.
Regulatory Requirements That Drive Sovereignty Decisions
Sovereignty architecture decisions should be grounded in specific regulatory requirements, not abstract sovereignty ideology.
GDPR Articles 44-49 restrict international transfers of personal data. The DPF provides a current legal basis for US transfers, but standard contractual clauses remain the fallback mechanism. Any architecture should be designed to function under SCCs if the DPF fails — meaning supplementary measures (encryption, pseudonymisation, access controls) that ensure transferred data is protected against government access that exceeds GDPR standards.
NIS2 does not contain explicit data location requirements, but its emphasis on the security of network and information systems — and the designation of essential and important entities whose disruption could affect national security — creates implicit sovereignty pressure. If an essential entity's critical infrastructure runs on a provider that can be compelled by a foreign government to alter system behaviour, the security of those systems is not entirely under the entity's control. NIS2 supervisory authorities are beginning to explore this dimension.
DORA Article 28(7) is more explicit: financial entities must take into account the data protection and the location of data and data processing. The Regulatory Technical Standards further specify that contractual arrangements must address where data is processed and stored, and that financial entities must have the ability to maintain data within the EU if required. For financial entities, this creates a tangible architecture requirement.
National-level requirements vary significantly. France's SecNumCloud certification requires hosting on infrastructure operated by entities with majority EU ownership and no extraterritorial legal exposure — effectively excluding US hyperscalers from qualified cloud hosting for certain government and critical workloads. Germany's C5 attestation is less restrictive but provides a tiered assurance framework. Other member states are developing or adopting similar schemes.
The Self-Hosted Option
For a specific category of organisation — those with platform engineering capability, stringent sovereignty requirements, and the operational maturity to manage infrastructure — self-hosting on EU infrastructure is a viable and increasingly common choice.
Self-hosting does not mean running bare metal servers in a basement. It means deploying software on EU-operated infrastructure (dedicated servers or virtual machines from EU providers) under your own operational control. You manage the operating system, the application runtime, the database, the networking, and the security. The infrastructure provider provides compute, storage, and network connectivity.
The advantages are clear: full operational sovereignty with no extraterritorial legal exposure, complete control over encryption keys and access, no vendor lock-in at the application layer, and frequently lower cost at scale compared to equivalent managed services. The disadvantages are equally clear: you are responsible for everything the managed service provider would otherwise handle — patching, scaling, monitoring, backup, disaster recovery, security hardening.
Self-hosting is appropriate when sovereignty is a hard requirement (not just a preference), when managed service alternatives do not exist at the required sovereignty tier, and when the organisation has the engineering team to maintain the infrastructure reliably. It is not appropriate when the organisation lacks platform engineering depth, when the managed service overhead is not justified by the sovereignty benefit, or when the primary motivation is cost reduction rather than sovereignty.
FortisEU's Approach: Self-Hosted Supabase on Scaleway FR
We should be transparent about our own architecture, because we sell sovereignty to customers and should demonstrate it ourselves.
FortisEU runs on self-hosted Supabase deployed on Scaleway infrastructure in France. This is a Tier 1 full EU-native architecture. Supabase — the open-source PostgreSQL platform — runs on our own instances, not on Supabase's managed cloud service. The database, authentication service, storage, and API gateway are all under our operational control.
We chose this architecture for specific reasons. Our customers — EU-regulated enterprises — need to trust that their compliance data, risk assessments, and regulatory evidence are not accessible to non-EU government agencies. Running on a US-headquartered managed service, even with EU region selection, would create a trust gap that our customers' procurement teams would — rightly — question. You can see the full details on our trust page and company page.
The tradeoffs are real. We manage our own PostgreSQL instances, handle our own backup and disaster recovery, operate our own monitoring stack, and maintain our own security hardening. This requires platform engineering capability that a managed service would eliminate. The cost is not lower — the operational overhead roughly equals what we would save on managed service fees. The value is in sovereignty, not in cost.
We use Scaleway because it is a French company with French data centres, no US legal nexus, and a strong track record in the European cloud market. Our encryption keys never leave infrastructure we control. Our database administrators are EU-based. Our deployment pipeline runs on EU-hosted CI/CD infrastructure. No component of our stack is subject to CLOUD Act, FISA 702, or any other extraterritorial compulsion mechanism.
This is not the right architecture for every company. Most commercial SaaS companies do not need Tier 1 sovereignty. But for a compliance platform that holds regulated enterprises' most sensitive security and risk data, it is the appropriate choice. Our compliance automation platform handles customer data that, by definition, reveals security gaps and risk exposures. Ensuring that data is beyond extraterritorial reach is not a marketing decision — it is a trust obligation.
Key Takeaways
Sovereignty is a spectrum, not a binary. Three architecture tiers — full EU-native, EU-controlled on hyperscaler, and hybrid with sovereign controls — serve different regulatory and risk profiles. Most organisations belong in Tier 2 or Tier 3, not Tier 1.
Operational sovereignty matters more than data location. Data stored in an EU region of a US cloud provider is EU-located but not necessarily EU-sovereign. Who holds the encryption keys, who administers the infrastructure, and who can be legally compelled to provide access are the questions that determine actual sovereignty.
The DPF is a current legal basis, not a permanent one. Architectures designed today should function if the EU-US Data Privacy Framework survives and if it does not. Relying solely on the DPF for transfer legitimacy is a compliance risk.
Encryption architecture determines sovereignty floor. Provider-managed keys offer no sovereignty benefit. Customer-managed keys improve the position. External key management with customer-controlled HSMs provides genuine operational sovereignty. Each level adds cost and reduces service flexibility.
Regulatory drivers are specific and identifiable. GDPR Articles 44-49, DORA Article 28(7), national sovereign cloud requirements (SecNumCloud, C5), and NIS2's implicit infrastructure security expectations create concrete architecture requirements. Design to the specific requirements, not to abstract sovereignty principles.
Self-hosting is viable for organisations with the capability. Running open-source infrastructure on EU providers eliminates extraterritorial legal exposure entirely. The tradeoff is operational responsibility. It is the right choice for organisations where sovereignty is a hard requirement and engineering capability exists to maintain infrastructure reliably.