Three phrases get used interchangeably in vendor conversations and mean different things. Getting them apart matters, because a supplier can satisfy one and not the others, and a buyer who accepts a residency commitment as an answer to a transfer question has not received an answer at all.
- Data location is a factual statement about where data physically sits at a given moment.
- Data residency is a commitment, usually contractual or configuration-based, that data will be kept in a stated region.
- An international data transfer is a legal concept under Chapter V of the General Data Protection Regulation (GDPR), triggered when personal data is made available to a recipient in a third country, including by remote access.
The critical point is the last one: a transfer can occur without any change in data location. Access is enough.
Why residency does not answer the transfer question
A supplier offering an EU region is making a storage commitment. Storage is one input to the transfer analysis and not the decisive one.
Consider a service hosted entirely in an EU region. Its support engineers work from three countries, one outside the European Economic Area. When a support engineer opens a customer record to investigate a ticket, personal data is made available to a person in a third country. That is a transfer, and it requires a lawful route, regardless of where the bytes are stored.
The same is true for administrative access, engineering diagnostics, security operations, and offshore development teams working against production data. Our international data transfer checklist treats access mapping as a distinct step for exactly this reason.
The four questions to ask instead
Replace "do you offer EU data residency" with four questions that produce usable answers:
- Where is the data stored, by country, including backups and disaster recovery?
- From which countries can your personnel access it, and in what roles?
- Which sub-processors are involved, where are they established, and what do they do?
- For each destination outside the European Economic Area, which transfer mechanism applies?
A supplier that answers all four clearly is unusual and worth valuing. One that answers only the first is describing residency and calling it compliance.
What a residency commitment is still worth
Residency is not meaningless. A genuine regional commitment reduces the number of destinations you have to analyse, simplifies the record, and can remove a category of exposure entirely where it is paired with access controls.
It is most valuable when it covers:
- Production storage and backups, not production alone.
- Processing as well as storage, so that computation does not move.
- Support and administrative access, not just data at rest.
- Sub-processors, so the commitment survives one layer down.
A commitment scoped only to primary storage is the weakest form, and it is also the most commonly marketed.
Sovereignty claims deserve the same scrutiny
Terms such as sovereign cloud or regional sovereignty describe commercial offerings rather than legal categories. Some are substantive: separate legal entities, local operational staff, and technical controls that prevent parent-company access. Others are ordinary services with a regional label.
Assess the claim against the same four questions. The one that discriminates most reliably is whether a parent entity in a third country can compel or obtain access, because that determines whether the arrangement changes the legal position or only the marketing.
Where the confusion causes real problems
Three recurring failures come from conflating the three concepts.
Records that describe storage instead of transfers
An Article 30 record listing "EU" for a vendor whose support runs from elsewhere is inaccurate, and inaccuracy in that record is difficult to explain later. Our article on keeping records accurate as vendors change covers the maintenance problem.
Assessments that stop at the hosting region
A transfer assessment that examines only the storage destination misses the access destinations, which are frequently where the legal-access concern actually arises.
Sub-processor changes assessed as non-events
A vendor adding a sub-processor "in the same region" may still have added an entity whose personnel or parent sit elsewhere. Region is not the unit of analysis; the entity and its access are. Our guide to evaluating a sub-processor list covers reading entries properly.
Getting it into the contract
If residency matters to you, write it as an obligation rather than a configuration setting:
- State the permitted regions for storage, processing, and backup.
- State whether access from outside those regions is permitted, and if so under what controls.
- Require notice before any change to either.
- Require sub-processors to be bound to the same limits, consistent with the flow-down obligation in Article 28(4).
- Provide for the change to be treated as a sub-processor change with the associated notice and objection rights.
A residency clause without the access limb is the version most often signed and least often sufficient.
Frequently asked questions
Is data residency required by the GDPR?
No. The GDPR does not require personal data to stay in the European Economic Area. It requires transfers outside it to rest on a lawful mechanism under Chapter V. Residency is one way to reduce the number of transfers, not a legal obligation in itself.
Does encryption remove the transfer?
Encryption is a supplementary measure, not an exemption. Where the importer holds no key and cannot access the plaintext, it can materially change the risk analysis; where the importer holds the key, it changes little. The European Data Protection Board's Recommendations 01/2020 address when measures are effective.
Our vendor says data never leaves the EU. Is that enough?
Ask the access question explicitly and in writing. The statement is usually made about storage in good faith, and support arrangements are often outside the speaker's knowledge.
What about metadata and logs?
They frequently contain personal data and frequently follow different routing from primary data. Ask where logs, telemetry, and error reports are processed, because they are commonly centralised outside the region the service is sold in.
Where DPAFlow fits in
Location, residency, and transfer positions are all recorded from vendor disclosures, and those disclosures change. DPAFlow checks vendor sub-processor lists, Data Processing Agreement pages, and trust-center pages on a scheduled, recurring basis, records what changed with dated evidence including captured page text and change differences, and sends email alerts. Detected changes enter a review workflow where your team decides whether the transfer position has moved.
DPAFlow does not determine whether an arrangement is lawful and does not provide legal advice. The evidence model is described on the evidence page.
This article distinguishes three concepts in general terms. It is not legal advice, and the transfer conclusions belong to your privacy function and counsel.