Health Data Residency Requirements: 2026 Guide

Data residency requirements are legal or regulatory rules that determine where health data may be physically stored and processed — typically requiring it to remain within a specific country or region. In 2026 there is no single global standard: health data residency is governed by a patchwork spanning the General Data Protection Regulation (GDPR) and the European Health Data Space (EHDS) in Europe, national instruments such as France’s Hébergeur de Données de Santé (HDS) certification and Australia’s My Health Records Act, and sector rules for genomic data such as China’s Human Genetic Resources regulations. The practical consequence for any multi-country research or AI programme is that health data increasingly cannot be pooled in one place — analysis has to travel to the data instead.

Why residency matters more in 2026

Three forces have converged. First, the EHDS regulation entered into force in March 2025 and anchors secondary use of health data in secure processing environments, with electronic health data to be stored and processed in the European Union — third-country arrangements are confined to narrow, adequacy-based exceptions. Second, the case law that began with the Court of Justice of the European Union’s Schrems II judgment (C-311/18) continues to make transatlantic transfer mechanisms legally unstable, and data protection authorities now scrutinise health-data transfers more aggressively than any other category. Third, governments have connected residency to a larger agenda: national capability in artificial intelligence. If a country’s health records train the models, ministers increasingly insist the data, the compute, and the resulting models remain under national jurisdiction — the position generally described as Sovereign AI in healthcare.

For policy makers, residency is therefore no longer a hosting detail delegated to procurement. It is the constraint that decides which research collaborations, which industry partnerships, and which Sovereign AI programmes are lawful at all.

Residency, localisation, and sovereignty: the definitions

The vocabulary is often blurred, and precision matters when drafting policy. Data residency describes where data is physically stored — a factual property of infrastructure. Data localisation is a legal mandate that data must stay within a jurisdiction, sometimes with a prohibition on any foreign access. Data sovereignty is broader still: the principle that data remains subject to the laws and governance of the state where it originates, covering not just storage location but who can compel access — a live issue given extraterritorial instruments such as the United States Clarifying Lawful Overseas Use of Data (CLOUD) Act, which can reach data held abroad by US-headquartered providers. A dataset can be resident in-country yet not sovereign, if the operator of the infrastructure answers to a foreign legal order. Mature health-data policies in 2026 address all three layers, and Sovereign AI strategies stand on the third: sovereignty over data implies sovereignty over the models derived from it.

Health data residency requirements by jurisdiction

The table is a snapshot, not legal advice: several of these instruments carry implementing rules still being finalised, and national positions have tightened, not loosened, every year since 2020. The direction of travel is uniform even where the letter differs.

The Sovereign AI angle: residency as an architecture problem

Read together, these regimes make one research pattern effectively obsolete: copying health data from multiple countries into a single analytical cloud. Any programme spanning, say, a German hospital network, an Australian registry, and a Singaporean cohort now faces at least three incompatible residency regimes — and a central data lake satisfies none of them. Organisations respond in one of two ways. The first is fragmentation: standing up isolated national environments and giving up on cross-border science. The second is federation — keeping every dataset inside its own jurisdiction and moving the computation instead.

A federated Trusted Research Environment (TRE) implements the second answer. Each country or custodian runs its node on infrastructure that satisfies its own residency law; approved analyses are dispatched to every node; and only aggregate, disclosure-checked results cross borders. The data never leaves the source, so residency compliance is a property of the architecture rather than a clause in a transfer agreement that a regulator may later strike down. The same topology is what makes Sovereign AI practical rather than rhetorical: models can be trained federatedly across national nodes — each government retaining physical and legal custody of its citizens’ records — while the learning, not the data, is shared. This is the pattern Lifebit deploys with national programmes, and the reason Sovereign AI for governments is inseparable from residency policy: sovereignty claims collapse the moment training data is exported.

Real-world example: national programmes that kept data at home

Genomics England shows the model working at national scale: one of the world’s largest genomic medicine datasets is analysed by thousands of approved researchers worldwide, yet the genomes and linked National Health Service records remain on UK infrastructure — researchers come to the data through a governed environment rather than receiving extracts. Singapore’s public-health ecosystem applies the same principle, with Lifebit supporting federated analysis across institutional custodians so that data remains within national boundaries and under national governance while still contributing to collaborative research. In both cases residency compliance was not retrofitted with contracts; it was designed in, and it became the foundation on which each country’s Sovereign AI ambitions could credibly rest.

Common pitfalls in residency compliance

Residency work fails in predictable ways, and most failures are conceptual rather than technical. Four errors recur. First, conflating residency with sovereignty: hosting data in-country on infrastructure operated by a provider subject to foreign disclosure law leaves the sovereignty question open — evaluate the operator’s legal exposure, not just the data centre’s postcode. Second, treating pseudonymised data as out of scope: under GDPR, pseudonymised health data is still personal data, and its transfer abroad is still a restricted transfer. Third, compliance by contract alone: standard contractual clauses can be invalidated or found insufficient, as Schrems II demonstrated; architecture that avoids the transfer outperforms paperwork that permits it. Fourth, ignoring derived data: model weights, embeddings, and detailed statistical outputs can carry personal information out of a jurisdiction just as an extract would, which is why credible frameworks pair residency rules with automated output control on everything that leaves the environment. A fifth, quieter failure is static compliance: residency positions are reassessed at procurement and then never again, even though every jurisdiction in the table above has amended its rules within the last five years. Residency review belongs on an annual governance calendar, not in a project’s closing report.

What to do next

Policy and programme leaders should start with a residency map: inventory every health dataset, the jurisdictions it touches, and the instruments that bind it — then classify each planned use as compatible, conditional, or prohibited under those rules. Where multi-country analysis is conditional or prohibited, evaluate federated architectures before transfer mechanisms: a design in which analysis moves and data does not is robust to the next Schrems-style ruling in a way no contractual mechanism can be. Finally, write residency requirements into procurement at the architectural level — require demonstrable in-jurisdiction processing, operator-law analysis, and controlled outputs — so that Sovereign AI programmes are built on infrastructure that can honour the promises made for them. The countries and organisations getting this right have stopped asking how to move health data lawfully, and started asking why it needs to move at all.

Frequently asked questions

What are data residency requirements for health data?

They are legal rules specifying where health data may be stored and processed — usually requiring it to remain within a country or region. Examples include Australia’s prohibition on holding My Health Record data offshore, Germany’s § 393 SGB V cloud rules, and the EHDS requirement that secondary-use health data be stored and processed in the EU.

What is the difference between data residency, localisation, and sovereignty?

Residency is where data physically sits; localisation is a legal mandate that it stay there; sovereignty is whether the data remains subject only to its home jurisdiction’s law, including who can compel access to it. A dataset can be resident in-country yet exposed to foreign legal orders through its infrastructure operator.

Does the GDPR require health data to stay in the EU?

Not as a blanket rule — GDPR permits transfers with adequacy decisions or appropriate safeguards. In practice, health data transfers face intense scrutiny, and the EHDS adds an explicit EU storage-and-processing requirement for health data used through its secondary-use framework.

Is pseudonymised health data exempt from residency and transfer rules?

No. Pseudonymised data remains personal data under the GDPR and most comparable regimes, so moving it across borders is still a regulated transfer. Only genuinely anonymised, aggregate outputs generally fall outside these rules.

How does federation solve the residency problem?

In a federated model, each dataset stays on infrastructure inside its own jurisdiction, and approved computations are sent to it, returning only aggregate results. Because the data never crosses a border, residency and localisation rules are satisfied architecturally rather than through transfer agreements.

What does data residency have to do with Sovereign AI?

Sovereign AI means a nation retains control over the data, infrastructure, and models involved in its AI capability. Residency is its foundation: if health data is exported for training, sovereignty over the resulting models is lost. Federated training lets models learn from national data that never leaves national custody.

Can outputs and trained models violate residency rules?

Potentially, yes. Model weights and fine-grained outputs can encode personal information, so exporting them can amount to a data transfer. Well-governed environments apply disclosure control to outputs — reviewing what leaves, not just where the source data is stored.