Residency and regions¶

Keeping data in the geographic locations that law, contracts or customers require, while still allowing analysis that spans regions.

Before reading

PII and data classification

Why it matters¶

A business that serves customers in several countries meets rules about where their data may be stored and processed. Some laws require certain data to stay in the country. Others allow transfers abroad only under conditions, as the GDPR does for transfers of personal data out of the European Economic Area. Customer contracts often add their own requirements. A platform that copies everything into one region can break these rules without anyone noticing.

How it works¶

Data residency is where data is stored and processed. Data localisation is a legal requirement that certain data stays in a country. Data sovereignty is the broader idea that data is subject to the laws of the place it is stored or of the provider holding it. Processing counts too: a query engine in one region reading files in another moves the data, even if only temporarily.

The first step is knowing what is affected. Classification marks personal and otherwise regulated data; each record also needs a home region, decided by a rule such as the customer's country of residence or the contract they signed. The home region is set at ingestion and travels with the data as a column.

The common design is regional stacks. Each region has its own storage, catalog and compute, and ingests and processes the data of customers whose home region it is. Pipelines and models are the same code, deployed per region, so results are comparable. Regulated data never leaves its region's stack.

Global analysis is built from what may leave. Each region produces aggregates, or pseudonymised or anonymised data where the rules allow it, and publishes them to a global layer. Global reports, such as revenue by country across all regions, read only those outputs. Whether a given output may leave is a legal decision recorded per dataset, not a technical default.

flowchart TB
  subgraph EU[EU region]
    direction LR
    E1[EU customers<br/>and orders] --> E2[(EU stack:<br/>raw, clean, gold)]
  end
  subgraph US[US region]
    direction LR
    U1[US customers<br/>and orders] --> U2[(US stack:<br/>raw, clean, gold)]
  end
  E2 -->|aggregates only:<br/>revenue by day and country| G[(Global layer:<br/>cross-region reports)]
  U2 -->|aggregates only| G
  EU ~~~ US

Routing decides which region data goes to. Applications that serve customers in several regions send each customer's events to their home region, using the home region stored with the account. Ingestion checks the home region on each record and rejects or quarantines records that arrive in the wrong region, rather than storing them.

People and access are part of residency. Under the GDPR, access from abroad by another company, including a group company, is a transfer; access by the controller's own employees is not, though it still needs security controls. Other countries' laws can be stricter. Access policies can include the user's location or legal entity as an attribute, and support access to regional stacks can be restricted to staff in or approved for that region.

Regional stacks cost more than one shared stack: more infrastructure, more deployments, duplicated reference data.

Key terms¶

Data residency: the location where data is stored and processed.
Data localisation: a legal requirement that certain data stays within a country.
Data sovereignty: data being subject to the laws of where it is held, or of who holds it.
Home region: the region a record belongs to, decided by a rule such as residence.
Regional stack: a full set of storage, catalog and compute for one region.
Cross-border transfer: data, or access to it, moving from one jurisdiction to another.

Example¶

The shop sells in the EU and the US. Its rule: EU customers' personal data stays in the EU stack; US customers' data in the US stack.

The web app routes each checkout to the customer's home region; clean_customers and clean_orders exist in both stacks, built by the same dbt project with a region variable.
Each stack publishes fct_daily_sales_by_country, with no customer-level data, to the global layer.
The CFO's dashboard reads the global table and shows revenue for both regions together.
An analyst employed by the shop's US company who needs EU customer-level data requests access to the EU stack; because that company is a separate legal entity, this is a transfer, approved only with a recorded legal basis and a transfer mechanism, such as the EU-US Data Privacy Framework (if the US company is certified; in force, checked October 2026) or standard contractual clauses.

When an EU customer moves to the US, the support team triggers a migration job that copies their records to the US stack, erases them from the EU stack and logs both steps; the copy is itself a transfer and uses the same mechanism as other EU-to-US flows.

Pitfalls¶

A global copy "just for analytics". It quietly moves regulated data out of its region.
No home region on records. Routing and residency cannot be checked afterwards.
Forgetting processing and access. Compute in another region, or access by another company abroad, can amount to a transfer.
Backups and disaster recovery in another region. Recovery copies are stored data too.
Splitting everything by default. Separate stacks only for data whose rules require it.

Learn more¶

European Commission, international data transfers under the GDPR: https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection_en
GDPR, Chapter V, transfers to third countries: https://eur-lex.europa.eu/eli/reg/2016/679/oj

Multi-tenancy · Privacy lifecycle · Disaster recovery · Data sharing