Annex D — Sovereign Data Zone (SDZ) & Cross‑Border Transfers Policy

Global Baseline + Host‑Law Appendices
Owner: Data Protection Officer (DPO) and Chief Information Security Officer (CISO)
Review cadence: Annual and upon material law/regulatory change

Purpose. Guarantee lawful, resilient, and privacy‑preserving data operations by enforcing compute‑to‑data inside Sovereign Data Zones (SDZs), default in‑country residency, controlled cross‑border transfers (SCCs/IDTA/BCRs with TIAs), and emergency unilateral disconnect plus tested exit/escrow procedures. This Policy aligns with Annex B (Regulatory Perimeter) and Annex C (Data Protection & Privacy).

1) Scope & Equal‑Treatment Baseline

Applies equally to: all regional consortium operators (APAC, Middle East, East Africa, Southern Africa, EU/France, USA, Canada, Brazil/LatAm, Senegal/West Africa, Switzerland/GRF seat), all NatCos, Program SPVs, contractors, and sub‑processors. Where host law conflicts with this baseline, the strictest rule prevails.

2) Definitions

• SDZ (Sovereign Data Zone): A physically and logically bounded environment within host‑country jurisdiction where personal data (PD) and regulated datasets are processed under compute‑to‑data rules.
• Compute‑to‑Data: Moving algorithms/queries to data within the SDZ; no bulk extraction of raw PD.
• Transfer Tools: SCCs (EU), IDTA (UK), BCRs, adequacy, or equivalent; each with a documented Transfer Impact Assessment (TIA).
• Unilateral Disconnect: The right and capability to isolate links, integrations, or services that threaten sovereignty, privacy, or compliance.
• Exit/Escrow: Contracted mechanisms to provide customers with complete, usable exports and to ensure business continuity via code escrow and data escrow.

3) SDZ Architecture & Controls (Global Minimums)

1. Residency defaults: PD and regulated datasets reside in‑country within the SDZ. Cross‑border movement requires §6 approvals and tools.
2. Zones & classification:
   • SDZ‑P (Public), SDZ‑I (Internal), SDZ‑C (Confidential), SDZ‑R (Restricted‑PD/special categories) — handling rules escalate by tier.
3. Identity & access: Zero‑Trust IAM; least privilege; role + attribute‑based (ABAC) controls; MFA; break‑glass with dual approval; session recording for SDZ‑R.
4. Encryption & key custody: Encryption at rest/in transit; customer/PoR‑controlled KMS/HSM where possible (BYOK/HYOK); split‑knowledge; location‑pinned keys.
5. Network & runtime: Micro‑segmentation; private endpoints; allow‑listed egress; workload attestation (TEE/SEV/SGX where available); image signing; SBOM for every deploy; SLSA‑aligned CI/CD.
6. Data handling: PETs preferred (tokenisation, hashing, differential privacy, PSI); production PD never used in lower environments without masking/synthesis.
7. Logging & audit: Immutable, time‑synchronised logs; tamper‑evident digests; 7‑year minimum retention (or stricter per host law).
8. Third‑party access: Vendors operate inside the SDZ via isolated jump hosts; no persistent admin from outside jurisdiction without explicit approval and session capture.

4) Compute‑to‑Data Rules (Operate where the data lives)

• Bring code to data. Analytics, model training/validation, and joins run inside the SDZ using secured workbenches.
• No raw PD exports. Approved outputs are aggregated, anonymised or strongly pseudonymised with re‑identification risk analysis.
• Federated patterns: Use federated queries/learning across SDZs; share parameters/gradients, not raw PD.
• Data minimisation checks: Pre‑run checklists (fields, purpose, retention, recipients) must pass before any job executes.

5) Residency & Localisation (Decisioning)

• Default: Keep PD/regulated data in the host‑country SDZ.
• Residency Decision Record (RDR): For any exception, maintain an RDR documenting legal basis, necessity, alternatives considered, risk analysis, mitigation, and approvals.
• High‑risk data: Special categories, biometrics, children’s data, and law‑enforcement‑related data may not leave the SDZ absent (i) explicit law allowing it and (ii) DPO/GC approval with TIA.

6) Cross‑Border Transfers (When and How)

1. Allowable circumstances: Only when necessary for contract/performance, safety, support, or multi‑jurisdictional analytics and when lawful bases are met.
2. Tools: Adequacy → SCCs/IDTA → BCRs (if available); each with TIA assessing destination law/government access risks and technical measures (encryption, key residency).
3. Outbound PD from SDZ: Use strong encryption; keep keys in host jurisdiction; prefer pseudonymised data; limit fields; apply k‑anonymity for analytics outputs.
4. Onward transfers: Contractually prohibit onward transfers without equivalent protections and approvals.
5. Registers: Maintain a Cross‑Border Transfer Register listing dataset, purpose, tool, counterpart, TIAs, and expiry/review dates.

7) Unilateral Disconnect (Emergency Containment)

• Triggers: Suspected breach; vendor compromise; sudden legal change; extraterritorial access demands inconsistent with law; PoR failure; integrity loss; sanction/AML flags.
• Action: DPO/CISO (or delegate) authorises isolation within 2 hours where feasible: shut links, revoke tokens/credentials, disable routing, block egress, freeze jobs.
• Runbook: Use the SDZ Disconnect Runbook (contacts, steps, decision log, back‑out plan).
• Notice: Notify affected counterparties and, where required, authorities per Annex C clocks.
• Post‑mortem: Within 10 business days, complete root‑cause, corrective actions, and re‑authorise connections via change control.

8) Exit & Escrow (Continuity & Customer Portability)

1. Data Escrow: Quarterly exportable snapshots (schema‑stable, documented, hashed) held with an independent escrow agent or returned to customer on schedule.
2. Code Escrow: For critical components, maintain escrow with release conditions (vendor insolvency, prolonged SLA breach, regulator order). Test restores annually.
3. Exit Plan Checklist:
   • Confirm legal basis and customer identity.
   • Freeze writes; take final signed snapshot.
   • Deliver export in open formats with data dictionary + lineage.
   • Secure delete residual PD; verify via logs.
   • Revoke access/keys; document completion; dual‑log as Class B (or Class A if mass exit).

9) Change Management & Approvals

• Tickets required for: new datasets, new processors, new cross‑border paths, key‑management changes, new analytics patterns, or SDZ topology changes.
• Approvals: DPO for privacy; CISO for security; GC for legal tools/agreements.
• Class A approval required for weakening residency defaults or bypassing compute‑to‑data; Class B for strengthening/clarifications.

10) Monitoring, Testing & Assurance

• Continuous controls monitoring: IAM drift, egress anomalies, key misuse, unenforced policies.
• Drills:
  • Quarterly: Disconnect drill; cross‑border failover (paper or live as feasible).
  • Annual: Full exit/restore test from escrow; penetration test of SDZ perimeter; TIA refresh.
• Attestations: SBOM coverage 100% for SDZ workloads; SLSA level targets; audit trails exported to independent archive.

11) Vendor & Cloud Requirements

• Residency commitments in contract; named hosting regions; no silent data replication outside jurisdiction.
• Support access controls: Localised support; JIT access; session capture; privacy screens.
• Law‑enforcement request handling: Vendor must notify (to the extent lawful) and challenge overbroad requests; use transparency reports.
• Sub‑processor flows: Prior approval; DPAs with equivalent SDZ clauses; right to audit.

12) Records & Evidence Packs

Maintain: SDZ topology diagrams, RDRs, TIAs, DPA/SCC/IDTA copies, key‑management SOPs, disconnect runbooks, exit test reports, audit logs, and escrow certificates. Link each to the program’s Assurance & Evidence Pack (AEP).

13) Host‑Law Appendices (Equal Treatment)

These appendices supplement the baseline with local rules and authorities. Apply the strictest requirements where conflicts arise.

• Appendix SG — Singapore: PDPA cross‑border rules; PDPC guidance; MAS technology risk guidelines for PoR; default no DPT/keys under SNC custody; ≥90‑day publication lag for market‑sensitive analytics.
• Appendix EU/FR — European Union/France: GDPR Ch.V transfers; EDPB TIAs; Schrems II technical measures; CNIL guidance; Data Act/data‑localisation interplay; eIDAS/eID rules.
• Appendix CH — Switzerland: nFADP transfers (FDPIC); Swiss SCC variants; data residency expectations for sensitive PD.
• Appendix US — United States: State privacy (CCPA/CPRA etc.), GLBA/HIPAA sector overlays; CLOUD Act handling with encryption/key residency; state breach clocks.
• Appendix CA — Canada: PIPEDA + Quebec Law 25 cross‑border transparency; provincial health data localisation.
• Appendix BR — Brazil: LGPD international transfers; ANPD TIAs; government access notes.
• Appendix KE — Kenya: Data Protection Act; registration of controllers/processors; ODPC transfer rules.
• Appendix ZA — South Africa: POPIA cross‑border conditions; Information Regulator guidance.
• Appendix SN/WA — Senegal/West Africa: UEMOA/ECOWAS frameworks; BCEAO/CREPMF data expectations; OHADA records.
• Appendix UAE — United Arab Emirates: Federal PDPL; DIFC/ADGM data protection regimes; financial‑free‑zone hosting specifics.

14) Effective Date & Governance

Adopted by the Board(s) of all regional operators on [●] and incorporated by reference into each Charter/Bylaw and relevant contracts. Class A to weaken residency/compute‑to‑data; Class B to amend/strengthen. Alignment with Annex B/C is mandatory.