Data residency
In shortData residency says where the data sits. Not who is allowed to reach it.
At a glance
- What it governs
- Storage and processing locations, usually as a region setting in the provider portal and an assurance in the contract
- What it does not govern
- Which law the parent company answers to, and who holds administrative access in operations
- Typical gap
- Support, maintenance and abuse handling frequently run from third countries even when storage sits in the EU
- Second gap
- Backups, log data and telemetry are often treated separately and leave the region
- What it is good for
- Latency, failure zones, regulatory storage-location requirements, evidence in questionnaires
- What it is not good for
- As an answer to disclosure orders against a parent company in a third country
Data residency is a provider's promise to store and process data in particular countries. It is available in almost every cloud contract, it is usually two clicks away in the portal, and it is the most misunderstood term in this field.
The misunderstanding is easy to see: location feels like the decisive quantity. Legally it is not.
What residency actually delivers
It governs latency and failure zones — a real operational advantage for a company with European users. It satisfies regulatory requirements that explicitly demand a storage location, as in parts of healthcare and finance. And it makes evidence easier for customers who ask about it in questionnaires.
That is more than nothing. It is simply not the question a sovereignty discussion is asking.
Where the promise routinely ends
At support. A provider with European storage whose second- and third-line support sits in a third country will access your data from that third country during an incident. In data protection terms that is a transfer, and in many contracts it appears only in the annex to the Data processing agreement.
At backups and telemetry. Production data in the chosen region, backups elsewhere, error reports and usage telemetry in a global pipeline — that split is common and is rarely mentioned in the region setting.
At the parent company. Storage location changes nothing about which law the company answers to. That is exactly what the US CLOUD Act targets: it attaches to possession, custody and control, not to geography.
How to check it properly
Do not ask about the region; ask for the access matrix. Which roles can reach production data, from which countries, in which circumstances, and how is that logged? A provider who answers that cleanly within two weeks is better qualified than one with the nicer region switch.
Three points belong in the contract alongside it: the region stated explicitly for backups and logs as well, an exclusion or approval requirement for remote access from third countries, and a duty to announce changes to sub-processors.
How this connects to the other terms
Residency answers where. Key control answers who. Sovereign cloud describes the whole package of both plus ownership and operating model.
Settling only one of them gives you a partial answer — which is fine, as long as you know which part is missing.
Common questions
- Is EU data residency enough for the GDPR?
- Not for the transfer question, if a provider with third-country ties holds administrative access. Remote access from a third country to data sitting in the EU is itself a transfer in data protection terms. What matters is not only where data rests but who can reach it.
- How do I check whether the promise holds?
- Three documents: the region clause in the contract, the sub-processor list with countries, and the description of support and maintenance processes. If the third is missing or evasive, that is exactly where the gap is.
- Does the promise cover backups and logs?
- Only where it says so explicitly. In many contracts the production environment is regionally fixed while backups, telemetry and error reports are governed separately — or not at all.
- How is this different from a sovereign cloud?
- Data residency is a single property: location. A sovereign cloud additionally describes the operating model, ownership, staff access and key management. Residency is a necessary condition, not a sufficient one.