Where your data actually sits, and what the buyer is really asking

The question arrives in a security questionnaire and looks simple: "is customer data stored in the EU?" The honest answer is usually longer than the box allows, because the data is in an EU region, the backups are too, the observability vendor is not, the support team has a follow-the-sun rota that includes two non-EU countries, and the AI feature calls a model endpoint whose location nobody has checked.

None of that is necessarily a problem. All of it has to be known, documented and defensible, and the work of getting there is inventory rather than law.

Three questions that get conflated

Where is the data at rest? A region choice, easy to verify and easy to evidence.

Where can the data be accessed from? Much harder. Support staff, engineers debugging production, a subprocessor's operations team, a vendor's own support. Access is a transfer even when the storage never moves, and this is the question buyers increasingly ask second.

Under whose jurisdiction does the processor sit? A US-headquartered provider storing data in Frankfurt is still a US company. This is the concern behind the whole framework debate, and pretending it is only about storage location misses what the buyer is worried about.

Answer all three separately in your documentation. A single sentence claiming EU storage invites a follow-up that you will answer badly under time pressure.

The mechanisms, and what each requires of you

Transfers of personal data out of the EEA need a legal basis for the transfer itself, on top of the basis for the processing.

An adequacy decision is the simplest: the Commission has determined the destination country protects data adequately, and the transfer needs nothing further. Several countries have one. For the United States, adequacy applies through a specific framework that covers organisations that have self-certified to it, which means the mechanism is company-by-company rather than country-wide. Check whether your specific vendor is on the current list rather than assuming.

Standard contractual clauses are the workhorse where adequacy does not apply. They are a set contract you incorporate, in the module matching the relationship, and they carry an obligation that many teams skip: a transfer impact assessment documenting whether the destination's laws would undermine the clauses in practice, and what supplementary measures you apply.

Binding corporate rules cover intra-group transfers for large organisations and take a long time to approve. Derogations exist for occasional transfers and are not a basis for routine product operation, however tempting that reading is.

Be aware that the transatlantic frameworks have a history. Two predecessors were invalidated by the Court of Justice, and the current arrangement has faced legal challenge. That does not mean it is invalid, and you should rely on what is currently in force. It does mean you should not build an architecture that cannot survive a change, and that a sensible answer to a buyer includes a fallback mechanism.

Supplementary measures that actually count

The transfer impact assessment asks what you do beyond the contract. Two measures carry real weight.

Encryption where the processor cannot decrypt. If the data is encrypted with keys held by you, in a jurisdiction outside the processor's reach, and the processor never sees plaintext, the exposure to a foreign access request is genuinely reduced. Customer-managed keys where the cloud provider holds the key material are weaker than external key management, and buyers who know the difference will ask.

Pseudonymisation before transfer, where the identifying data stays in the EEA and only tokens cross the boundary. Effective, and limited by what the processing actually needs.

Organisational measures such as a policy of challenging government access requests and publishing a transparency report are worth documenting, but they are commitments rather than controls. Do not present them as equivalent.

Sovereignty is a different product from residency

Buyers increasingly distinguish these, and so should you.

Residency means the data is stored and processed in a chosen region. Every major provider offers it, and it is a configuration.

Sovereignty means the operator is legally and technically insulated from foreign jurisdiction: EU-controlled entity, EU-resident staff with exclusive access, keys held outside the parent's reach. Providers now sell distinct sovereign offerings, either as their own controlled environments or through local partners, at higher cost and with a smaller service catalogue.

Most commercial buyers need residency plus good documentation. Public sector and regulated buyers increasingly ask for sovereignty, and if that is your market, the architecture decision arrives early and constrains which managed services you can use.

Find the transfers you have not noticed

The inventory is the actual work, and the same one that underpins GDPR as engineering controls. The places teams miss are consistent:

• Observability. Logs and traces carry personal data and often go to a vendor whose default region is not yours. Check the ingestion endpoint, not the marketing page.
• Support tooling. Ticketing systems hold whatever customers paste in, which is everything.
• Email and notification providers, which by definition process addresses and message content.
• AI and model endpoints. A model call sends the prompt somewhere. Region-pinned endpoints exist on the major platforms; confirm you are using one and confirm the data retention terms.
• CDN and edge compute, which may execute in many locations by design.
• Analytics and product telemetry, the most common unexamined transfer.
• Your own staff. An engineer with production access working from a non-EEA country is a transfer, and remote working policies rarely mention it.
• Backups and disaster recovery, where a second region is sometimes chosen for availability without anyone checking the jurisdiction.

What to put in front of a buyer

Prepare these before you are asked, because assembling them under a deadline produces vague answers that lose deals.

A subprocessor list with each entity, its role, the data categories it receives and its location. A statement of storage and processing regions per data category. The transfer mechanism relied on for each non-EEA subprocessor. A short description of your supplementary measures. Your data processing agreement with the clauses already incorporated. And a named contact for privacy questions.

Keep the subprocessor list current and publish it, because changes usually carry a notice obligation to your own customers, and a stale list is a contractual problem rather than just an awkward one.

The things people forget

• Metadata is personal data. IP addresses, device identifiers and usage telemetry count, even when the payload stays home.
• A region is not a guarantee of where support sits. Ask your provider directly and get it in writing.
• Adequacy can change. Build so that changing a vendor or a region is a project, not a rewrite.
• The US is not the only question. Buyers increasingly ask about every non-EEA location in the chain.
• Documentation is the deliverable. In practice you are assessed on whether you can evidence the analysis, not on whether the answer is elegant.

What to do this week

List every third-party service that receives production data, including the ones engineering added without procurement, and write the country next to each. The row you cannot fill in is the finding, and there is almost always at least one. We build that list in the first week of a security engagement.