Three requirements wearing one name
Ask which of three things is being required, because the architectures diverge sharply and the words are used loosely.
Residency is a statement about where bytes rest: the data is stored in this country. It is the easiest to satisfy and the weakest guarantee, because a foreign-owned operator storing data locally may still be subject to legal process elsewhere. Sovereignty adds a claim about which legal system and which operator can reach the data, which is why some public-sector requirements insist on a locally owned provider, or on customer-held keys, or on operational staff who are nationals and located in-country. Localisation is the strong form: the data may not leave, full stop, which removes cross-border processing options that residency alone would allow.
Then ask what class of data the rule covers, because rules are almost never about all of it. They cover personal data, or health records, or payment credentials, or public-sector records, and the design leverage comes from separating the constrained class from everything else. Treat every byte as constrained and you replicate the whole platform per country, which is expensive and also tends to fail, since the more you duplicate the more places a mistake can hide.
What you pin on purpose
The obvious stores get pinned quickly and are rarely where the failure is: the primary database and its replicas, the object store, the search index, the cache, the broker, any analytical copy. Three less obvious ones deserve to be named unprompted.
Backups are a store. A managed database service that ships automated backups or point-in-time snapshots to a location you did not select has moved the data, and its being a vendor default rather than a decision does not help you.
Disaster recovery is the same problem wearing a virtue. The instinct that DR belongs in another geography for independence is right in general and wrong here: a failover region outside the jurisdiction is a permanent copy outside the jurisdiction. Under localisation, DR becomes a second availability zone or a second in-country site, so you are buying less geographic independence than you would elsewhere. Say that out loud, because it is a trade-off you are accepting rather than an oversight.
Key material is the third. If the data is encrypted under keys held in another region, the ciphertext is local and the ability to read it is not, which under a sovereignty requirement is often the whole point of the rule. Keys live in-region, and where the requirement is strong, in hardware the operator cannot use on the customer's behalf.
What leaves without anyone deciding
This is the part of the answer that distinguishes someone who has done it. Every leak below is created by a well-intentioned engineering practice, none of them is visible in an architecture diagram, and collectively they are how residency programmes actually fail.
Telemetry. Metrics are supposed to be aggregate and non-personal, which is true until someone adds a label. A metric tagged with a user identifier, an email address, an account name or a full request path is personal data being written into a monitoring backend that is very often a single global SaaS tenant in another country. High-cardinality labels are already a cost problem; here they are a compliance problem.
Error tracking. An exception reporter is a firehose pointed at a foreign region by default. The stack frame carries local variables, the breadcrumb trail carries recent user actions, the request context carries headers and body, and someone has helpfully attached the authenticated user's profile to make triage easier. It is the commonest source of unintended transfer in a web application, because a developer installs it on day one and nobody ever reviews it as a data flow.
Log shipping, traces and session replay. Logs get centralised because centralising them is correct operational practice, and the central place is usually one cluster for the whole company, holding whatever developers printed — which over a few years includes identifiers, addresses, payloads and the occasional token. A trace carries span attributes and often request and response fragments. A session-replay tool records the user's screen, which is to say every field they typed, and ships it wherever the vendor terminates.
The tools around the edges. Email and SMS providers see the recipient and the content, push services see the payload, feature-flag platforms see the attributes used for targeting, and payment processors see cardholder data by design. A CI pipeline seeded with a production dump has copied the database to wherever the build runs. Any AI feature calling a model endpoint sends the prompt, and the prompt is whatever the user's document said.
Support tooling, and this one is not about bytes at all. A ticketing system holds the customer's description of the problem, the screenshot they attached and the CSV an engineer exported to reproduce it, so it is a full-fidelity copy of exactly the data the rule protects. Worse, remote access counts: a support engineer or on-call SRE in another country, viewing a record through a bastion or an admin console, is generally treated as a transfer to their location even though nothing was stored there. That reframes the problem from network topology to rota design — who may be on call for this region, and what your existing follow-the-sun model implies. Candidates who reach this point have usually been through an audit.
The structural response to all of it is that every outbound integration is a data flow requiring a decision, and the enforcement cannot be a wiki page. Deny egress by default at the network boundary, so a newly added SDK fails loudly instead of silently exporting; require regional endpoints or regional tenants from every vendor and reject vendors that cannot offer one; and scrub at the emitting process rather than at the receiver, because a promise from a vendor to drop a field is a contract, not a control.
The topology this produces
What falls out is a silo per jurisdiction rather than one global system with a region column. Each region runs a full stack for the constrained data: its own database, its own storage, its own observability backend, its own support queue. The regions do not read each other's data. Above them sits a thin global control plane that holds only what is genuinely non-personal — the service catalogue, deployment configuration, entitlements, billing totals, aggregate metrics — and every field in it is there because someone asserted it carries no personal data.
Two design problems always appear. The first is routing: you must decide which region owns a request before you can look anything up, and without a global table of users. Make the region derivable from something the client already presents — a tenant-scoped subdomain, a region prefix inside an opaque account identifier, or a token whose issuer identifies the region — so the edge routes on a non-personal key. The lazy alternative, a global directory mapping email addresses to regions, is itself a store of personal data in the one place you promised not to put any, and it will be found.
The second is anything global by nature. Cross-region reporting is solved by computing aggregates in-region that cannot single out an individual and pushing them up, never by pulling rows into a central warehouse. Global uniqueness is solved either by accepting per-region namespaces, which is usually fine and occasionally unacceptable to the business, or by a global index of salted hashes holding no reversible identifier, which answers "does this exist" without holding the value. Choosing between them is a product decision rather than an engineering one.
The failure that survives every review
Teams pass residency reviews on the diagram and fail on the exhaust. The database is in the right country, the bucket has the right region in its name, the architecture document is convincing, and meanwhile the error tracker, the metrics labels, the centralised log pipeline and the shared support desk are quietly maintaining a complete parallel copy elsewhere — assembled incrementally by people making sensible operational choices, none of whom saw themselves as making a compliance decision.
Residency is enforced at the egress boundary and in the vendor list, not in the data-store configuration, and if you cannot name every destination your processes talk to then you do not know whether you comply. Which is why this is one of the few requirements where observability belongs in scope from the first sprint: retrofitting a regional telemetry stack after two years of instrumentation is a far bigger project than standing one up early.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).