Why Data Residency Now Defines Global Pharma Architecture

For most of the last decade, pharma cloud strategies were shaped by a fairly narrow set of variables: HIPAA business associate agreements in the US, GDPR safeguards in Europe, and a handful of regional preferences from specific health authorities. Global teams generally assumed that if the primary cloud region was hosted somewhere in the EU or the US, and if the right encryption and access controls were in place, most local requirements could be satisfied through contractual mechanisms and Standard Contractual Clauses.

That assumption is no longer safe. Between 2023 and 2026, a series of independent regulatory movements has converged to make where data physically sits a first-order design decision. The European Union’s Data Act became generally applicable on September 12, 2025, adding switching and interoperability obligations to the existing GDPR baseline.1 China’s Cyberspace Administration and State Administration for Market Regulation jointly issued new Cross-Border Personal Information Transfer Certification Measures that take effect January 1, 2026, layering a third pathway on top of the existing security assessment and standard contract regimes.2 In the United States, Washington’s My Health My Data Act came into force in 2024 and pharmaceutical companies have been explicitly named as likely first targets of enforcement.3

None of these developments individually would force a rearchitecture. Taken together, they have shifted the question a pharma CIO or Chief Data Officer is asking. It used to be: “Can we keep this data in one global instance and address local requirements through policy?” It is now: “Which data classes must be resident where, which can move under which safeguards, and what does that mean for our clinical, safety, and RWD platforms?”

33
AWS regions globally as of 2026, with a dedicated European Sovereign Cloud scheduled to launch by year-end4
2,800+
organizations certified under the EU-US Data Privacy Framework as of mid-20265
Jan 2026
effective date of China’s new PIPL cross-border certification measures for personal information transfers2

What the industry has learned the hard way

Several public disputes over the past three years have made the stakes visible. The unresolved tension between GDPR transfer requirements and the US CLOUD Act has repeatedly surfaced in European hospital and biotech procurement decisions, where the possibility that a US-headquartered cloud provider could be compelled to produce EU data has led some public health systems to require in-region processing with customer-managed keys.1 China’s tightening of Human Genetic Resources oversight has created explicit friction points for multinational sponsors running trials with Chinese sites, and while May 2026 draft revisions suggest a partial shift toward ethics-committee oversight for lower-risk research, the export of pseudonymized trial data still requires deliberate legal design.2

The practical takeaway for architecture teams is that residency requirements now function as a constraint on system design in the same way that GxP requirements have for decades. A commercial launch plan for a therapy that will be sold in Europe, the US, and multiple APAC markets should include a residency map before it includes a cloud vendor selection.

European Union: GDPR, the Data Act, and the EHDS Stack

The EU is the most mature and, in some ways, the most stable environment for a pharma data residency strategy. GDPR remains the horizontal baseline, and it does not by itself impose data localization: personal data can leave the EEA if a valid transfer mechanism is in place. What has changed since 2023 is that the surrounding stack of health-specific and cloud-specific rules has grown considerably, and the political pressure to keep sensitive health data physically resident in Europe has increased.

The core baseline: GDPR and the DPF

The EU-US Data Privacy Framework, adopted July 2023, provides an adequacy pathway for transfers to certified US organizations. The framework covers key-coded (pseudonymized) clinical trial data even where the key is held only by the EU sponsor.5 In September 2025 the EU General Court dismissed an action for annulment, but an appeal was filed at the Court of Justice as Case C-703/25 P and is pending, so certification under the DPF is currently the operative mechanism but not one that any prudent pharma should treat as permanent.5

The Data Act’s cloud switching obligations

The EU Data Act came into force on January 11, 2024, and became generally applicable on September 12, 2025. For life sciences, the most operationally significant provisions concern cloud service switching: providers must remove technical, contractual, and economic barriers to moving data between cloud services, and must support functional equivalence and data portability.1 This has a direct effect on pharma platform strategy because it makes multi-cloud portability a right rather than a negotiation, but it also means data architectures that rely on proprietary formats or heavy provider lock-in will need to be revisited.

The European Health Data Space

The European Health Data Space Regulation entered into force in March 2025, creating a framework for both primary and secondary use of health data. Most secondary-use provisions apply from 2029, and those specifically addressing clinical trial data and human genetic data apply from 2031.6 The residency implication is that EHDS envisages a network of Health Data Access Bodies operating within Member States, which in practice pushes toward architectures that can support in-region processing and controlled access rather than bulk data transfer.

Clinical trials under CTR and CTIS

Since January 2025, all clinical trials in the EU must operate under the Clinical Trials Regulation and submit through the Clinical Trials Information System (CTIS), the centralized portal managed by the EMA. CTIS is EU-hosted, but sponsors retain their own trial master files, safety databases, and analytics platforms, which may sit elsewhere. The residency question falls on those sponsor systems, not on CTIS itself.

United States: HIPAA, State Health Privacy Laws, and CIRCIA

The US remains a jurisdiction without a comprehensive federal privacy law, but the practical picture for pharma has grown considerably more complex because of state health-specific statutes and a new federal cyber incident reporting regime under CIRCIA.

HIPAA and its limits

HIPAA remains the anchor. Cloud providers that store or maintain electronic protected health information are business associates and must comply with the HIPAA Security Rule, which imposes administrative, physical, and technical safeguards.7 HIPAA itself does not require US residency; it requires that PHI be protected wherever it is processed. The practical constraint is that most covered entity partners and hospital systems require US-region processing under their business associate agreements, and that expectation flows through to CROs and pharma sponsors handling identifiable data.

State laws that reach further than HIPAA

Washington’s My Health My Data Act, effective March 2024 for larger regulated entities, covers consumer health data that falls outside HIPAA. Pharmaceutical companies have been explicitly identified as likely first targets of enforcement, with plaintiff firms already recruiting individuals who visited pharma company websites for potential litigation.3 The Act deems any violation an unfair or deceptive act and creates a private right of action with treble damages up to $25,000 per violation.3 California’s CMIA and CPRA reach similar territory from different angles, and Nevada, Connecticut, and Colorado have all layered on additional health data protections.8

CIRCIA and the 72-hour clock

The Cyber Incident Reporting for Critical Infrastructure Act requires covered entities to report substantial cyber incidents to CISA within 72 hours and ransomware payments within 24 hours. Pharmaceutical companies, medical device manufacturers, and healthcare providers all qualify as covered entities under the Healthcare and Public Health sector.9 As of mid-2026 the final rule remains pending after CISA’s town-hall consultations, but the core reporting obligations are not expected to change.9 CIRCIA does not itself impose residency, but its logging, monitoring, and audit requirements make cloud regions with strong observability tooling and CISA-recognized incident response support materially easier to operate.

The state law patchwork is not going away. Federal preemption of state health data laws has been discussed for years and has not materialized. Any residency strategy that assumes a single US-region footprint will satisfy every state requirement is exposed. Where the risk is highest, in direct-to-consumer digital health and marketing analytics, treating Washington, California, and a handful of other states as separate policy domains is prudent even where the underlying storage is consolidated.

United Kingdom: UK GDPR, DSPT, and Post-Brexit Divergence

The United Kingdom retained a version of GDPR after Brexit, and while the substance remains very close to the EU regime, the transfer landscape has diverged. UK GDPR governs personal data processed in the UK, and international transfers require either an adequacy determination, an International Data Transfer Agreement (IDTA), the UK Addendum to EU Standard Contractual Clauses, or Binding Corporate Rules.10 The UK issued its own adequacy decision regarding the US in 2023 that operates in parallel to the EU DPF and covers transfers to UK Extension participants.

NHS Data Security and Protection Toolkit

Any organization that accesses NHS patient data or systems must complete the NHS Data Security and Protection Toolkit, which sets ten data security standards covering leadership, staff responsibilities, training, managing data, process reviews, responding to incidents, continuity planning, unsupported systems, IT protection, and accountable suppliers.10 For a pharma sponsor running trials with UK NHS sites, this toolkit shapes the practical residency conversation: NHS trusts typically expect UK or EU processing, and specifically will want reassurance about how CLOUD Act exposure and US-headquartered provider access are addressed.

Clinical trial data under UK GDPR

UK GDPR provides derogations for scientific research purposes but requires appropriate safeguards including data minimization, pseudonymization, and defined retention. Sponsors conducting UK trials also fall under MHRA oversight and must maintain trial records in accordance with UK GCP. Where UK trial data is transferred to a sponsor operation in the US, EU, or elsewhere, an IDTA or the UK Addendum is the operative safeguard.10

APAC Markets: China, Japan, Korea, Singapore, India

APAC is the most fragmented region for pharma residency planning. Every major market has its own regime, several have added new mechanisms or tightened existing ones in the past 18 months, and the sector-specific overlays (particularly around human genetic resources and clinical trial data) mean that generic privacy compliance is not sufficient.

China: PIPL, CSL, and Human Genetic Resources

China operates the most restrictive cross-border regime among major pharma markets. Under PIPL Article 38, personal information processors have three pathways for transferring personal information abroad: pass a CAC-led security assessment, obtain certification from an approved institution, or sign a CAC standard contract with the foreign recipient.2 The new Cross-Border Personal Information Transfer Certification Measures, jointly issued by the CAC and SAMR on October 14, 2025 and effective January 1, 2026, formalize the certification pathway and are expected to become the preferred route for many multinationals given its lower friction relative to the full security assessment.2

Sitting on top of PIPL, the Human Genetic Resources Regulations require dedicated approvals for the export of biological samples and associated genetic data from Chinese subjects. May 2026 draft revisions signal a partial shift from centralized pre-approval toward ethics-committee oversight for lower-risk research, but multinational sponsors running trials with Chinese sites should still design architectures that keep primary trial data resident in China with controlled export of pseudonymized subsets under one of the PIPL pathways.11

Japan: APPI and adequacy with EU and UK

Japan’s amended Act on the Protection of Personal Information requires consent for cross-border transfers of personal data unless the destination country ensures equivalent protection or the organization implements necessary measures. When cross-border transfer is based on consent, information about the data protection regime of the recipient country must be disclosed to data subjects.12 Japan holds an EU adequacy decision from 2019 and a UK adequacy decision, so transfers from Japan to those jurisdictions are relatively unencumbered. Transfers to the US require additional safeguards.

South Korea: PIPA and its 2026 amendments

PIPA remains the horizontal Korean privacy law, and Article 17 continues to govern third-party provision including overseas transfers. Recent amendments have expanded lawful bases while tightening accountability, and platforms must obtain consent for third-party provision or rely on a lawful basis and notify customers about overseas transfers.13 Korea holds an EU adequacy decision (since 2021), which simplifies EU-Korea flows but not US-Korea flows. Korea also has a series of sector-specific rules on medical records and clinical trial data that overlay PIPA.

Singapore: PDPA as a hub anchor

Singapore’s Personal Data Protection Act Section 26 restricts cross-border transfers unless the organization ensures that the receiving party provides a standard of protection comparable to the PDPA. “Comparable” does not mean identical, and the most commonly used mechanism is a legally binding agreement with the overseas recipient.14 Singapore’s role as an APAC regional hub for many pharma companies makes PDPA compliance a practical foundation for hub-and-spoke architectures serving the region.

India: DPDP Act 2023 and sectoral overlays

India’s Digital Personal Data Protection Act, 2023 adopts a negative-list approach under Section 16: cross-border transfers are permitted by default unless the Central Government specifically restricts transfers to certain countries. As of mid-2026, no restricted-country list has been notified, so transfers are broadly allowed.15 Where DPDP is more permissive than expected, sectoral laws are stricter. The RBI’s 2018 payment data localization directive, SEBI and IRDAI requirements, and DPDP Rules 2025 continue to apply, and pharma operations that touch payment data (patient support programs with direct financial elements) or that use insurance-linked data may face stricter localization than the DPDP baseline would suggest.15

Latin America: Brazil’s LGPD and the Sensitive Health Data Threshold

Brazil’s Lei Geral de Proteção de Dados (LGPD) closely mirrors GDPR structurally but treats health data as a sensitive category with stricter parameters. The LGPD prohibits the communication or shared use between controllers of sensitive personal data relating to health with the aim of obtaining economic advantage, though sharing is permitted for the provision of health services, pharmaceutical assistance, and healthcare purposes.16 International transfers require one of several mechanisms including adequacy decisions from Brazil’s ANPD (currently limited), Standard Contractual Clauses, Binding Corporate Rules, or specific safeguards.16

For pharma companies conducting clinical trials in Brazil, personal data flows to and from institutions, investigators, and sponsors require written agreements covering collection, processing, and transfer. The strict health data provisions mean that pooling Brazilian trial data with global datasets for commercial or analytic purposes outside the immediate healthcare delivery context requires deliberate legal design and, in practice, often pushes toward in-country processing with tightly controlled export.16

Country-by-Country Requirements Comparison

The table below condenses the current state of the requirements across nine major pharma markets as of mid-2026. It is intended as a starting point for architecture and program teams, not a substitute for jurisdiction-specific legal review.

Jurisdiction Primary Law(s) Cross-Border Mechanism Health-Data Specifics Residency Bias
European Union GDPR, Data Act, EHDS, CTR Adequacy, SCCs, BCRs, DPF (for US) Health data is a special category; EHDS applies from 2029/2031 Strong in-EU preference; increasing pressure on US-headquartered clouds
United States HIPAA, WA MHMDA, CA CMIA/CPRA, CIRCIA No general restriction; HIPAA governs PHI State health laws expand beyond HIPAA; consumer health data covered separately US-region preferred by covered entities; state variation matters
United Kingdom UK GDPR, DPA 2018, NHS DSPT Adequacy, IDTA, UK Addendum, BCRs DSPT for NHS-connected systems; UK CTR aligns with EU CTR post-Brexit UK/EU preferred by NHS partners; US access a persistent concern
China PIPL, CSL, DSL, HGR Regs Security assessment, SCC, or certification (from Jan 2026) HGR export requires separate approval; sensitive PI has stricter thresholds Strong localization; in-China processing effectively required for trial data
Japan APPI Adequate country, consent, or contractual safeguards Medical Information Guidelines overlay APPI Local preference but permissive with adequacy or consent
South Korea PIPA Consent, contract, adequacy (EU 2021) Sector-specific rules on medical and clinical trial data Localization preferred; adequacy simplifies EU-Korea only
Singapore PDPA Comparable protection via contract or approved regime Healthcare Services Act overlays for licensed providers Hub-friendly; contractual mechanism widely used
India DPDP Act 2023, DPDP Rules 2025 Permitted except to notified restricted countries (none as of mid-2026) Sectoral rules (RBI, SEBI, IRDAI) can be stricter DPDP permissive; sectoral localization can force in-India
Brazil LGPD Adequacy (limited), SCCs, BCRs, specific safeguards Health data is sensitive; sharing for economic advantage restricted Strong preference for in-Brazil processing of trial data

A Cloud Region Selection Framework for Pharma

A defensible region selection process for a pharma workload should proceed through a small number of ordered decisions. The purpose of ordering them is to avoid the common failure mode of picking a region on cost or latency grounds and then discovering a residency conflict during regulatory review.

1

Classify the data

Identify what data classes the workload handles: identifiable patient data, pseudonymized trial data, adverse event reports, RWD from a specific market, human genetic material, commercial CRM data, or something else. Each class has different residency implications and often falls under different laws even in the same jurisdiction.

2

Determine residency constraints

For each data class, list the countries whose laws apply based on where the data subjects are, where processing happens, and where any local regulator has oversight. Note both hard constraints (Chinese HGR data must remain in China absent specific approval) and soft constraints (NHS-connected data is expected to remain in the UK or EU even where transfer is legally possible).

3

Screen candidate regions

Filter provider regions by whether they satisfy the residency constraints and whether the required certifications (HIPAA BAA, HDS in France, C5 in Germany, IRAP in Australia) are in scope for the workload.

4

Apply engineering criteria

Only after the residency and compliance screen, apply the traditional criteria: latency to user populations, service availability, pricing, and DR pairing. Region selection should follow data residency first, then latency, service availability, pricing, and DR pairing.17

5

Document the decision

For regulated systems, the residency decision itself is an artifact that regulators may inspect. Record the data classes, the constraints considered, the alternatives evaluated, and the rationale. This is the same discipline that applies to GxP decisions, and residency now warrants the same level of documentation.

Architectural Patterns: In-Region, Multi-Region, and Hybrid

Three broad architectural patterns handle most pharma residency requirements. Each has distinct trade-offs, and most large sponsors end up running some combination.

PATTERN 1

Single in-region deployment

All processing and storage happens in one cloud region within the target jurisdiction. Simplest to reason about and defend. Appropriate for country-specific systems: a Chinese EDC instance, a Japanese pharmacovigilance database, or a Brazilian patient support platform. Cost is manageable because there is no cross-region replication. Weakness is disaster recovery within the same jurisdictional envelope.

PATTERN 2

Regional silo, global control plane

Data processing is siloed within region while metadata, orchestration, and identity live in a global control plane. Effective for multi-country programs where local data must remain resident but consistent operational tooling is required. The control plane needs careful design to avoid inadvertently pulling regulated data into a non-compliant region.

PATTERN 3

Multi-region active-active

Sensitive data is siloed within region, but application services and analytics operate across regions with data-plane isolation. This is where separate databases per region and robust metadata tagging matter most, so that personal data can be found and deleted on request.17 Cost and operational complexity are highest; appropriate for global platforms serving multiple markets simultaneously.

PATTERN 4

Sovereign cloud with pooled analytics

Raw data remains in a sovereign cloud region (AWS European Sovereign Cloud, Bleu, Delos Cloud, T-Systems partnerships). Aggregated or pseudonymized derivatives are transferred to a global analytics environment under an appropriate mechanism. Emerging as the preferred pattern for European pharma facing CLOUD Act concerns.4

The Sakara Digital perspective

The pattern we see working best in practice is not any single one of these choices, but a deliberate mapping of data classes to patterns. A global sponsor may run pattern 4 for European identifiable trial data, pattern 1 for Chinese and Brazilian trial data, pattern 2 for global pharmacovigilance orchestration with region-siloed adverse event storage, and pattern 3 for commercial analytics. The mistake we see repeated is treating residency as a single architectural decision rather than a data-class-by-data-class decision. Once teams internalize that residency is a data model concern, the platform choices become considerably clearer.

Operational Implications for Trials, Safety, and RWD

Residency requirements bite differently across the main clinical and post-market data domains. Understanding the operational implications is what separates a paper compliance strategy from one that actually works.

Clinical trials: the sponsor’s global master file

Clinical trials generate data at investigator sites in specific jurisdictions, but sponsors need a consolidated view for safety monitoring, statistical analysis, and regulatory submission. The typical resolution is a two-tier architecture: site-level EDC and eSource systems remain in-region, while pseudonymized case report data flows to a sponsor’s global clinical data platform under appropriate transfer mechanisms. For Chinese sites, the pseudonymized transfer usually requires a PIPL certification or standard contract in addition to any HGR approval for genetic data.2 For EU sites, the transfer to a US sponsor typically relies on the DPF or SCCs, with the ongoing awareness that the DPF appeal at the CJEU introduces some residual uncertainty.5

Pharmacovigilance: the always-on obligation

Pharmacovigilance is one of the more residency-sensitive workloads because it must operate 24 hours a day, report to multiple regulators on statutory timelines, and often relies on a single global safety database. EMA requires electronic submission through EudraVigilance, with 15-day reporting for serious adverse events. FDA guidance under 21 CFR Part 310/314 focuses on adverse event reporting and signal detection with mandatory 15-day serious adverse event reporting for post-marketing products.18 Marketing authorization holders managing global products must integrate multiple PV systems and ensure the same adverse event data is consistently reported across EMA, USFDA, and MHRA systems.18 In practice, most sponsors run a global safety database with regional replicas that satisfy specific residency expectations while maintaining a single source of truth.

Real-world data: the highest-friction domain

RWD from claims, EHR, registries, and connected devices is where residency requirements bite hardest, because the source data is often subject to the strictest health-specific rules in each jurisdiction, and the analytic value depends on aggregation across markets. Despite regulatory bodies like FDA and EMA accepting RWD, achieving regulatory acceptance of real-world evidence poses challenges due to varying standards across regions, and each regulatory body has different expectations regarding data quality, methodology, and evidentiary thresholds.19 Strict data anonymization regulations in the EU make it challenging for researchers to access and use patient-level data efficiently, underscoring the necessity for global agreement on RWD in relation to data privacy.19

What good looks like in an RWD architecture. The pattern we see delivering value is a federated analytics model: raw patient-level data remains in the market where it originated, with aggregated statistics or de-identified derivatives moving to a global analytics environment. This preserves residency, satisfies most consent and use limitation obligations, and still supports cross-market signal detection and value evidence generation. It requires investment in federated tooling and rigorous metadata governance, but it survives regulatory scrutiny far better than the “pull everything into one warehouse” approach that was common a decade ago.

Incident response and regulator access

CIRCIA’s 72-hour reporting requirement in the US, EU regulators’ expectations under NIS2 for critical infrastructure operators, and equivalent regimes in the UK, Japan, and Singapore mean that a global pharma incident response capability must be able to identify affected data by jurisdiction quickly. That is a metadata problem, not a residency problem, but it is the metadata design that makes residency workable at scale.

Conclusion

Data residency has become one of the defining architectural constraints for global pharma, and the trajectory is toward more, not less, specificity. The EU stack, the US state law patchwork, China’s tightening cross-border regime, and the growing sophistication of health-data protections in APAC and Latin America together mean that a residency map is now a foundational deliverable for any global system launch. The good news is that the sovereign cloud offerings from major hyperscalers, the maturity of federated analytics tooling, and the growing clarity of the regulatory expectations make it possible to design architectures that are both compliant and useful. The bad news is that these are architecture decisions, not procurement decisions, and they warrant the same level of governance and documentation as any GxP-critical system choice.

Sakara Digital works with pharma and biotech organizations building this kind of residency-aware data architecture, from the initial classification exercise through cloud region selection, sovereign cloud evaluation, and the federated analytics patterns that make cross-market RWD programs work. If you are re-examining your global cloud strategy in light of the 2025-2026 regulatory shifts and want an independent perspective on where to start, we are happy to have that conversation.