The conversation in European boardrooms changed in late 2025. Between the EU Data Act becoming fully applicable in September, the European Commission publishing its Cloud Sovereignty Framework in October, and a fresh round of US executive orders rattling cross-border data flows, the question of who really controls your infrastructure stopped being theoretical. If you are a CTO at a UK or EU enterprise running on AWS, Azure, or Google Cloud, you have probably already had the meeting where your board, your legal team, or one of your larger clients asked some version of the same question: are we actually European, or do we just have European-shaped data centres?
The honest answer for most organisations is the second one. This guide explains why that distinction matters, what genuine sovereignty looks like, who the credible EU-native providers are in 2026, and how to plan a migration that does not turn into a two-year archaeology project.
Why “EU region” is not enough
The simplest way to understand the problem is through the US CLOUD Act. Passed in 2018, it compels any company incorporated in the United States to disclose data on request from US authorities, regardless of where in the world that data is physically stored. AWS Frankfurt, Azure Dublin, Google Cloud Belgium — all of them sit inside this jurisdictional envelope because their parent companies are American. A US court order can be served in Seattle and reach into a data centre in Hesse, and the operator is legally obliged to comply. There is no European data residency configuration that fixes this. It is a question of corporate nationality, not geography.
The 2020 Schrems II ruling from the European Court of Justice made this concrete in EU law. The court invalidated the EU-US Privacy Shield on the grounds that US surveillance law is fundamentally incompatible with the protections GDPR guarantees European citizens. Successor frameworks have not closed the gap so much as papered over it, and a series of European data protection authorities have since issued opinions casting doubt on whether US-controlled cloud services can lawfully process certain categories of personal data at all.
Two more recent developments have hardened this position. The EU Data Act became fully applicable in September 2025, granting customers a statutory right to data portability and obliging cloud providers to actively facilitate switching. And in October 2025, the European Commission published its Cloud Sovereignty Framework — a structured scoring system that defines eight sovereignty objectives across five SEAL levels (0 to 4), now being used as the procurement benchmark for the Commission’s own €180M cloud tender. Sovereignty has moved from a values question to a measurable, contractual one.
The test is straightforward. Is your cloud provider’s parent company incorporated in the European Union? If not, the CLOUD Act applies, and no amount of regional configuration changes that. For a deeper walkthrough of why an EU region inside a US hyperscaler does not resolve GDPR exposure, see The CLOUD Act Problem: Why Your AWS EU Region Is Not GDPR-Safe.
What genuine EU sovereignty looks like
Sovereignty is not a single attribute. It is a stack of conditions that need to be true simultaneously, and the Cloud Sovereignty Framework is useful precisely because it forces you to look at all of them at once. In practice, four dimensions matter.
The first is legal. The provider’s parent company must be incorporated in the EU, the contract must be governed exclusively by EU law, and there must be no chain of ownership or control that exposes the provider to foreign jurisdiction. A French subsidiary of a US holding company is not legally sovereign, however French it feels.
The second is operational. Sovereignty fails the moment a non-EU support engineer can SSH into the infrastructure that hosts your data. The serious EU-native providers have moved to EU-staff-only operations for exactly this reason, and the strictest of them — those certified under Germany’s BSI C5 standard — can demonstrate it with audited evidence rather than promises.
The third is data. All data, all metadata, all backups, all logs, and all telemetry must remain physically within EU borders. This sounds obvious until you start tracing where your provider’s monitoring stack actually sends events, or where your IAM directory replicates to. Metadata leakage is the most common failure mode in otherwise-compliant architectures.
The fourth is technical. Sovereignty is meaningless if you cannot leave. That means open standards, no proprietary lock-in to APIs that exist only in one provider’s ecosystem, and an architecture you can audit. The EU Data Act now reinforces this with statutory portability rights, but the engineering work to make portability real is still yours to do.
The Cloud Sovereignty Framework’s eight objectives map closely onto these four dimensions, scored from SEAL 0 (no sovereignty guarantees) through SEAL 4 (full legal, operational, and technical isolation from non-EU influence). Most workloads do not need SEAL 4. Knowing what level you actually need is the first decision in any serious migration.
The top 5 EU-native cloud providers in 2026
The European cloud market in 2026 is more credible than it was even two years ago, and a CTO no longer has to choose between sovereignty and capability. Five providers are worth knowing by name. For a workload-by-workload breakdown of the four leading providers and specific recommendations by industry and compliance requirement, see OVHcloud vs STACKIT vs T Cloud Public vs Scaleway: Which EU Sovereign Cloud Fits Your Workload?.
OVHcloud, headquartered in France, is the largest EU-native cloud provider in the world. It runs more than 40 data centres across Europe, offers a full range of IaaS, PaaS, and bare metal services, holds GDPR and ISO 27001 certifications, and is a founding member of Gaia-X. It is the default starting point for a CTO who wants breadth and maturity in a single European vendor. One caveat worth knowing: a 2024 court case involving OVHcloud’s Canadian entity raised questions about cross-jurisdictional reach for the most sensitive workloads, so for SEAL 4 use cases the right configuration matters.
T-Systems, the enterprise arm of Deutsche Telekom, operates T Cloud Public out of Germany and is the provider you choose when regulatory exposure is the dominant constraint. It holds BSI C5 certification — the strictest cloud security standard in Europe and a mandatory requirement for German federal procurement — runs EU-staff-only operations, and is rated a leader in European cloud by both Forrester and ISG. Financial services, healthcare, automotive, and public sector workloads land here for good reason.
STACKIT, backed by the Schwarz Group (the parent of Lidl and Kaufland and Europe’s largest retailer), has been the fastest-growing EU-native cloud provider through 2025 and into 2026. It is BSI C5 certified, offers strong managed services for Kubernetes, databases, and AI model serving, and has built native integrations with ServiceNow and Salesforce that close the enterprise readiness gap many EU providers historically had. For a CTO who wants German jurisdictional protection without the conservatism of legacy telco vendors, STACKIT is the most interesting option in the market.
IONOS Cloud, part of United Internet AG, is the pragmatic choice. It is ISO 27001 certified, has a multi-region EU footprint covering Germany, France, Spain, and the UK, offers solid Kubernetes and IaaS services, and is competitive on price. Financial services teams that need strict EU residency without the premium pricing of the BSI C5 providers tend to find IONOS the easiest landing zone.
Scaleway, owned by the Iliad Group, is the strongest EU option for GPU and AI inference workloads in 2026. The most recent Callista benchmark (February 2026) put its compute value per euro at 4.8x that of AWS, and its developer experience is the best of any EU-native provider — important when you are asking engineers to migrate away from the AWS console. One operational caveat: parts of Scaleway’s own management plane still rely on US-based services, which matters for the strictest sovereignty postures but is irrelevant for most workloads.
Two market signals are worth keeping in mind alongside these providers. The Callista benchmark also showed Hetzner delivering roughly 14.3x the value per compute unit of AWS, which keeps cost pressure on the hyperscalers and reframes the “EU is more expensive” assumption many boards still hold. And in March 2026, OVHcloud’s CEO publicly forecast RAM prices rising 250–300% by year end, driven by AI demand. Capacity planning conversations now have a procurement-timing dimension that did not exist twelve months ago.
What workloads to migrate first
Migration is a portfolio exercise, not a binary one. The right question is not “should we move off AWS?” but “which workloads should move first, which can wait, and which probably should not move at all?”
Three categories should move first:
Some workloads can stay on hyperscalers for now without doing much harm. Non-sensitive development and test environments, ephemeral CI infrastructure, and CDN or edge workloads where the hyperscaler ecosystem still offers a real depth advantage can reasonably be left alone during a first-wave migration. The goal is to reduce risk and contractual exposure, not to perform sovereignty as ideology.
Migration timeline and what to expect
A meaningful sovereign cloud migration takes between six and eighteen months for a mid-sized enterprise. Less than six months is almost always a sign that you have descoped the hard parts. More than eighteen months is usually a sign that you have not committed to a target architecture and are migrating in a fog. Three phases work in practice.
The first phase, roughly months one and two, is audit and selection. You inventory your current workloads, classify them by data sensitivity and contractual exposure, map their dependencies (this is almost always more painful than expected), and select one or two EU-native providers based on the workload mix. Provider selection at this stage is about fit, not loyalty — most mature migrations end up using two providers, often a BSI C5 vendor for regulated workloads and a developer-friendly vendor like Scaleway or STACKIT for the rest.
The second phase, months three through nine, is the working migration. You move non-critical workloads first. The point is partly to reduce risk and partly to build the internal muscle: your team needs to develop fluency in the new provider’s networking model, IAM, observability stack, and operational quirks before you trust it with anything that matters. By the end of this phase you should have running production workloads on EU infrastructure and a clear-eyed view of where the friction lives.
The third phase, months ten through eighteen, is the harder half. Regulated and critical workloads move, hyperscaler dependencies are systematically decommissioned, and you reach the target architecture. A multi-cloud transitional posture — sensitive workloads on EU providers, non-sensitive workloads still on hyperscalers — is entirely legitimate during this phase, and several analysts now recommend it explicitly for 2026 migrations. The mistake to avoid is treating multi-cloud as the destination rather than the bridge. Long-term, dual operational overhead is expensive and erodes the sovereignty benefit you set out to achieve.
The questions to ask any EU cloud provider
Before signing anything, run the provider through this checklist. The answers you get — and the speed at which you get them — will tell you more than any marketing deck.
A serious provider will answer these in writing without hesitation. A provider that hedges, redirects to a sales engineer, or asks why you are asking is telling you something important.
How Looming Tech can help
Looming Tech helps UK and EU enterprises plan and execute sovereign cloud migrations end to end — workload assessment, provider selection, migration delivery, and post-migration compliance support. Our sovereign cloud practice spans OVHcloud, STACKIT, Scaleway, and T Cloud Public, and we work alongside your existing engineering team rather than around it. If you are evaluating your options, or your clients have started asking the questions in this guide, we are happy to have a no-commitment conversation about where you are and what a credible path forward looks like.