Cross-Border Data Transfers

The Schrems II Problem

In July 2020, the Court of Justice of the European Union struck down the EU-US Privacy Shield in the Schrems II decision. The core issue: US surveillance laws (FISA Section 702, EO 12333) allow government access to personal data without adequate safeguards for EU data subjects. This did not just affect EU-US transfers. The court's reasoning applies to any country where government surveillance lacks proportionality and judicial oversight.

For engineering teams, the immediate consequence was uncertainty. If your EU user data flows through US-based infrastructure or is accessible by US-based employees, you need a legal basis for that transfer and technical measures to back it up.

Legal Mechanisms

Standard Contractual Clauses (SCCs) are the workhorse. The European Commission adopted new modular SCCs in June 2021 covering four scenarios: controller-to-controller, controller-to-processor, processor-to-processor, and processor-to-controller. You must use the new SCCs. The old versions are no longer valid.

But SCCs alone are not enough. You must also complete a Transfer Impact Assessment (TIA) for each transfer. This assesses whether the destination country's legal framework allows the data importer to comply with the SCCs. For the US, this means evaluating FISA 702 exposure, whether your data is likely to be targeted, and what supplementary measures you can apply.

The EU-US Data Privacy Framework (DPF), adopted in July 2023, provides an adequacy decision for transfers to US organizations that self-certify. It includes new safeguards addressing the Schrems II concerns, including limitations on US intelligence access and a Data Protection Review Court. It is usable now, but privacy advocates have already signaled challenges. Plan for the possibility that DPF gets invalidated like its predecessors.

Technical Measures

When legal mechanisms are uncertain, technical measures reduce exposure:

• Encryption with EU-held keys - Encrypt data before it leaves the EU. If the cloud provider holds the keys, US government requests can compel decryption. If an EU entity holds the keys, the data is protected even if the infrastructure is US-based. Google Cloud External Key Manager and AWS External Key Store support this pattern.
• Pseudonymization - Replace direct identifiers with tokens before transfer. Keep the mapping table in the EU. The transferred data is less useful to surveillance programs because it cannot be linked to individuals without the mapping.
• Regional processing boundaries - Configure your cloud infrastructure so that EU personal data is processed only in EU regions. This means EU-region databases, EU-region compute, and EU-region backups. Verify that your cloud provider's sub-processors also stay within boundaries.

Engineering Data Residency Controls

Build data residency into your architecture from the start. Use geo-routing at the CDN and API gateway layer to direct EU user requests to EU infrastructure. Partition your database by region or use region-specific database instances. Audit cloud resource creation to prevent engineers from accidentally spinning up resources in non-compliant regions. Tag all infrastructure with its data residency zone and monitor for drift.

Multi-region architectures add operational complexity. Failover, replication, and disaster recovery plans must respect residency constraints. You cannot fail over EU data to a US region during an outage. Plan for region-constrained recovery and test it.