How to answer
Where is customer data hosted, and can it be kept in a specific region?
The database is the easy half. A reviewer at an EU company is asking about every sub-processor and about who can read a record from where.
Customer data is stored in [region]. Data for EU customers can be pinned to [EU region] on request. Where data is transferred outside the EEA it is covered by the Standard Contractual Clauses annexed to our DPA.
Square brackets are yours to fill in. FillTrust grades an answer like this reused from your library when your documents support it.
- Answered from
- Your DPA and your sub-processor list, together. The DPA states the transfer mechanism; the list states where each party actually sits.
- Evidence to attach
- Nothing usually. EU buyers sometimes ask for the Standard Contractual Clauses, which are an annex to the DPA.
- Where it is asked
- CAIQ v4.0 · DSP-19SIG LiteGDPR · Ch. V
For a US buyer this is a formality. For an EU buyer it can be the question that decides the deal, and it is worth answering with more care than its one line suggests.
Start with where the data actually sits: the primary region for your database and object storage. That is the easy half and most answers stop there.
The half that matters is everywhere else it goes. Your error tracker, analytics, support desk, transactional email and model provider each receive some slice of customer data, and each sits somewhere. If your database is in Frankfurt and your error tracker is in Virginia, customer data is being transferred to the United States, and a reviewer comparing your residency answer to your sub-processor list will see it. The two answers have to be consistent, which in practice means writing them at the same time.
There is a subtlety that trips up careful teams as well as careless ones: remote access is a transfer. If support staff outside the EEA can view a customer record, that is an international transfer under GDPR even though the data is stored in Frankfurt and never copied. A claim that data "never leaves the EU" is difficult to sustain for any company with a distributed team, and the safer, more accurate framing is that data is stored in the EU and any access from outside it is covered by the Standard Contractual Clauses.
On regional pinning: only offer what you can configure. This is a question whose answer routinely gets lifted into a contract, and "EU data can be pinned to an EU region on request" becomes an obligation the moment someone requests it. If you have not built it, the honest answer is where the data is stored today plus the transfer mechanism, which is a perfectly acceptable answer on its own.
The transfer mechanism is worth naming explicitly, because it is what an EU reviewer is looking for: the Standard Contractual Clauses, annexed to your DPA. Naming them saves the round trip where they ask.
How this one goes wrong
Specific to this question, not general advice.
- Answering for the primary database and not for the sub-processors. If your error tracker or model provider is in another jurisdiction, the data went there too.
- Offering regional pinning you cannot actually configure. This is a question that turns into a contract clause.
- Saying data "never leaves the EU" while support staff outside it can read a record. Access from a third country is a transfer.