Data Residency and Sovereignty: Choosing Where Data Lives

Residency, Localisation, Sovereignty: Not Synonyms

These three words get used interchangeably in procurement conversations and they mean quite different things. Separating them early prevents a lot of wasted architecture.

Data residency is simply where the bytes are stored. It is a technical property, it is the easiest of the three to satisfy, and picking a region usually settles it.

Data localisation is a legal requirement that certain data must remain within a country's borders, sometimes with the further condition that no copy may leave. Several jurisdictions impose this for health records, financial data or government workloads.

Data sovereignty is the broader question of which state's laws and courts can compel access to the data. This is the one that cannot be solved by choosing a region, because it depends on where the operating company is incorporated and who holds the keys.

The distinction matters because a requirement phrased as one may really be the other. When a customer asks for data to stay in a country, find out whether they need storage location, legal jurisdiction, or a contractual commitment about who may view it. The answers lead to different providers.

The Data That Leaves Without Being Noticed

Choosing a region pins your primary storage. A surprising amount of everything else quietly goes elsewhere, and this is where reviews find problems.

Two of these deserve special attention. CDN caching is genuine data movement, and if the requirement forbids copies leaving, the CDN configuration has to restrict which content it caches and where. The CDN basics article covers the cache controls that make that possible.

Support access is the one teams forget entirely. A provider's support engineer troubleshooting your ticket may be in a different country from your data, and whether that constitutes a transfer is exactly the kind of question a compliance reviewer will ask. Providers document their arrangements, and some sell restricted-access options specifically to answer it.

The Shape of the Legal Landscape

This is not legal advice and the details differ by jurisdiction and change over time. What follows is the shape of the problem so you can ask your counsel the right questions.

In the European Union, personal data may move outside the bloc only under specific mechanisms, and the adequacy of those mechanisms has been litigated repeatedly. The practical consequence for engineering teams is that transfers must be documented and defensible rather than incidental.

Several countries impose sector-specific localisation, most commonly for health, financial and public sector data. These are usually stated as obligations on the data controller, which means they land on you rather than on your provider.

Extraterritorial access laws create the sovereignty question. Legislation in some jurisdictions can compel a company under its authority to produce data it controls, including data held abroad. This is why a region located in one country, operated by a company incorporated in another, may not satisfy a sovereignty requirement even though residency is perfectly satisfied.

The compliance frameworks that customers actually audit against are a separate layer again, and the cloud compliance basics article covers how SOC 2, ISO 27001 and the rest relate to all of this.

What Providers Offer to Address It

There are four broad mechanisms on the market, in ascending order of strength and cost.

Region selection. Every provider lets you choose where resources live, and most document the geography explicitly, as Google does in its geography and regions documentation and Microsoft does in its Azure regions overview. This settles residency and nothing more.

Policy enforcement. Organisation-level controls that prevent resources being created outside approved regions. This is the difference between intending to comply and being unable to breach it by accident, and it is the highest-value single control on this list.

Customer-managed and external keys. If you hold the encryption keys, and particularly if you hold them outside the provider, then data the provider holds is ciphertext it cannot unilaterally read. This addresses part of the sovereignty question technically rather than contractually, and the layers are explained in encryption at rest and in transit.

Sovereign and locally operated clouds. Offerings run by a locally incorporated entity, with staffing and operational control inside the jurisdiction. European providers such as OVHcloud and Scaleway are structured in the EU by default, and the hyperscalers have introduced sovereign variants of their platforms in partnership with local operators.

For teams whose requirement is simply that everything stays European under European corporate control, an OVHcloud account or a Scaleway account answers it structurally rather than by configuration. The OVHcloud and Scaleway comparison covers how the two French platforms differ in everything else.

Designing So It Stays True

A residency claim made once at launch decays. Building it into the system is what keeps it accurate two years later.

• Enforce region constraints in policy, not in documentation. Deny resource creation outside the approved list at the organisation level.
• Tag data by classification so that restricted data can be identified programmatically rather than by memory.
• Pin every dependency's region, including logging, error tracking, mail and AI endpoints. Default endpoints are rarely in your region.
• Constrain backups explicitly. Cross-region replication is often on by default because it is good for durability and bad for localisation.
• Keep a data flow map listing every place data comes to rest and every third party that receives it. Auditors ask for this and it is far easier to maintain than to reconstruct.
• Review after every new integration. Most residency breaches arrive as a helpful new tool rather than as an architectural decision.

Where a workload must serve several jurisdictions, the usual pattern is a regional deployment per jurisdiction with a shared codebase and entirely separate data stores. That is more operational work than a single global deployment, and it is far less work than retrofitting separation later. Picking the regions themselves is covered in cloud regions and availability zones.

Questions Procurement Usually Asks