Schrems II and the case for deciding where data lives first

The EU’s highest court invalidated the EU-US Privacy Shield on July 16, 2020, and made standard contractual clauses depend on case-by-case assessment. Organizations that settled data location and key control first found the legal paperwork easier, and survived later swings in the law.

Looking Back revisits one week at a time, from January 2020 to today, and asks what it meant for the banks, health systems and public agencies we serve. The series was written in 2026, with the benefit of hindsight, and each article says which week it looks back on.

The week

On July 16, 2020, the Court of Justice of the European Union ruled in Data Protection Commissioner v Facebook Ireland and Maximillian Schrems, known as Schrems II. The court invalidated the European Commission’s adequacy decision for the EU-US Privacy Shield, which more than five thousand companies relied on to transfer personal data from the EU to the United States. It cited the reach of US surveillance law and the limited redress available to EU individuals. It upheld standard contractual clauses as a transfer mechanism. Organizations relying on them, however, had to assess whether the destination country’s law allowed the protections to be honored in practice, and adopt supplementary measures where it did not. There was no grace period.

Schrems II is often treated as a legal problem solved with paperwork, and the paperwork mattered. The court’s reasoning, though, turned on whether data could actually be accessed by authorities in the destination country. That made architecture the decisive response. Banks, health and life sciences organizations and public bodies move personal data between Europe and the United States. For them, the work fell into three decisions, best taken in this order. They were where each category of data physically lives and is processed, who can read it in the clear, and which legal mechanism covers whatever transfers remain. Taking them in that order made each one easier.

Where each category of data lives

The simplest way to reduce transfer risk is to avoid the transfer. European personal data can be stored and processed in Europe. Large cloud providers expanded European regions and later offered commitments to keep more data within the EU, including some support and diagnostic data. Residency does not settle the question alone, because a provider subject to US law may be compelled to produce data it controls wherever it is stored. It does shrink the volume of data that needs further measures.

Residency has costs. It can fragment platforms, duplicate infrastructure and complicate global functions that benefit from one view, such as fraud monitoring, sanctions screening, clinical trial analysis and security operations. The practical approach is to classify data by sensitivity and purpose, then decide category by category. Customer identity and health data may need to stay in region. Aggregated or pseudonymized data for global analytics may be able to move. Each decision should be recorded with its reasoning and cost, so that it can be revisited when law or business needs change.

Hidden flows complicate this layer. A support engineer in one country viewing a database in another is a transfer. So is a monitoring tool that ships logs to a vendor’s global platform, or a backup copied to another region by default. Finding these requires technical discovery, not only interviews with system owners. Network flow data, cloud configuration reviews and vendor subprocessor lists all help.

US organizations serving European customers faced the mirror image. A bank with a European branch, a life sciences company running trials in the EU, or a health system treating European patients had to know which of its US systems received that data and why. Often the answer was a single global CRM, data warehouse or security platform. Splitting those systems was expensive. Partitioning them, so that European records sat in a regional instance or under separate keys, was frequently cheaper and easier to defend.

Who can read the data in the clear

The European Data Protection Board’s recommendations, finalized in 2021, said technical measures could be effective supplementary measures. Strong encryption, with keys held by the exporter or otherwise out of the importer’s reach, was the main example. Pseudonymization could help in some cases. These measures work only when the recipient does not need to read the data in the clear. That rules out many processing purposes, including most software-as-a-service applications that must display or analyze the data.

Key management therefore moved from an engineering detail to a transfer decision. Customer-managed keys, hardware security modules and confidential computing entered transfer decisions. For each workload, the organization needs to know whether the provider can see the data, under what conditions, and whether that can be demonstrated to a regulator. Keys held in a European hardware module controlled by the organization give a clear answer. Keys managed by the provider give a weaker one, whatever the contract says.

Access controls for people complete the picture. Restricting administrative and support access to staff in approved locations, with logging and just-in-time approval, limits who can read data even when it sits in an otherwise compliant region. Those access logs also become evidence for the transfer assessment.

Which legal mechanism covers the remaining transfers

With Privacy Shield gone, most organizations moved to standard contractual clauses. These now required a transfer impact assessment: an analysis of the destination country’s law and practice, and of whether supplementary measures were needed. Assessments had to cover onward transfers to service providers and remote access by support staff, as well as the obvious transfers to a US parent company.

Counsel should own the legal judgment. The quality of that judgment depends on the facts technology teams supply. Where data location and key control had already been decided and documented, assessments could describe a limited set of transfers with clear protections. Where they had not, assessments described sprawling, poorly understood flows and could only hedge. Records of processing written for general privacy compliance often lacked the detail an assessment needed, such as which subprocessors could access which data from where. Keeping a transfer register linked to the architecture decisions, and updating it when systems change, kept assessments current without starting from scratch each time.

With hindsight

The European Commission adopted new standard contractual clauses in June 2021, and the EU and US negotiated a successor framework. After a US executive order in October 2022 added safeguards for signals intelligence and a new redress mechanism, the Commission adopted an adequacy decision for the EU-US Data Privacy Framework in July 2023. On September 3, 2025, the EU General Court dismissed a challenge to it brought by a French member of parliament. He appealed to the Court of Justice at the end of October 2025, so the framework’s durability is still being tested.

Architectural responses spread meanwhile. Cloud providers launched EU data boundary and sovereign cloud offerings, and European public bodies increasingly asked for them. Over six years the legal basis for transfers changed three times. The architecture decisions described here did not need to change with it, which is the practical case for taking them first.

  • Schrems II
  • data transfers
  • GDPR
  • encryption
  • data residency