The four questions a cloud region cannot answer

What is cloud compliance, and why has it got harder?

Cloud compliance is the ability to evidence that data held in a cloud service satisfies every rule that applies to it: where it physically sits, whose courts can compel its disclosure, who holds the encryption keys, and what the provider is permitted to do with it. For most of the past decade those four questions collapsed into one decision, which was picking a region. They have now come apart. A regional endpoint answers the first and leaves the other three open.

The separation has become a budget line rather than a debate. Gartner expects sovereign cloud spending to shift roughly 20% of current workloads from global cloud providers to local ones.¹ That money is not buying new capability. It is relocating systems that already worked, because the legal position underneath them changed.

It also helps to separate two things that get filed together. SOC 2 and ISO 27001 are assurance frameworks: they attest that you run controls competently, and an auditor signs the result. GDPR, HIPAA and national data protection statutes are law: they attach obligations to the data itself, and no certificate discharges them. A provider can hand you a wall of attestations and still leave you exposed on jurisdiction, because jurisdiction was never in scope for the audit.

What is the difference between data residency and data sovereignty?

Data residency is the physical or geographic location where data is stored, usually chosen to satisfy a named law or contract clause. Data sovereignty is the principle that data is subject to the laws of the country where it is collected or stored, independent of where the operating company is headquartered. Residency is a storage fact. Sovereignty is a legal reach question, and the two do not move together.

This is where most programmes stop one step short. A team pins a workload to a European region, marks the residency requirement closed, and does not ask the second question: the entity operating that region is often a subsidiary of a foreign parent, and extraterritorial disclosure law can follow the parent regardless of where the disks are. The data never leaves the country. The obligation to hand it over does not depend on the data leaving the country.

That contradiction is the honest state of the market. Buyers want local control and global engineering at the same time, and the sovereign cloud category exists to sell them both. Whether any given offer delivers both is a question you have to ask per vendor, not per region.

Where is sovereign cloud money actually going?

The spending pattern tells you which way procurement expectations are moving. China is forecast as the largest sovereign cloud infrastructure market in 2026 at $47 billion, with North America second at $16 billion.² Europe is forecast to spend over $12 billion in 2026, up from roughly $7 billion in 2025.³

Read the North American number carefully. Sovereignty is routinely framed as a European preoccupation, and a $16 billion domestic market says otherwise.² Public sector buyers, regulated industries and multinationals are all asking who can compel disclosure, and they are asking it in jurisdictions that have no GDPR equivalent. If your product sells into government, health, defence or financial services anywhere, expect the question in the security review whether or not the buyer is European.

Can your cloud provider train AI on your data?

Sometimes yes, by default, and the setting is rarely where you would look for it. Cloud AI services differ widely on whether customer inputs, outputs and logs feed model improvement, and the answer can vary between two products from the same vendor, between a free tier and an enterprise tier, and between the model API and the assistant built on top of it. Assuming a single vendor-wide policy is the common failure.

Three things need to be true before an engineering team can claim this is handled. First, an explicit opt-out that is set and verifiable in configuration, not merely available. Second, a contractual commitment, not a privacy policy statement. Third, a clear retention window for prompts, completions and abuse-monitoring logs, because retained inference data is still personal data and still sits somewhere.

A privacy policy can be rewritten on a Tuesday. A contract cannot, not without your signature on the amendment.

The same discipline applies to sub-processors. Model providers reached through a cloud marketplace can introduce a legal entity you never assessed, in a jurisdiction you never approved, sitting between your users and the answer. Teams building AI features into existing products should treat the model vendor list as part of the data map, not as a procurement footnote. Our engineering practice treats that map as a build artefact, versioned with the code rather than kept in a spreadsheet that ages out.

Where does cloud compliance leak in practice?

Not usually at the primary database. The controls there are visible, reviewed and easy to evidence. The leaks are in the copies.

Backups and disaster recovery replicas

This is the most common residency failure we see. The production workload is correctly pinned to an approved region while its backup schedule or DR replica writes cross-border, often because a default replication target was accepted during setup and never revisited. The primary passes the audit. The copy is the breach.

Key custody

Encryption at rest is table stakes and it is not a sovereignty control on its own. If the provider holds the keys, the provider can be compelled to produce readable data. Customer-managed keys held outside the provider’s control change what a disclosure order can actually retrieve. Expect key custody, not the presence of encryption, to be the question regulators press on.

Telemetry, logs and support access

Application logs, crash reporting, analytics SDKs and vendor support tooling move data across borders continuously and almost never appear on a data map. Mobile products are the worst offenders because the SDK layer is thick and mostly third-party; anyone shipping a mobile application into a regulated market should enumerate every SDK that transmits off-device and record where each one terminates. Support access matters too: a follow-the-sun support model can mean an engineer in a third country reading a customer record at 03:00, which is a transfer even though nothing was copied.

How do you choose a region and a sovereignty tier?

Sovereign cloud is a spectrum, not a badge. The label covers offers that differ enormously in what they actually constrain, and the only way to compare them is to ask what a foreign disclosure order would return.

Availability is the practical constraint on that choice, and it is improving fastest outside the established markets. Middle East and Africa (89%), mature Asia Pacific (87%) and Europe (83%) are forecast to post the highest sovereign cloud growth rates in 2026.⁴ Options that did not exist at your last architecture review may exist at the next one.

Two rules make the decision tractable. Classify data before choosing infrastructure, because most systems hold a small regulated core inside a large unregulated body, and paying sovereign-tier costs for the whole estate is how these programmes lose their budget. Then split the estate: run the regulated core where the legal answer is clean and keep everything else on the global platform where the engineering is better.

What should an engineering team do this quarter?

The work below is deliberately unglamorous, and it is what separates a defensible position from a slide that says compliant.

1. Map the copies, not the systems. For every regulated data store, list the backups, replicas, caches, log sinks, analytics destinations and AI service endpoints, and record the country each one terminates in. Most teams find at least one crossing they did not know about.
2. Read the AI terms per service, not per vendor. Record for each service whether training on customer data is on by default, whether the opt-out is contractual, and how long inference logs persist.
3. Move keys before you move workloads. Customer-managed key custody delivers more sovereignty benefit per week of effort than a region migration, and it does not require re-architecting the application.
4. Put the checks in the pipeline. Residency assertions belong in infrastructure tests that fail a deploy, not in a quarterly review. This is a normal part of a governed software development life cycle, and it is far cheaper than a retrospective audit.
5. Name an owner per jurisdiction. Cloud data regulations change on national timetables. Someone has to be accountable for noticing.

None of this requires a sovereign cloud contract on day one. It requires knowing which of the four questions you have actually answered. If you are working out where your own architecture stands, our team is happy to walk through the map with you.

Written by the group's editorial team with the practice leads who run these builds. Reviewed before publish. Spotted an error? Tell us and we will fix it.