Sovereign cloud is a procurement decision, not a region setting.
What buyers usually ask, and why it is incomplete
The typical procurement question is: is the data in the EU? The vendor confirms an EU region for storage and compute. Procurement ticks the box. The contract goes to legal for a standard Standard Contractual Clauses (SCC) review. Done.
The problem with stopping there is the law. The US CLOUD Act (Clarifying Lawful Overseas Use of Data Act) can compel any US-headquartered cloud provider, including its EU subsidiaries and its 'sovereign cloud' offerings, to produce customer data on a valid US legal demand regardless of where the data physically sits. Microsoft completed its EU Data Boundary in February 2025. AWS launched its European Sovereign Cloud in Brandenburg in January 2026. Both improve residency. Neither removes the provider from US jurisdiction.
The EU is moving in the opposite direction. The EU Cybersecurity Certification Scheme for Cloud Services (EUCS) has been the subject of years of debate; the sovereignty and foreign-law-immunity criteria for the highest assurance tier have been added, removed, and partially revisited. The Cybersecurity Act 2.0 proposal of January 2026 carries that work forward. In parallel, the Dutch government signed its first contract with a German sovereign provider (StackIT) in April 2026, with European-ownership-change clauses written into the agreement. The conversation has shifted from 'where is the data' to 'which law applies'.
The four layers of sovereignty
Sovereignty is not a single property. It is four properties, and a vendor can offer some without offering the others. Asking about one layer and assuming the rest follow is the most common procurement mistake.
Layer one: data residency. The data is stored and processed in the EU. Microsoft, AWS, Google, OpenAI, and Anthropic all offer this. It satisfies the GDPR transfer mechanics. On its own, it satisfies nothing else.
Layer two: key control. The encryption keys are held by the customer, in a customer-controlled hardware security module (HSM), with the provider technically unable to decrypt data at rest or in transit. This is bring-your-own-key with hold-your-own-key (BYOK plus HYOK), combined with confidential computing for the runtime path. It raises the bar for compelled disclosure: the provider can hand over ciphertext, not plaintext.
Layer three: operational sovereignty. The control plane, support staff, and physical access are restricted to EU residents under EU law. AWS European Sovereign Cloud is the headline example among US providers. EU vendors like OVHcloud, Scaleway, IONOS Cloud, StackIT, and T-Systems have offered this from day one. The control-plane personnel cannot be compelled by a US subpoena because they are not in US reach.
Layer four: jurisdictional sovereignty. The legal entity that holds the customer contract is not US-owned and not US-headquartered. This is the only layer that closes the CLOUD Act gap. AWS ESC, despite operating with EU staff, is a 100 percent subsidiary of Amazon.com Inc. Microsoft Cloud for Sovereignty is a Microsoft product. A provider can offer layers one, two, and three with no parent-company change. Layer four requires a non-US entity.
The questions that belong in the request for proposal
For any workload above an ordinary-sensitivity threshold, the buyer should put the following five questions in front of the vendor before signing. They belong in the request for proposal (RFP) and the contract addendum, not in a side conversation.
One: where is the data stored, where is it processed, and where do the support engineers who can access it sit? Three answers, not one. Most contracts answer the first and leave the other two implicit.
Two: who holds the encryption keys, and can the provider technically decrypt customer data without the customer's cooperation? If the answer is 'we manage the keys in our HSM,' the provider can decrypt. Move to BYOK with a customer-controlled HSM if the workload warrants it.
Three: what is the legal entity that holds our contract, and what is the ultimate parent? Read the parent's country of incorporation, not the regional subsidiary's address. The contract paper says the subsidiary; the disclosure obligations follow the parent.
Four: what is the published process when the provider receives a foreign government data request that conflicts with EU law? The honest providers publish it. The dishonest ones answer with 'we have a long history of resisting such requests.' That is a statement, not a process.
Five: under what conditions, and within what timeframe, can we exit the platform and recover our data and operational state? Sovereign cloud without a credible exit clause is sovereign cloud only on paper.
"The contract paper says the subsidiary. The disclosure obligations follow the parent."
Sebastiaan van Parijs / Founder
Three workloads where the answer is different
Marketing analytics, internal knowledge search, and customer support tooling sit comfortably in a US-headquartered provider with an EU region and the right Chapter V mechanism. The risk profile is ordinary personal data. Going further is paying for protection the workload does not need.
Regulated financial services, health records, HR data with works-council scrutiny, and EU defence-adjacent data sit in a different bucket. The risk profile is sensitive personal data and trade secrets, with national-security undertones in the defence case. For these workloads, BYOK with customer-controlled keys is the floor. For the most sensitive subset, a non-US provider is the answer. The cost premium is real and worth paying.
Government workloads and EUCS-High candidates sit in the third bucket. Several member states are writing freedom-from-foreign-compelled-disclosure into their procurement criteria, with the Netherlands' StackIT deal as a recent example. AWS ESC and Microsoft Cloud for Sovereignty do not meet that bar today. The realistic candidates are OVHcloud, IONOS Cloud, Scaleway, T-Systems' Open Sovereign Cloud, StackIT, and a handful of national providers. The trade-off is reduced feature breadth versus full jurisdictional control.
If you would like to test this against your environment
We help mid-market and enterprise EU teams take the sovereignty conversation from a slide to a procurement-ready position. Two outputs. A one-page mapping of every workload to one of three sovereignty tiers, with the residency, key control, operator, and jurisdiction columns filled in. A revised vendor question set ready for the next procurement round, plus a draft contract addendum your legal team can take to existing agreements.
The conversation is usually shorter than buyers expect. Most of the work is honest classification. Once the tiers are written down, the architecture choices follow without argument.
If you are looking at a sovereignty question and the answers are not lining up, write us. One call, one written summary, no slide deck.
