Ask most teams where their code lives and you get the name of a git host. Ask where the production data lives, which jurisdiction the backups sit in, and who at the vendor can read a customer record on a Tuesday afternoon, and the answers get considerably vaguer. For a European buyer outsourcing development, that vagueness is the entire risk.
This is not a legal article and nothing here is legal advice. It is the engineering side of the question: what to establish, and where the answers usually turn out to be wrong.
Four different questions people ask as one
- Where is the data stored? The region your database and object storage actually run in — not the region of the console you log into.
- Where is it processed? Different, and more slippery. A queue worker, a log pipeline, an analytics job or a third-party API can move data out of the region your database never leaves.
- Who can access it? An engineer in another country reading production to debug an incident is a transfer, whatever the storage region says. This is the one most teams have not thought through.
- Who controls the accounts? If the cloud tenancy belongs to the vendor, then residency, retention and access are all governed by their operational choices rather than yours.
Where it usually leaks
The primary datastore is almost never the problem. Somebody chose that region deliberately. The leaks are in the periphery, which nobody diagrams:
- Logs and traces. Observability platforms are cheerfully global by default, and application logs contain more personal data than anyone intends.
- Backups and snapshots. Frequently replicated to a second region chosen for durability rather than jurisdiction, and rarely revisited.
- Support and debugging. Screenshots in ticket systems, database dumps copied to a laptop to reproduce a bug, exports pasted into a chat thread.
- Third-party services. Email delivery, error tracking, payment providers, and increasingly model APIs. Every one is a processor and every one has its own regional behaviour.
- Non-production environments. Staging seeded from a production dump is the most common single failure, because the controls on staging are always weaker.
Distance is a design question, not a disqualifier
Buyers sometimes conclude that a distant engineering team is incompatible with strict residency requirements. That conflates two separate things: where data lives and where engineers sit. A team can build and operate a system whose data never leaves a given region, provided the access model is designed rather than assumed.
What that design usually involves is unglamorous. Production access is brokered rather than standing, and it is logged. Debugging runs against synthetic or masked data by default, with access to real records treated as an event requiring a reason. Environments are seeded from generators, not dumps. Third-party processors are enumerated somewhere a person can actually read, and revisited when someone adds one.
None of that is exotic. It is mostly the discipline of deciding these things deliberately at the start, instead of discovering the arrangement during a due-diligence questionnaire two years later.
When sovereignty becomes an architecture decision
For some buyers — public sector, health, telecom, parts of finance — the requirement goes past region selection on a hyperscaler and into who ultimately operates the infrastructure. That is a different conversation, and it is one of the few places where running your own cloud stops being nostalgia and starts being the straightforward answer. We have written about when a private cloud beats the hyperscalers, and residency obligations are one of the clearer cases. We also set out what running a private cloud involves for exactly this kind of requirement.
What to ask your vendor
- Whose cloud accounts is this running in, and can I revoke your access today without breaking production?
- Which of your engineers can read production data, through what mechanism, and where is that logged?
- How is staging seeded?
- What is the complete list of third-party processors touching this system?
- Where do logs, traces and backups physically end up?
Our own default is that the repositories and the cloud accounts are yours from day one, which makes most of the above answerable by you rather than by us. If you are working through residency constraints on a system that already exists, a technical call is a faster way through it than a questionnaire.