Procurement asked where your data is stored. Here is how to actually answer
“Our servers are in the EU” is not an answer to the question a compliance reviewer is asking. Here is the difference between where data sits, who owns the machine, and who can reach it.
In short
Data residency is three separate questions: where data is stored, who owns the infrastructure, and who can access it from where. A host that answers only the first has not answered the question.
A client's compliance team sends you a questionnaire. One line asks where personal data processed through your website is stored. You forward it to your host, get back “our infrastructure is located in the European Union”, paste that in, and the reviewer comes back with three more questions.
This happens because data residency is not one question. It is three, and most hosting marketing answers only the easiest one.
Question one: where is the data stored?
This is the question everyone answers, because it has the friendliest answer. Data at rest sits on a disk, the disk is in a building, the building is in a country. Frankfurt, Amsterdam, Belgium — settled.
It is a real question and it matters. It is also the one a provider can answer affirmatively while leaving the two harder ones untouched, which is why a reviewer who knows the job never stops there.
Question two: who owns the infrastructure?
A host with servers in Frankfurt may own those servers, or may be renting capacity from a hyperscaler that owns them. Both are legitimate. They are not equivalent for a compliance assessment.
If the underlying infrastructure belongs to a large cloud provider, that provider is in your processing chain whether or not it appears in the marketing. It has physical access to the hardware, and it is subject to the legal regime of its own jurisdiction — which, for a US-parented cloud, includes the CLOUD Act regardless of where the data centre stands.
The question to ask is direct: do you own the servers my data is on, or do you rent them? Providers who own their hardware answer immediately. Providers who rent tend to answer a slightly different question instead.
Question three: who can access it, and from where?
This is the one that catches people out, and the one most likely to appear in a serious audit.
Under the GDPR, making personal data accessible to someone in a third country is itself a restricted transfer. Not copying it — making it reachable. An engineer outside the EEA who can log into a production server constitutes a Chapter V transfer even though the data never leaves the disk it started on.
Which means a host can truthfully say “your data is stored in the EU and never leaves it” while its support team administers those servers from anywhere in the world. Both statements are true at once. Only one of them is on the marketing page.
Ask explicitly: which countries can your staff access production systems from, and what is the transfer mechanism? A provider with a proper answer names the countries and points at Standard Contractual Clauses in its DPA. A provider without one restates that the servers are in the EU.
How we answer all three
Storage: on hardware we own, in Tier-III data centres in Belgium and Finland. Files, databases, mailboxes and backups are stored in the EU and are not replicated to another region.
Ownership: the servers are ours. We are not reselling hyperscaler capacity, which is why we can answer the second question at all.
Access: our engineering team works from our office in Lahore, Pakistan, and can reach production systems to provide support and respond to incidents. Under the GDPR that is a restricted transfer, Pakistan has no adequacy decision, and so it runs under Standard Contractual Clauses and is named in our Data Processing Agreement alongside every other subprocessor. A transfer impact assessment is available on request.
We would rather write that here than have a reviewer discover it. If your organisation cannot accept any non-EEA administrative access — a real requirement in some regulated sectors — tell us before you buy, and the honest answer is that we are not the right host for you.
What a good answer looks like
A host being straight with you gives four things without much prompting: a named location for data at rest, a clear statement of who owns the hardware, a complete subprocessor list with countries attached, and a DPA that describes transfers rather than gesturing at them.
If the subprocessor list is a category — “essential infrastructure providers” — rather than a list of companies, it is not a subprocessor list. If the transfer section says appropriate safeguards will be applied where transfers occur, without saying which transfers occur, it is describing a policy rather than a practice.
Those two documents tell you more about a hosting provider than any amount of front-page copy about sovereignty. They are also, usefully, the two a procurement reviewer will ask for anyway.