Knowledge Base → Frameworks & law → 🌐 International Transfer & TIA Matrix (interactive)
🌐 International Transfer & TIA Matrix (interactive)
⚠️ Not legal advice — decision-support only. NOT LEGAL ADVICE. Simplified decision-support only. Verify every entry against current primary law and take qualified advice before relying on it for a specific transfer. Transfer law changes frequently; entries may be out of date.
As of 2026-09-07. Re-verify every entry against primary law. “Access = transfer” (EDPB Guidelines 05/2021); the exporter’s law sets the conditions and one flow can trigger several regimes at once. 🔶 = fast-moving, verify.
Pick an exporter (from) and a destination (to) for an at-a-glance transfer mechanism, plus the system-access (remote-admin) analysis — then read the full tables below. The data is maintained in the wiki kb:transfers matrix and regenerated on each site sync, so it stays current without touching this page.
Quick check
Indicative only — confirm against the tables below and primary law.
Table A — Exporter regimes (the “from” axis)
| Exporter | Model | Free to | Otherwise need | Assessment | Localisation | Ref |
|---|---|---|---|---|---|---|
| EU/EEA (GDPR Ch. V) | Adequacy + SCCs | EC adequacy list (incl. US via DPF) | SCCs 2021/914 · BCRs · Art. 49 | TIA (Schrems II) | No | ↗ |
| UK (UK GDPR) | Adequacy + IDTA | UK regs (≈EU + UK–US Data Bridge) | IDTA / EU SCCs+Addendum · BCRs · derogations | TRA | No | ↗ |
| Switzerland (revFADP) | Adequacy + CH-SCCs | FDPIC list + Swiss–US DPF | EU SCCs + FDPIC amend. · BCRs · derogations | TIA | No | ↗ |
| Brazil (LGPD) | Adequacy + SCCs | ANPD list (nascent) | ANPD SCCs · BCRs · specific clauses | — | No | ↗ |
| Canada (PIPEDA; Quebec Law 25) | Accountability | — | Comparable-protection contract; org stays accountable. Quebec Law 25: privacy-impact assessment required before transferring PI outside Quebec | Assessment (Quebec PIA) | No | ↗ |
| China (PIPL) | Approval / mechanism | — | CAC security assessment / certification / standard contract (filing); separate consent + specific export notice; 2024 exemptions | PIPIA | Yes (CIIO, important data) | ↗ |
| India (DPDPA + DPDP Rules 2025) 🔶 | Negative list | All (none restricted yet) | Valid contract between fiduciary/processor; govt may blacklist; fully operational ~mid-2027 | — | Sectoral (RBI payments) | ↗ |
| Indonesia (PDP Law 27/2022) 🔶 | Tiered | Equal-or-higher protection | Else binding safeguards; else consent; implementing GR pending; extraterritorial effect | — | Sectoral (public / electronic-system data, GR 71/2019) | ↗ |
| Japan (APPI) | Adequacy-equiv. | Japan list (EEA, UK) | Consent / equivalent-measures contract + oversight | — | No | ↗ |
| Malaysia (PDPA amended 2024/25) | Comparable-protection + TIA | — | TIA (substantially similar/adequate); SCC/BCR/cert; consent/contract; 5-day notice | Yes (TIA) | No | ↗ |
| South Korea (PIPA 2023) | Consent + alternatives | EU (PIPC-recognised equivalent, Sep 2025) | Consent / contract+safeguards+notice / PIPC-cert / PIPC-recognised country; SCC/BCR + Overseas-Transfer Impact Assessment planned H1 2026 | Impact-type | No | ↗ |
| Taiwan (PDPA amended Nov 2025 → PDPC) 🔶 | Permitted unless restricted | — | No dedicated cross-border-transfer statute yet; PDPC may restrict (Art. 21); sector/national-security bans emerging (e.g. PII to China/HK/Macao); assertive enforcement | — | Sector | ↗ |
| UAE (Federal PDPL 45/2021 + DIFC/ADGM) 🔶 | Adequacy + mechanisms (fragmented) | Federal list pending; DIFC/ADGM own lists | Federal: adequate country / contract / consent / necessity (regs not gazetted); health data generally must stay in UAE absent approval; financial-sector controls. DIFC & ADGM: GDPR-like + own SCCs | DIFC/ADGM yes | Health data + free-zone/sector | ↗ |
| Australia (APP 8) | Accountability | — | Reasonable steps + comparable protection (exporter stays liable, incl. intra-group); exception if recipient under substantially-similar law/binding scheme/BCRs; or consent | Reasonable-steps | Health/sector | ↗ |
| Russia | Localisation | — | Roskomnadzor consent/registration; strict | — | Yes (citizens' data) | |
| Singapore (PDPA s.26) | Comparable-protection + accountability | — (no whitelist) | Recipient bound by legally enforceable obligations (contract/BCR/APEC-CBPR cert) ensuring comparable protection; or consent; or contract necessity; or data in transit/public | Comparable-protection assessment | No | ↗ |
| South Africa (POPIA s.72) | Adequacy-or-safeguards + accountability | — (responsible party assesses adequacy) | Recipient bound by law/BCR/agreement with adequate protection + onward-transfer limits; or consent; or contract necessity/benefit | Adequacy assessment | No | ↗ |
| Turkey (KVKK Art. 9, amended Jun 2024) | Adequacy + safeguards (GDPR-aligned) | Board adequacy decisions (list nascent) | Board standard contract (notify Board <=5 business days) / BCRs / int'l agreement / undertaking+authorisation; explicit-consent & other derogations for one-off | Adequacy/safeguards assessment | No | ↗ |
| Costa Rica (Law 8968; reform Bill 23097) 🔶 | Consent-based + adequate-protection | — (no whitelist) | Data-subject consent; transfer to non-adequate country without valid derogation = very serious offence; guarantee adequate protection; GDPR-aligned reform (Bill 23097) pending | Adequacy/consent check | No | ↗ |
| Most other countries | Light / none | — | Often consent/contract or no restriction | — | Varies |
Table B — Personal-data transfer, destination buckets — from an EU/EEA exporter (UK/CH ≈ same)
Tables B and C are the EU/EEA-EXPORTER view (Table B = EU/EEA as data exporter; Table C = EU/EEA as the source/origin of the remote access). UK and Switzerland are broadly equivalent. For any other exporter, that exporter's own regime governs — see Table A.
| Bucket | Countries | Adequate? | Mechanism | Verdict |
|---|---|---|---|---|
| Adequate → free | United Kingdom, Switzerland, Japan, South Korea, Canada (commercial), New Zealand, Israel, Argentina, Uruguay, Andorra, Faroe Islands, Guernsey, Isle of Man, Jersey | yes | None (adequacy) | Free transfer |
| US — DPF-certified 🔶 | United States (DPF-certified importer) | partial | Data Privacy Framework | OK if importer is DPF-certified (verify scope) |
| Mechanism-achievable (SCC + TIA) | Australia, Taiwan, United Arab Emirates (DIFC/ADGM), Malaysia, Indonesia, Brazil, Singapore, South Africa, Turkey, Costa Rica, most Latin America / SE Asia (moderate risk) | no | SCCs + TIA (+ measures as risk dictates) | OK, case-by-case after TIA |
| High-risk / broad state access | United States (non-DPF), China, Russia, India | no | SCCs + TIA + strong supplementary measures, or local mechanism | Problematic — robust measures or do not transfer |
| Localisation / approval | China (CIIO / important data), Russia, Indonesia (sectoral), India (sectoral) | no | Local pre-clearance (e.g. CAC) + export mechanism | Restricted — local approval needed |
| No mechanism available | no | Art. 49 derogation (consent, contract necessity, legal claims) | Occasional / one-off only — not for routine flows |
Table C — System access (remote admin) — EU/EEA as exporter / source of the remote access; mitigation lens
Does the third-country admin need to see PLAINTEXT personal data?
| Situation | Mitigations | Residual risk | Verdict |
|---|---|---|---|
| Adequate destination | n/a | Low | Free — normal access controls |
| Non-adequate; importer sees only ciphertext/pseudonymised, keys held in exporter country | Strong encryption (exporter-held keys), pseudonymisation, no-download, JIT/ephemeral access, logging | Neutralised (EDPB Rec 01/2020 UC 1–3) | OK |
| Non-adequate; importer needs plaintext | Access controls help but do not neutralise | Medium | Case-by-case (per destination risk) |
| High-risk destination; plaintext admin | Encryption fails if cleartext needed (EDPB UC 6/7) | High | Avoid — encrypted-only ops or relocate access |
| High-risk destination; encrypted-only ops | E2E encryption + exporter-held keys + confidential computing | Low / neutralised | OK if admin never needs cleartext |
| Localisation regime | — | — | Local rules govern even remote access |
Table D — System support out of India — India as source of remote support
India as the LOCATION of the remote support/access, supporting a controller elsewhere (e.g. an EU/EEA exporter). If Indian staff can reach personal data, that access is a transfer to India (EDPB 05/2021). India (DPDPA) does not restrict inbound access, but the Indian entity is usually a processor/data-fiduciary with contract & security duties; India is not EU-adequate (broad state access -> factor into the TIA). RBI payment-data localisation applies if payment data is in scope.
| Support scenario | Transfer? | EU-exporter mechanism | India-side (DPDPA) | Mitigations / notes | Verdict |
|---|---|---|---|---|---|
| No access to personal data (infra/OS/network only, or ciphertext-only with keys held outside India) | No personal-data transfer | None (Ch. V not triggered) | Contract + security good practice | RBAC; encryption with keys outside India; no-download; screen-only/JIT; logging; beware PII in metadata/config/logs/tickets | OK — document the no-PII scoping |
| Possible / incidental access (admin could technically reach PII; break-glass only) | Treat as a transfer (mere possibility of access can count) | SCCs + TIA — or neutralise the access | Processor contract (DPDPA); security | Prefer to eliminate access (encryption + keys outside India -> back to row 1); else SCC+TIA + measures | SCC+TIA, or neutralise |
| Actual access to personal data (plaintext) — L2/L3 support, data fixes, content ops | Yes — transfer to India | SCCs + TIA + supplementary measures | Valid processor contract required (DPDPA); security safeguards; breach cooperation; onward transfer follows DPDPA negative-list | Encryption cannot neutralise plaintext (EDPB UC 6/7); minimise/pseudonymise; heightened scrutiny for sensitive/large-scale; consider EU-side handling for sensitive data | SCC+TIA + measures; high scrutiny |
Table E — US DOJ Data Security Program (EO 14117) — US-outbound bulk-sensitive-data export control 🔶
US-outbound national-security control (28 CFR Part 202; EO 14117; final rule effective 8 Apr 2025, affirmative compliance from 6 Oct 2025, reporting/enforcement phasing through 2026). Separate from the privacy/adequacy analysis; turns on the RECIPIENT being a country of concern (China incl. HK/Macau, Cuba, Iran, North Korea, Russia, Venezuela) or a covered person (entities >=50% owned by/organised in a CoC; their employees/contractors; individuals resident in a CoC). Covers bulk US sensitive personal data (genomic/omic, biometric, precise geolocation, health, financial, identifiers) and US government-related data (any volume). Cross-link: offshoring to India (Table D) is not a CoC, but a support provider that is a covered person can trigger this.
| Scenario | DSP category | Outcome | What's required | Notes |
|---|---|---|---|---|
| Data brokerage / sale of bulk US sensitive personal data to a CoC or covered person | Prohibited | Prohibited | — (not permitted) | Core prohibition; incl. onward-transfer & knowingly directing |
| US government-related data (precise geolocation of sensitive gov sites; gov/military personnel data) to CoC/covered person | Prohibited | Prohibited — any volume | — | No bulk threshold |
| Human genomic / 'omic / biospecimen data to CoC/covered person | Prohibited | Prohibited | — | Lowest thresholds; especially sensitive |
| Vendor / employment / investment agreement giving a covered person access to bulk US sensitive data (e.g. offshore support/dev team that is a covered person) | Restricted | Allowed only if compliant | CISA security requirements + data-compliance program + due diligence + annual audit + (2026) reporting | The key offshoring case — access = a covered data transaction |
| Below bulk threshold, rule-compliant de-identification, or an exempt transaction (intra-corporate group, financial services, telecom, US-gov, FDA/clinical) | Out of scope / exempt | No DSP restriction | Document the exemption/threshold | Still check other laws (privacy, export controls) |
Table F — Health & special-category data — overlay on Tables A–C
Health data is special-category (GDPR Art. 9). A cross-border transfer must satisfy an Art. 9(2) condition ON TOP of the Chapter V mechanism (and an Art. 6 basis), and the TIA must weight it as sensitive: plaintext exposure to a high-risk state generally cannot be neutralised by encryption (EDPB Rec 01/2020 UC 6/7). Watch EU secondary-use rules (EHDS) and national health-hosting regimes (e.g. FR HDS) that can require EU/EEA hosting.
Cross-cutting frameworks
| Topic | Rule / effect on transfers | Ref |
|---|---|---|
| GDPR Art. 9 — special category + stacking | Health data is special-category; needs an Art. 9(2) condition IN ADDITION to an Art. 6 basis and a Chapter V transfer tool — the transfer mechanism does not itself legitimise the sensitive-data processing. | ↗ |
| GDPR Art. 9(4) — national add-ons | Member States may keep or introduce further conditions or limits on health, genetic and biometric data — the hook for the divergent national hosting / localisation rules below. | ↗ |
| EDPB Rec 01/2020 — encryption is no cure for plaintext | Storage-only encryption / pseudonymisation (UC 1-3) can be effective supplementary measures, but transfer to a processor in a high-risk state that needs data in the clear (UC 6/7) has no effective technical measure — unencrypted health data so exposed cannot be rescued. | ↗ |
| EHDS — Regulation (EU) 2025/327 🔶 | In force 26 Mar 2025 (primary-use from 2027, most secondary-use from 2029). Targeted localisation, not blanket EU-only: secondary-use analysis must occur in an HDAB-controlled secure processing environment (Art. 73); third countries join the HealthData@EU infrastructure only from 2035 on equivalence. Member States may additionally require primary-use EHR data to be stored in the EU. | ↗ |
| France — HDS + SecNumCloud / cloud au centre 🔶 | Hosting others' patient data requires HDS certification (CSP Art. L.1111-8). State doctrine ('cloud au centre') requires particularly sensitive State/public-sector data on ANSSI SecNumCloud-qualified cloud. Health Data Hub is mid-migration from Azure to Scaleway (target end-2026/2027). | ↗ |
| Germany — 203 StGB + Land / church laws | Medical secrecy; the 2017 amendment permits disclosure to external IT/cloud providers under confidentiality conditions. PUBLIC hospitals are additionally bound by Land hospital laws (Landeskrankenhausgesetze); confessional hospitals by church data-protection law (KDG / DSG-EKD). | ↗ |
| US — HIPAA / HITECH + EO 14117 🔶 | HIPAA imposes NO data-localisation; PHI may go offshore with Security-Rule safeguards plus a Business Associate Agreement. Overlaid by the DOJ Data Security Program (EO 14117; 28 CFR Part 202) restricting bulk health and human-genomic data to countries of concern; enforcement ramps up 6 Oct 2026. | ↗ |
| China — PIPL + Human Genetic Resources 🔶 | Medical/health and genetic data are sensitive PI under PIPL (separate consent + a CAC export route). Human genetic resources (biospecimens + genomic data) are separately gated by the HGR Regulation (MOST/HGRAC approval); HGR approval does NOT replace PIPL export compliance. | ↗ |
Per-regime health specifics (“Public-body extras” = where public vs private hospitals diverge)
Public vs private hospitals diverge where public bodies face sovereignty/procurement rules or public-sector localisation that private providers escape: FR SecNumCloud / "cloud au centre" for the State/public sector, German Land hospital laws (+ church data-protection law for confessional hospitals), and public-scope localisation (Indonesia GR 71/2019, Russia public bodies, EHDS Health Data Access Bodies). UAE, Australia (MHR), Russia, China and US HIPAA/EO 14117 apply by data type / actor role regardless of public vs private status.
| Regime | Health-data specifics | Health localisation | Public-body extras |
|---|---|---|---|
| EU/EEA 🔶 | Art. 9(2) condition required on top of the Ch. V mechanism. EHDS routes secondary-use processing into HDAB-controlled secure environments; Member States may add Art. 9(4) conditions and optional EHR storage-in-EU. | EHDS secondary-use (secure processing env.); optional national EHR storage-in-EU | Public health bodies / Health Data Access Bodies carry the EHDS secure-processing duties; national sovereign-cloud rules may apply. |
| UK | Health = special category (UK GDPR Art. 9): Art. 9 condition + transfer tool. No statutory health localisation, but NHS data-security (DSPT) and residency expectations bite in practice. | No (NHS residency expectations in practice) | NHS bodies: DSPT + procurement / residency expectations. |
| Switzerland | Health = sensitive personal data (revFADP); transfer via adequacy / safeguards. No health-specific localisation. | No | — |
| Brazil | Health = sensitive (LGPD); transfer via ANPD adequacy or SCC-type safeguards. No localisation. | No | — |
| Canada / Québec 🔶 | No general health localisation, but Québec Law 25 requires a privacy-impact assessment BEFORE any transfer of PI outside Québec; the health-and-social-services-information regime adds sector constraints. | No (Québec PIA before export) | Public bodies + Québec health-info sector: extra residency / procurement constraints. |
| China 🔶 | Medical/health + genetic = sensitive PI (PIPL): separate consent + a CAC export route. Human genetic resources separately gated by the HGR Regulation (MOST/HGRAC approval) — which does not substitute for PIPL export compliance. | PIPL export route + HGR approval for genetic / biospecimen | — |
| India 🔶 | NO health localisation in the final DPDP Act / Rules 2025 (earlier drafts' sensitive-data localisation was dropped); conditional free-flow, Govt may blacklist countries by order. | No | — |
| Indonesia 🔶 | Health = specific personal data (PDP Law), tiered transfer regime. GR 71/2019 forces PUBLIC electronic-system operators to localise systems and data in Indonesia. | Public-sector (GR 71/2019) — catches state / public hospitals | State / public hospitals = public ESOs -> must localise in Indonesia; private hospitals may offshore. |
| Japan | Medical/health = requires-special-care personal information (APPI); transfer via adequacy / consent / equivalent-measures. No health localisation. | No | — |
| Malaysia | Health = sensitive personal data (PDPA); cross-border via TIA / comparable-protection routes. No health localisation. | No | — |
| South Korea | Health/medical = sensitive information (PIPA); transfer needs consent or another statutory basis. No health-specific localisation (Korea holds EU adequacy). | No | — |
| Taiwan 🔶 | Health = sensitive (PDPA); no dedicated cross-border statute yet, PDPC may restrict. No health-specific localisation. | No | — |
| UAE 🔶 | HARD health localisation: Federal Law 2/2019 (ICT in Health) Art. 13 — health data related to UAE health services may not be stored / processed / transferred outside the UAE absent Health-Authority approval. On top of PDPL / DIFC / ADGM. | Yes — health data must stay in UAE (Law 2/2019) | — |
| Australia | My Health Records Act 2012 s.77 — absolute ban on holding / processing My Health Record data (with identifying info) outside Australia (not waivable by consent). Other health data via APP 8. | Yes — My Health Record data must stay in Australia (s.77) | — |
| Russia | Law 152-FZ citizen-data localisation catches health (no carve-out): initial recording / storage / updating of Russian citizens' data must be in a database in Russia. | Yes (152-FZ — includes health) | — |
| Singapore | Health = personal data (PDPA s.26); transfer via comparable-protection routes. No health localisation. | No | — |
| South Africa | Health = special personal information (POPIA); transfer under s.72. No health localisation. | No | — |
| Turkey | Health = special-category (KVKK) with heightened conditions; cross-border via adequacy / standard-contract routes (2024 reform). No health localisation. | No | — |
| Costa Rica 🔶 | Health = sensitive (Law 8968); transfer needs consent / adequate protection. No health-specific localisation. | No | — |
| Most other countries | Health is 'sensitive' almost everywhere -> tighter conditions and often local approval; a few impose hard health/genomic localisation (e.g. UAE, Australia MHR) or sovereign-cloud rules. Verify per country. | Varies | Public bodies often face additional residency / procurement / sovereignty rules. |
Sources
- EC — adequacy decisions
- EC — EU–US DPF
- India — DPDP Rule 15
- Malaysia — CBDT guidelines 2025 (Mayer Brown)
- Indonesia — PDP Law transfers (Makarim)
- Taiwan — PDPA 2025 amendment
- UAE — PDPL (DLA Piper)
- DLA Piper — Data Protection Laws of the World
- Linklaters — Data Protected
- Chambers — Data Protection & Privacy 2026
- US DOJ NSD — Data Security Program (EO 14117)
- 28 CFR Part 202 (eCFR)
- EHDS — Regulation (EU) 2025/327
- EDPB Recommendations 01/2020 (supplementary measures)
- France — HDS hosting (CSP Art. L.1111-8, Légifrance)
- Germany — §203 StGB (professional secrecy)
- Australia — My Health Records Act 2012 (s.77)
- US HHS — HIPAA Business Associates