How do you handle data residency in a hybrid cloud?
Start by checking whether the requirement is real, because a large share of them are not what the organisation believes. The sentence usually reaches an architect as "the data cannot leave the country", and when the underlying source is traced it is often a customer contract covering one field, an internal policy written before in-country cloud regions existed, or an answer someone gave on a procurement questionnaire that has since become folklore. The engineering is straightforward once the requirement is precise, and impossible while it is not.
Residency, sovereignty or localisation: which one do you have?
They are three different requirements and they demand different architectures. Residency is about where data is physically stored. Sovereignty is about whose laws and whose personnel can reach it. Localisation is a legal mandate that specified data must remain within a country's borders.
Residency is the easiest to satisfy, because every major provider offers regions in many countries and pinning storage to one is a configuration decision. Sovereignty is harder, because it concerns control rather than location: a data centre in your country operated by a company incorporated elsewhere may satisfy residency and still fail a sovereignty test if the concern is which government could compel disclosure or which staff can access support systems.
Localisation is the narrowest and the most binding, and it genuinely exists for particular categories in particular jurisdictions, commonly certain health, public sector and financial records. It is also the one most often invoked by analogy, where a rule that applies to one narrow category is applied to a whole estate because nobody has read it recently.
Where is the requirement actually coming from?
One of four places, and identifying which changes both the architecture and who can approve an exception. A statute or regulator's rule is not negotiable and needs a compliant design. A customer contract clause is negotiable in principle and enforceable in practice, and it usually applies to that customer's data rather than to all of it. An internal policy can be updated by the organisation that wrote it. A procurement questionnaire answer is not a requirement at all, though it may have become a contractual commitment by reference.
The single most useful action available here is asking for the clause in writing. Not a summary, not a policy page, the actual text. This request commonly reveals that the requirement covers one data category rather than a system, or names a region rather than a country, or has an exception for processing that most designs would already satisfy.
It is worth being precise about one widely misquoted example. European data protection law does not require that personal data stay in Europe. It restricts transfers to countries lacking equivalent protection unless a recognised transfer mechanism is in place, which is a materially different constraint and one that many hybrid designs meet without relocating anything.
| Source | How to verify | What it typically constrains | Who can grant an exception |
|---|---|---|---|
| Statute or regulator's rule | Named instrument and the specific clause | A defined data category, not a whole system | Nobody internally |
| Customer contract | The executed agreement, not the sales summary | That customer's records only | The customer, by amendment |
| Sector code or certification | The control reference in the scheme | Controls and evidence, often not location | The certifying body, by compensating control |
| Internal policy | The document and its date of issue | Whatever it says, often written pre-cloud | The policy owner |
| Questionnaire answer | The original response and whether it is incorporated | Nothing, unless referenced by a contract | The organisation that answered it |
Does an in-country cloud region satisfy it?
For residency, usually yes, provided you pin every service to that region and verify it rather than assume it. Not every managed service is regional, some have global control planes, and defaults occasionally place a component elsewhere.
For sovereignty, not automatically, and this is where hybrid architectures stop being optional for some organisations. The questions a sovereignty assessment asks are about reach rather than geography: can staff outside the jurisdiction access systems for support, where do the provider's operational logs and telemetry go, who holds the encryption keys, and could a foreign legal instrument compel disclosure from the parent company. An in-country region can be perfectly compliant on storage location and fail on all four.
The providers have responded with sovereign cloud offerings, partner-operated regions and controls limiting operational access to in-country personnel. These are real and they satisfy some assessments, so they belong in the evaluation. They are also newer, narrower in service catalogue and priced accordingly, which means they need pricing and feature checking rather than acceptance on the basis of the name.
What leaves the jurisdiction even when the database does not?
More than teams expect, and this is where residency designs usually fail an audit rather than at the primary store. The database was placed carefully. Everything that touches it was not.
The recurring offenders: application and error logs shipped to a monitoring platform hosted elsewhere, backups replicated to a second region for durability, telemetry and crash reports from client applications, email and notification services that carry customer detail in the message body, search indexes built in one place from data stored in another, content delivery caches holding responses at edge locations worldwide, analytics tags in a web front end, and support tickets in which someone pasted a record to explain a problem.
The practical test is to list every destination that receives any part of the data, including systems nobody thinks of as data systems, then confirm the hosting location of each. Error tracking and support tooling are the two that most often turn up in the wrong place, because both were adopted by a team on a self-service basis rather than through the process that reviewed the database.
How do you design for residency without a full on-premise estate?
By separating the data that is actually constrained from the data that is not, because the constrained portion is usually a small set of fields rather than a whole system. Once identified, the identifying fields can stay in the jurisdiction while everything else moves freely, which converts a total blocker into a bounded piece of engineering.
The mechanism is tokenisation. Replace the constrained fields with meaningless references before anything leaves, and keep the mapping between reference and real value in the environment that must hold it. Cloud services then process records that contain no regulated content, and re-identification happens only at the boundary where an authorised user needs the real value. This is materially stronger than encrypting everything and moving it, because the sensitive value never leaves at all.
Where the whole record must stay, the remaining options are keeping the processing next to it and exporting only aggregates, or holding your own encryption keys so that data in a cloud service is unreadable without a key your jurisdiction controls. Customer-managed keys are widely available and are a genuine control, but they are a control over confidentiality rather than location, so they answer a sovereignty concern about access and do not answer a localisation rule about where bytes sit.
What should you check before committing to a design?
Five things, and the first two are not technical. Get the requirement in writing with its source named. Establish which specific data categories it covers, since it is rarely all of them. Then list every downstream destination that receives any part of the data, including logs, backups, monitoring, notifications and support tooling. Confirm where each of those is hosted. And ask who is accountable for signing off the design, because a residency architecture approved by nobody is a finding waiting for an auditor.
Do this before the architecture, not after. Residency constraints determine the shape of a hybrid design more completely than any other factor, and discovering one late means rebuilding rather than adjusting.
One test is worth running regardless of what the documents say. Take a single real record, and trace every system it reaches over one week. The gap between where teams believe data goes and where it goes is consistently wide, and it is almost always in the tooling around the application rather than in the application itself.
Common questions
- What is the difference between data residency and data sovereignty?
- Residency is about where data is physically stored, and is generally satisfied by pinning services to an in-country region. Sovereignty is about whose laws apply and whose personnel can reach the data, which location alone does not settle: a data centre in your country operated by a company incorporated elsewhere may satisfy residency while failing a sovereignty test concerning foreign legal compulsion or support staff access. Localisation is a third, narrower thing: a legal mandate that specified data remain within a country's borders.
- Does GDPR require data to stay in the EU?
- No. European data protection law does not mandate that personal data remain in Europe. It restricts transfers to countries without equivalent protection unless a recognised transfer mechanism is in place, which is a materially different constraint. Many hybrid designs satisfy it without relocating anything. Sector-specific rules and individual customer contracts may impose stricter location requirements, which is why the source of a stated requirement matters more than the general regulation.
- Does using an in-country cloud region satisfy data residency?
- For residency usually yes, provided every service is pinned to that region and verified rather than assumed, since some managed services have global control planes and defaults occasionally place components elsewhere. For sovereignty it is not automatic, because the questions are about reach rather than geography: support access from outside the jurisdiction, where operational telemetry goes, who holds encryption keys, and whether a foreign legal instrument could compel disclosure.
- What data leaves the country even when the database stays?
- Application and error logs shipped to monitoring platforms hosted elsewhere, backups replicated to another region for durability, client telemetry and crash reports, notification and email services carrying record detail in the message body, search indexes, content delivery caches at edge locations, front-end analytics, and support tickets containing pasted records. Error tracking and support tooling are the most frequent offenders because both are typically adopted by teams without the review the database received.
- How can you use cloud services for data that cannot leave the country?
- Tokenise the constrained fields. Replace them with meaningless references before anything leaves, keeping the mapping between reference and real value inside the jurisdiction, so cloud services process records containing no regulated content and re-identification happens only at the boundary. This is stronger than encrypting and moving the data, because the sensitive value never leaves at all. Where whole records must stay, process next to them and export only aggregates.
- Do customer-managed encryption keys satisfy data residency requirements?
- They address confidentiality and access, not location. Holding your own keys means data in a cloud service is unreadable without a key your organisation controls, which can answer a sovereignty concern about who could compel or perform access. It does not answer a localisation rule that specifies where bytes must physically sit, because the encrypted data is still stored outside the required territory.
