Chapter 47 — Data residency, sovereignty, and transfer

In one sentence

Personal data crossing a border is a legal event, not just a network hop, so where your data physically lives and which mechanism justifies moving it — an adequacy decision, Standard Contractual Clauses, or a sovereign-cloud offering — has to be a deliberate architectural decision, not a side effect of default region settings.

Where we are

Ch 41's data-flow map already records "transfers: to which countries" per the RoPA. This chapter is why that field exists and how to actually satisfy it with real infrastructure choices.

How it works

The legal landscape (know the shape, not every clause):

   GDPR CHAPTER V restricts transferring personal data OUT of the EU/EEA
   unless one of these applies:

     ADEQUACY DECISION    the European Commission has decided the
       destination country provides "essentially equivalent" protection
       -- transfers proceed like an internal EU transfer. Covers a growing
       but incomplete list (UK, Japan, South Korea, Canada -- commercial
       organisations only, Switzerland, and others); re-evaluated
       periodically, so an adequacy decision can be WITHDRAWN (it has
       happened) -- don't treat it as permanent.

     STANDARD CONTRACTUAL CLAUSES (SCCs)   the EU Commission's pre-
       approved contract clauses, signed between exporter and importer,
       committing the importer to GDPR-equivalent protections. THE most
       common mechanism in practice. Since Schrems II (below), signing
       SCCs alone is NOT enough -- you must also do a TRANSFER IMPACT
       ASSESSMENT (TIA): assess whether the destination country's LAWS
       (especially government surveillance powers) could override the
       contractual protections in practice, and apply SUPPLEMENTARY
       MEASURES (strong encryption where the importer has no access to
       keys, pseudonymization, etc.) if they could.

     BINDING CORPORATE RULES (BCRs)   an approved internal code of conduct
       for transfers WITHIN a corporate group across borders -- heavier to
       set up, useful for large multinationals with frequent intra-group
       transfers.

     EU-US DATA PRIVACY FRAMEWORK (DPF, 2023)   the current mechanism
       specifically for transfers to US organisations that self-certify
       compliance -- successor to Safe Harbor (invalidated by SCHREMS I,
       2015) and Privacy Shield (invalidated by SCHREMS II, 2020), both
       struck down by the CJEU essentially because US surveillance law
       (FISA Section 702, EO 12333) didn't provide EU data subjects
       adequate redress. The DPF has stronger redress mechanisms but IS
       ALREADY under legal challenge (as its predecessors were) -- treat
       any single-mechanism reliance on ANY transfer tool as something to
       actively monitor, not "solved once."
   Both SCHREMS rulings are the essential background reading here: they
   are WHY "we signed a contract" stopped being sufficient and technical
   supplementary measures became a real, audited requirement.

Data localization laws (the mirror image — countries requiring data to STAY):

   CHINA  -- the Cybersecurity Law and PIPL (Personal Information
     Protection Law) require certain data ("important data", and personal
     information above volume thresholds) to be stored IN China, with a
     mandatory SECURITY ASSESSMENT for any cross-border transfer.
   RUSSIA -- requires personal data of Russian citizens to be initially
     recorded/stored on servers located IN Russia.
   INDIA  -- the DPDP Act (2023) empowers the government to restrict
     transfers to specific countries (a blocklist model, evolving).
   Others with meaningful localization requirements: Brazil (LGPD, more
     GDPR-like but with its own transfer rules), Vietnam, Indonesia, and a
     growing list -- this is an increasing, not decreasing, global trend.

The architectural response:

   REGION SELECTION AS A CONTROL: pin EU customer data to EU regions
   (eu-west-1, eu-central-1, europe-west*) and treat "does this service
   replicate data outside the region" as a design-review question for
   EVERY new component, not just the primary database. This includes:
     - backups and DR replicas (do they cross regions? if a DR region is
       outside the EU, that's a transfer needing its own justification)
     - logging/observability platforms (a SaaS APM or log-aggregation
       tool that's US-hosted by default is a transfer path many teams
       don't notice)
     - CDNs (edge caching is usually fine for PUBLIC content; RESTRICTED
       data should not be cached at edges outside your approved regions)
     - support tools, email, CI/CD SaaS -- anything processing customer
       data that isn't your own infrastructure needs the same scrutiny.

   SOVEREIGN CLOUD OFFERINGS (an emerging, increasingly available option):
     AWS European Sovereign Cloud, Microsoft's EU Data Boundary, Google's
     Sovereign Controls -- these provide operational and sometimes legal
     guarantees that data, metadata, AND support/operational access stay
     within a jurisdiction, addressing the Schrems II concern more
     directly than "just pick an EU region" (which doesn't by itself
     guarantee no US-based support engineer or subpoena-reachable parent
     company can ever access the data).

   DATA PROCESSING AGREEMENTS (DPAs) WITH SUB-PROCESSORS: every vendor
     that touches personal data on your behalf needs a DPA specifying the
     transfer mechanism it relies on, and you need a MAINTAINED SUB-
     PROCESSOR LIST with a change-notification process (most privacy
     laws require you to be able to tell your own customers who your
     sub-processors are and where they process data -- which means you
     must actually track this, not just sign the DPA and forget it).

Worked example

Finding an unapproved transfer path through an "innocent" tooling choice.

   SecureShop pins its primary database and application infrastructure to
   eu-west-1 for EU customers -- looks compliant on the architecture
   diagram.

   A data-flow review (Ch 41's quarterly reconciliation) traces where
   ERROR TRACES actually go: the APM/error-tracking SaaS tool the
   engineering team adopted eighteen months ago defaults to a US region
   for its ingestion endpoint, and stack traces occasionally include
   request bodies containing EU customers' email addresses and order
   details (an unredacted-logging gap, G1 Ch 50, compounding a
   Ch 47 transfer gap).

   This is a live, undocumented transfer of EU personal data to the US,
   with NO SCC, NO TIA, and NOT on the sub-processor list given to
   customers -- entirely by accident of a tool's default configuration,
   not a deliberate architecture decision.

   REMEDIATION:
     1. Immediate: configure the APM tool's EU-region ingestion endpoint
        (most enterprise SaaS tools offer one once you look) or switch
        providers if none exists.
     2. Fix the underlying redaction gap so request bodies/PII never
        reach error traces in the first place (G1 Ch 50) -- this is
        strictly better than relying on the region fix alone, because it
        also protects against every OTHER accidental transfer path this
        pattern could cause.
     3. Retroactively: sign a DPA covering the period of use, run a TIA
        for the period data was processed in the US, add the vendor to
        the sub-processor list with proper notice to customers, and
        assess whether this needs disclosure as part of any active
        DSARs or (depending on scale and sensitivity) a breach
        consideration under your incident-response process (G1 Ch 51).
     4. Add "where does this tool actually send data, by default" as an
        explicit gate in your vendor-onboarding / Part 3 supply-chain
        process, not just "is it SOC 2 certified."

Practice (60 min)

For a real system: list every third-party SaaS tool that could plausibly receive customer data (support, email, APM/logging, analytics, CI/CD, payment processing) and, for each, find its actual default data-region configuration.
Pick one and verify what redaction/scrubbing happens before data reaches it (G1 Ch 50) — is anything RESTRICTED reaching it unnecessarily regardless of region?
Draft a one-page Transfer Impact Assessment for one real cross-border flow: destination country, the transfer mechanism relied on (SCC/adequacy/DPF), the surveillance-law risk assessment, and any supplementary measures (encryption where the importer lacks keys, pseudonymization) applied.
Build or update your sub-processor list: for each vendor touching personal data, record its DPA status, transfer mechanism, and data region.
Add a design-review checklist item: "does this new component transfer personal data outside our approved regions, and via what mechanism?" — apply it retroactively to your three most recently shipped features.

Common mistakes

Treating "we picked an EU region for the database" as the whole answer. Logging, APM, CDNs, backups, and SaaS tooling are common unnoticed transfer paths — the worked example is a common real pattern, not a contrived one.
Signing SCCs and stopping there. Post-Schrems II, a Transfer Impact Assessment and supplementary measures are expected, not optional extras.
No maintained sub-processor list. Most privacy laws require you to disclose sub-processors to your own customers; "we'll figure it out if asked" fails that requirement continuously, not just when asked.
Assuming an adequacy decision is permanent. It can be withdrawn (as Safe Harbor and Privacy Shield were, via the courts rather than the Commission, but the practical effect is the same) — monitor the legal landscape for mechanisms you rely on.
Ignoring data-localization requirements as "not our problem" if you have EU customers. If you also serve customers in China, Russia, India, or similar jurisdictions, localization laws apply independently of GDPR.
No process connecting new-tool adoption to a transfer review. The gap in the worked example came from an engineering team adopting a SaaS tool without anyone asking "where does this data actually go."

Check yourself

Name the current primary transfer mechanisms available for EU-to-US personal data flows, and what happened to their two predecessors.
What did Schrems II add to the requirements beyond "sign SCCs"?
Give two examples of data-localization laws and what they require, as distinct from GDPR's transfer restrictions.
What makes a sovereign-cloud offering a stronger answer to the Schrems II concern than simply choosing an EU region?
In the worked example, what allowed the transfer gap to be found, and what single upstream fix would have prevented it regardless of region configuration?
What must a sub-processor list contain, and why does the law generally require you to maintain one?