Data residency strategies for multi-country EDI

For an EDI hub operated in multiple jurisdictions, data residency is not an infrastructure detail: it is an architectural choice that drives cost, compliance, performance and future extension capability.

Why residency?

Three reasons motivate attention to data residency. (1) Legal obligation: some countries require that fiscal, banking or health data stay within borders (Russia, China, KSA, certain Brazilian states, sensitive sectors in France). (2) Transfer restrictions: since Schrems II (July 2020), transferring personal data from EU to US requires reinforced standard contractual clauses (SCC) and an impact assessment. (3) Performance: inter-regional latency can exceed 150-300 ms between continents, degrading the user experience of dashboards and synchronous APIs.

Legal framework 2026: overview

EU — GDPR: no residency restriction within EU/EEA. Non-EU transfers subject to adequate mechanism (adequacy decision, SCC, BCR, derogations).
EU → US — Data Privacy Framework: since July 2023, the DPF (successor of Privacy Shield, itself successor of Safe Harbor) allows transfers without SCC to certified US companies. Oversight by the DOJ Civil Rights Court. Legal stability still debated (Schrems III ongoing).
Switzerland — nLPD/FADP: new Swiss data protection law in force since 1 September 2023. Aligned with GDPR but Switzerland-US adequacy still under assessment.
United Kingdom — UK GDPR: post-Brexit continuation of GDPR. EU-UK transfers under 2021 adequacy decision (valid until June 2025 then renewed).
Brazil — LGPD: General Data Protection Law in force since 2020. No strict residency requirement but transfers require legal basis equivalent to GDPR.
China — PIPL: Personal Information Protection Law in force since November 2021. Strict residency requirements for "important data" and large-scale personal data. Mandatory CAC review for transfers.
Saudi Arabia — PDPL: Personal Data Protection Law September 2023. Residency requirements being progressively applied.
India — DPDP Act 2023: Digital Personal Data Protection Act. Allows transfers except to blacklisted countries published by the government (list not yet published mid-2026).

Four architecture models

Model 1: regional deployment (data stays in region)

One hub instance per jurisdiction: EU in Frankfurt/Dublin, US in Virginia/Oregon, APAC in Singapore/Tokyo. Each instance operates independently, with its own database, storage, ops team if needed. Data never leaves the region.

Pros: maximum residential compliance, low latency for regional partners, incident isolation. Cons: high cost (multiplied stacks), operational complexity (coordinated updates), complex global reporting (need for separate aggregation).

Model 2: hybrid with regional data plane, central control plane

Payloads and operational data stay in region (data plane), but configuration, aggregated monitoring, global dashboards go through a centralised control plane (typically in EU or Switzerland for European groups).

Pros: good residential compliance (business data stays localised), simplified operations (single control plane), native global reporting. Cons: metadata (who did what, when) transits via the central node and may count as personal data in some jurisdictions; case-by-case analysis needed.

Model 3: central deployment with localised access controls

Everything centralised (typically in EU), with technical controls preventing non-European employees from accessing European data (RBAC + jump server + audit). Adequate only for countries without strict residency requirement (EU among Member States, or non-EU with adequacy decision).

Pros: optimal cost, simple operations. Cons: impossible for China, Russia, KSA. Risk on intra-group transfers (SCC or BCR to set up).

Model 4: sovereign cloud per sensitive jurisdiction

For highly regulated sectors (defence, certain parts of health, certain public data), deployment on dedicated sovereign cloud: SecNumCloud in France (OVHcloud, Numspot, Bleu), C5-labelled data centres in Germany (T-Systems), G-Cloud in UK. Hyperscalers propose aligned offers (AWS Sovereign Cloud announced 2024, Microsoft Cloud for Sovereignty, Google Sovereign Solutions).

Pros: maximum compliance, isolation from US CLOUD Act. Cons: significantly higher cost, reduced service ecosystem vs classical hyperscaler, slower evolution.

Sovereign cloud and GAIA-X

GAIA-X (Franco-German initiative launched 2019, Belgian AISBL since 2021) aims to federate a European cloud ecosystem compliant with European values (transparency, sovereignty, interoperability). In 2026, GAIA-X mainly provides a labels and standard contract framework, but few direct operational offers. SecNumCloud (French ANSSI label) is more structuring for French regulated sectors: OVHcloud, Numspot, S3NS, Outscale, Bleu (Microsoft- Capgemini-Orange offer under French sovereignty) are notable operators.

For an EDI hub serving French public clients or vital importance operators (OIV), operating on SecNumCloud infrastructure becomes a commercial prerequisite for many from 2026.

Decision matrix: which model to choose?

EU-only greenfield hub, standard B2B retail: model 3 central EU (Frankfurt or Paris), granular access control per employee.
EU + US hub, retail/manufacturing sector: model 2 hybrid (data plane per region, control plane EU) with DPF for metadata transfers.
Multinational hub including China/Russia/KSA: model 1 strict regional, no choice.
Hub serving French public sector or OIV: model 4 sovereign cloud, SecNumCloud label, exclusion of non-European infrastructure.
Multi-country European health hub: model 2 hybrid, hosts FHIR Bundles per country, aggregated metadata on EU central compliant with EHDS (European Health Data Space, Regulation 2024/1306).

Foundations

Standards

Flagship messages

Tools