Schrems II and the case for deciding where data lives first

The week

On July 16, 2020, thousands of companies woke up to find that a legal arrangement they used every day to move information across the Atlantic had stopped working overnight.

That day the Court of Justice of the European Union, the EU’s highest court, ruled in Data Protection Commissioner v Facebook Ireland and Maximillian Schrems, known as Schrems II. Maximillian Schrems is an Austrian privacy campaigner, and this was his second major case on the subject, hence the name.

The case had a long history. Schrems first complained to the Irish Data Protection Commissioner in 2013, after Edward Snowden’s disclosures about US intelligence programs. Facebook ran its European operations from Ireland, which made the Irish regulator the lead authority. That first complaint produced Schrems I, the October 2015 judgment in which the same court struck down Safe Harbor, the arrangement that preceded Privacy Shield.

The Commission adopted Privacy Shield in July 2016 as Safe Harbor’s replacement. Schrems then reformulated his complaint to target standard contractual clauses, the contracts Facebook used, and the Irish High Court referred a set of questions to the Court of Justice in 2018. In December 2019, the Advocate General, an adviser whose opinion the court often follows, advised that the clauses remained valid. He said the court did not need to rule on Privacy Shield, while expressing doubts about it. The court chose to rule on both.

Some background helps. Under European data protection law, personal data, meaning any information about an identifiable person, cannot simply be sent to a country outside the EU. It can flow freely only where the European Commission has decided that the destination offers essentially equivalent protection, a finding called an adequacy decision, or where another approved legal mechanism applies. For the United States, the main route had been the EU-US Privacy Shield, a framework under which American companies signed up to a set of privacy commitments.

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. The court’s concern was that US intelligence agencies could access Europeans’ data, and that Europeans had no effective way to challenge that access in court.

The reasoning was specific. The court examined Section 702 of the Foreign Intelligence Surveillance Act, which authorizes the targeting of non-US persons abroad with the compelled help of US service providers. It also examined Executive Order 12333, which governs US intelligence activities more broadly. It found that these programs were not limited to what is strictly necessary, as EU law requires for any interference with privacy.

Presidential Policy Directive 28, a 2014 directive that set limits on signals intelligence, did not cure the problem, because it gave individuals no rights they could enforce in court. The Privacy Shield Ombudsperson, a State Department official who handled complaints from Europeans, could not issue decisions binding on the intelligence agencies. The court found the role lacked the independence and powers that EU law expects of a body offering redress.

It upheld standard contractual clauses as a transfer mechanism. These are template contract terms, approved by the Commission, that a European company and the recipient of its data sign to promise appropriate protection. 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. A contract cannot bind a government that is not party to it, so the court asked whether the promises in the contract could actually be kept.

The court also gave the national regulators a duty. Where the clauses could not be honored in the destination country, and the exporter had not itself stopped sending data, data protection authorities were required to suspend or prohibit the transfer. That turned the judgment from a statement of principle into something regulators would have to enforce, complaint by complaint.

There was no grace period. Banks, hospitals, drug developers, technology companies and public bodies all had to work out, immediately, how much of their data was crossing the Atlantic, on what basis, and what to do about it.

Reactions came within days. On the day of the ruling, US Commerce Secretary Wilbur Ross expressed disappointment. He said the department would continue to administer the Privacy Shield program and that the ruling did not relieve participating companies of their obligations under it. Companies that had certified were left bound by commitments to a framework Europe no longer recognized.

On July 23, the European Data Protection Board published a set of frequently asked questions. It confirmed that there was no grace period and that transfers on the basis of Privacy Shield were unlawful. It said exporters using contractual clauses had to assess, case by case, whether supplementary measures were needed, and promised more detailed guidance on what those measures could be. That guidance did not arrive in draft until November, so for the rest of the summer organizations had to act without it.

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. Architecture here means the technical design of an organization’s systems: where data is stored, how it moves, who can reach it and how it is protected.

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.

The order matters because each decision narrows the next. A choice to keep a category of data in region removes it from the transfer analysis altogether. A choice about who holds the keys changes what the assessment needs to say about the flows that remain. Legal mechanisms come last because they are the most volatile part of the picture. Between 2015 and 2023, the main legal route for EU-US transfers was struck down twice and replaced twice. Architecture changes on a budget cycle. The law changed on a court calendar, with no notice and no transition.

Regions, hidden flows and keys

Three ideas do most of the work in this story.

The first is that data has a physical location. However abstract it feels, every customer record is stored on disks in buildings somewhere. Large cloud providers, the companies that rent computing power and storage over the internet, organize their buildings into regions: clusters of data centers in a particular geography, such as Frankfurt, Dublin or Virginia. When an organization chooses a cloud region, it is choosing which country its data sits in.

The second is that data is often transferred without anyone thinking of it as a transfer. If a support engineer in Texas logs in to look at a system in Ireland, that counts as a transfer, even though no file has moved. If a monitoring tool sends copies of system logs, which can contain customer names or account numbers, to a vendor’s global platform, that is a transfer too.

The third is encryption. Encryption scrambles data so that it is unreadable without a key, a long secret number. Encrypted data works like a locked safe: it can be shipped anywhere, but only someone with the combination can open it. What matters is who holds the key. If the cloud provider holds it, the provider can open the safe, and so, potentially, can anyone who can compel the provider. If the customer holds the key and the provider never sees it, the provider is storing a box it cannot open.

Put those three ideas together and the logic of the court’s ruling becomes practical. The question was whether someone in the destination country could actually read the data, whatever the contract said. Location, hidden flows and key control are what answer that question.

Why location alone was never the whole answer

A fourth idea lies underneath the other three: who controls the provider. The CLOUD Act, a US law passed in March 2018, clarified that US providers can be required to disclose data in their possession, custody or control even when it is stored abroad. It gave providers only a limited route to challenge orders that conflict with foreign law.

The court’s concern in Schrems II was intelligence surveillance under Section 702, which is a separate legal authority from the criminal warrants the CLOUD Act addresses. Both point the same way, though. Section 702 compels help from “electronic communication service providers”, a category defined broadly enough that many exporters could not assume their own importers fell outside it. The address of the data center was one input. The nationality and legal exposure of whoever ran it was another.

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. Keeping data in Frankfurt does not help much if a US-headquartered provider can be ordered to hand it over. 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. A fraud team that can see patterns only within one region may miss a scheme that spans several. A sanctions screening system, which checks customers and payments against government lists of restricted parties, works best when it sees everything.

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. Pseudonymized data has had names and direct identifiers replaced with codes, so it cannot be linked to a person without a separate lookup table. Each decision should be recorded with its reasoning and cost, so that it can be revisited when law or business needs change.

How the classification is actually done

Classification for transfer purposes is narrower than a full data classification program, and quicker. It needs four facts for each category: what the data is, whose it is, why it moves and who needs to read it. A category might be “retail customer identity records for EU branches”, “EU employee payroll data” or “key-coded clinical trial data from EU sites”. Too fine a grain produces thousands of rows nobody maintains. Too coarse a grain hides the differences that drive the decision.

Each category then gets one of three outcomes. It stays in region, with no routine transfer. It moves, but in a form the recipient cannot read or link to a person. Or it moves in readable form, under a legal mechanism and documented safeguards. Most organizations found that the third bucket was smaller than they feared once the first two had been worked through honestly.

How the answer differs by type of organization

For an EU bank or the EU branch of a US bank, data location was already partly a supervisory question. The European Banking Authority’s outsourcing guidelines, in force from September 2019, expected outsourcing contracts for important functions to state where data would be stored and processed. Schrems II added a privacy dimension to a decision banking supervisors were already asking about. The EU’s Digital Operational Resilience Act, which applied from January 2025, later extended that discipline with registers of ICT third-party arrangements that supervisors can request.

A broker-dealer or wealth manager with European clients faced a different pull. US record-keeping and supervision rules expect certain communications and records to be retained and reviewable by US compliance staff. Keeping EU client data entirely in Europe could collide with that, so the realistic design was usually regional storage with tightly controlled, logged access by named compliance roles. Counsel needed to weigh both regimes, and the architecture had to make that access visible.

For life sciences companies, clinical trial data is the central case. Trial sites in the EU typically send key-coded data to a sponsor, with the key that links codes to patients held at the site. Health data is a special category under GDPR, and key-coded data is still treated as personal data in the sponsor’s hands in most analyses. That made pseudonymization helpful but rarely sufficient. The decision about where the analysis environment ran, and who could reach it, carried real weight.

US health systems were usually affected only at the edges: international patient programs, research collaborations with European institutions, and vendors that process data for European affiliates. Public bodies differed again. Law enforcement data exchanged between EU and US authorities falls under separate instruments, including the EU-US Umbrella Agreement in force since February 2017, and the EU’s law enforcement directive rather than GDPR. European public bodies buying cloud services, on the other hand, became some of the most demanding customers for in-region guarantees.

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 as well as interviews with system owners. Network flow data, cloud configuration reviews and vendor subprocessor lists all help. Network flow data is a record of which systems talked to which, and when. A subprocessor list is a vendor’s published list of the other companies it uses to deliver its service, each of which may handle your data.

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. A CRM, or customer relationship management system, holds the record of every client and interaction; a data warehouse is a central store that gathers data from many systems for reporting and analysis. 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.

Partitioning has its own mechanics. A global CRM might be split by tenant, by region-specific database, or by field-level encryption that hides European records from US users. Each option has a different effect on reporting, on the vendor contract and on the support model. Tenant splits are the easiest to explain to a regulator and the hardest on global sales teams. Field-level encryption keeps one system but needs careful key design and breaks some search and reporting features. The choice should follow from how the business actually uses the data, which is why the classification comes first.

Who can read the data in the clear

“In the clear” means readable, not encrypted. The European Data Protection Board’s recommendations, finalized in 2021, said technical measures could be effective supplementary measures. The Board is the body that brings together Europe’s national data protection regulators. 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.

What the Board’s use cases said

The Board’s recommendations worked through concrete scenarios, and they repay reading. Storage of backups in a third country could be protected by strong encryption if the keys stayed with the exporter and the provider never needed the data in the clear. Pseudonymized data could move if the recipient had no realistic means to re-identify people, including by combining it with other data. Data that only passed through a third country in transit could be protected by strong transport encryption.

Two scenarios were the hard ones. One was a cloud service that needs to process data in the clear to do its job. The other was remote access from a third country for business purposes, such as a shared HR or support function. The Board considered the case where the destination country’s law allowed access going beyond what EU law considers necessary and proportionate. For these two scenarios, it said it could not envision an effective technical measure in the then state of the art. Those two scenarios describe much of how modern organizations run.

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. Software-as-a-service, or SaaS, is software you use over the internet rather than install yourself, such as a hosted email, HR or customer service system. If the application needs to show a customer’s name on a screen or calculate their balance, it has to be able to read the data, and encryption that hides the data from the provider also hides it from the application.

The key management options, and what each one costs

Key management comes in grades. Provider-managed keys are the default: the provider generates, stores and uses them, and the customer has no independent control. Customer-managed keys sit in the provider’s key service, but the customer controls their lifecycle and can revoke them, which stops the provider’s services from decrypting the data. External key management goes further: the keys live in a system the customer runs, often a hardware module in its own data center, and the provider must ask for them each time.

Each step up adds control and adds risk of a different kind. If the customer loses its keys, it loses its data, and no provider support line can recover it. If the external key service goes down, the applications that depend on it go down too. Some SaaS features, such as full-text search, analytics or machine learning on the data, may stop working when the provider cannot read it. Key custody should therefore be decided per workload, with operations, resilience and product owners in the room, and not as a blanket policy issued by the privacy office.

Confidential computing deserves a measured view. It protects data while it is being processed by running workloads in hardware-isolated environments, and it can produce evidence, called attestation, that the expected code ran in the expected environment. It narrows what a cloud operator can see. It also depends on the hardware vendor’s design and has had published research weaknesses. For most organizations in 2020 it was a pilot technology, and it remains a complement to key control rather than a replacement for it.

Key management therefore moved from an engineering detail to a transfer decision. Customer-managed keys, hardware security modules and confidential computing entered transfer decisions. A customer-managed key is one the organization controls rather than the provider. A hardware security module is a tamper-resistant device built to store keys so they cannot be copied out. Confidential computing is a newer technique that keeps data encrypted even while a computer is working on it, so that the operator of the machine cannot see it.

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. Just-in-time approval means an engineer gets access only when a specific task requires it, for a limited time, after someone approves the request, rather than holding standing access all year. Those access logs also become evidence for the transfer assessment.

Support models need the same scrutiny. Many organizations run follow-the-sun operations, with engineers in the Americas, Europe and Asia covering a 24-hour day. Every one of those locations outside the European Economic Area is a destination for transfer purposes, and the United States is only one of them. A support desk in a country without an adequacy decision raises the same questions as one in Texas. Some organizations moved to region-locked support queues for the most sensitive systems. Others accepted the transfer and documented controls such as session recording and data masking, which hides sensitive fields on the engineer’s screen.

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.

The other mechanisms, and their limits

Standard contractual clauses were not the only option, but the others had narrow uses. Binding corporate rules are an internal code for transfers within a corporate group, approved by a lead data protection authority. They suit large groups with many intra-group flows, but approval historically took a long time, and they were subject to the same assessment duty as the clauses. Article 49 of GDPR allows certain derogations, such as explicit consent or transfers necessary for a contract with the individual. European regulators had long said these should be read narrowly and used for occasional transfers, not for routine, structural ones.

The Commission’s new clauses, adopted in June 2021, were organized as modules for different relationships: controller to controller, controller to processor, processor to processor and processor to controller. They built the assessment duty into the contract itself. Clause 14 required the parties to warrant that they had assessed the destination’s law and practice and had no reason to believe it prevented compliance. Clause 15 required importers to notify exporters of government access requests and to challenge unlawful ones where possible. Those clauses gave the technical facts a direct contractual role.

What a transfer impact assessment actually contains

A credible assessment describes the specific transfer: the data, the parties, the purpose, the format and the onward recipients. It analyzes the destination’s relevant laws and how they are applied to that kind of importer. It records any experience the importer has with government requests. It then identifies supplementary measures and explains why they are effective for that transfer.

The technical sections are where weak assessments fail. “Data is encrypted” says little. “Data at rest is encrypted with keys held in an EU hardware module under the exporter’s control, and the importer’s support staff see masked fields only” says a great deal. The difference is entirely a product of the architecture decisions taken earlier.

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.

Change control is what keeps the register honest. A vendor notice of a new subprocessor should trigger a review, not a filing. A cloud configuration change that enables cross-region replication should be caught by automated policy checks before it is deployed. Several cloud platforms let administrators set policies that block the creation of resources outside approved regions. Those guardrails turn a residency decision into something the platform enforces, rather than something people remember. A transfer register is simply a maintained list of every cross-border flow: what data, from where to where, for what purpose, under which mechanism and with which protections.

How the work runs inside an organization

Decisions like these do not belong to one department, which is one reason they stall. The privacy office understands the law but rarely knows how the backup system is configured. The infrastructure team knows where the servers are but not which data is legally sensitive. Procurement signs the vendor contracts but may never have read a subprocessor list. Security owns the keys and the access controls. Each holds part of the answer.

Organizations that handled Schrems II well usually created a small working group that brought these people together with a clear sequence. First, an inventory: a list of the systems that hold European personal data, built from technical evidence as well as interviews. Second, a classification: for each kind of data, how sensitive it is and what it is used for. Third, decisions: for each category, where it should live, who can read it and how keys are managed. Only then, fourth, the legal assessments, written from the facts the first three steps produced.

The working group also needed a way to keep the picture current. Systems change constantly. A new analytics tool is bought, a vendor adds a subprocessor, a team switches on a feature that sends data to a global service. The organizations that stayed on top of this built a simple checkpoint into existing processes: any new system or vendor that would touch European personal data had to answer the same three questions before going live. That turned a one-time project into a routine habit.

Budget was the other practical issue. Regional instances, additional key infrastructure and engineering time all cost money, and the benefit is mostly avoided risk, which is hard to show on a spreadsheet. The groups that won funding framed the choices clearly for executives: what each option cost, what risk it reduced and what it would do to business functions such as fraud monitoring or global reporting. That made the trade-offs a business decision rather than a technical argument.

Who owns what, and the evidence an examiner would ask for

Ownership splits cleanly once the sequence is clear. The data protection officer or chief privacy officer owns the legal judgment and the register. The CIO or chief architect owns location decisions and the patterns that enforce them. The CISO owns key custody, privileged access and the logs that prove both. Procurement owns the contract terms and the subprocessor notices. Business owners sign off on the trade-offs that affect them, such as reduced global reporting.

A regulator or auditor reviewing this work will ask for evidence. Typical requests include the transfer register, the assessments and the reasoning behind them, and records showing where keys are held and who can use them. They also include privileged access logs for the systems in scope and the vendor’s subprocessor list with notices of change. Organizations that kept those records as a by-product of normal operations could answer in days. Those that had to reconstruct them took months.

Useful metrics are simple. The share of systems holding European personal data that have a documented location and key decision. The number of unmapped flows found each quarter, which should fall over time. The time it takes to assess a new vendor. Each one tells leadership whether the program is keeping pace with change or falling behind it. None of them requires new tooling. Most can be produced from the register, the vendor management system and the cloud policy reports that a well-run program already keeps, which makes them cheap to report every quarter.

One bank, three decisions, in order

Suppose a mid-sized bank is headquartered in the United States, with a branch in Ireland serving European business customers.

Its first instinct after the ruling was to ask the legal team to replace Privacy Shield references with standard contractual clauses and draft an assessment. The lawyers quickly hit a wall. They asked which European data went to the United States, and nobody could give a complete answer. The core customer records were in an Irish data center. But the global CRM was in Virginia. The security team’s monitoring platform collected logs from everywhere. Overnight backups were copied to a US region by default. Support engineers in Texas had standing access to the Irish systems.

So the bank changed the order of work. First, location: it classified its European data, kept customer identity and transaction data in a European cloud region, and moved European records in the CRM into a regional instance. Backups were reconfigured to stay in Europe. Global fraud analytics continued, using pseudonymized data. Second, readability: European data was encrypted with keys held in a hardware security module the bank controlled in Europe, and US support access moved to just-in-time approval with logging. Third, the legal mechanism: with a much smaller and better understood set of remaining transfers, the lawyers could write an assessment that described specific flows and specific protections.

Two flows needed more thought. The security team’s monitoring platform needed logs from European systems to detect attacks, and those logs contained user names and IP addresses. Sending them raw to a US platform was a readable transfer. The bank pseudonymized user identifiers in the logs before export and kept the mapping table in Europe. Analysts in the United States could see patterns of attack, and the European team could re-identify an account when an investigation required it.

The second was the overnight support desk, which ran from a team in Asia. That team was outside the European Economic Area too, and had been left out of the first analysis entirely. The bank moved its most sensitive European systems to a region-locked support queue during European hours. It kept overnight cover for infrastructure only, with masked data and recorded sessions. Both choices reduced what the assessment had to justify.

The result was not free. The regional CRM instance and the European key infrastructure cost money, and some global reports became more complicated to produce. But each choice was recorded with its reasoning and cost, so that the bank could revisit it if the law changed. When the law did change, the bank could review those recorded decisions instead of redesigning its systems.

What is at stake, and what sound preparation includes

For a chief executive or board, the stakes are concrete. European regulators can order data flows to stop and impose fines. A sudden stop to transfers can interrupt customer service, payroll, clinical research or security monitoring. Customers and public-sector buyers increasingly ask where their data lives before they sign. And the cost of rebuilding systems in a hurry, after the law moves, is far higher than designing them with location in mind.

The fines are real. Transfer violations fall in the higher tier of GDPR penalties, up to 4 percent of worldwide annual turnover or 20 million euros, whichever is higher. The order to stop transferring can be more disruptive than the fine, because it can arrive with a short deadline and apply to a core business process.

The case against architecture first

The strongest counter-argument is that the paperwork route worked. In 2023 a new adequacy decision arrived, and companies that certified under it could transfer to certified US recipients without the full contractual assessment. On that view, organizations that spent heavily on regional infrastructure in 2020 and 2021 paid for insurance they never claimed.

A second objection is cost and fragmentation. Regional instances duplicate infrastructure, complicate global analytics and slow product teams. Smaller organizations, such as a credit union with a handful of European members or a regional hospital with an international patient program, cannot fund sovereign architecture. A third is that some in-region offerings promised more than they changed, because the provider remained subject to US law.

Each objection has force, and each has a limit. The new adequacy decision covers only certified US recipients, and transfers to many other countries still rely on clauses and assessments. The framework itself has been under legal challenge since shortly after its adoption, so a decision made in 2020 that depended on its arrival would have been a bet. On cost, the architecture argument is about decisions and records more than infrastructure. A small organization can classify its data, choose providers with clear regional options, control its keys for its most sensitive systems and keep a short register. On provider claims, the answer is to check who holds the keys and who can access the systems, which is the question this approach asks first.

Well-prepared organizations share five features: data is classified, with a documented residency decision and cost for each category; hidden flows have been searched for technically as well as asked about; every workload has a clear answer to “can the provider read this, and where are the keys”; privileged access is limited by location and approved just in time; and a transfer register ties it all to the legal assessments.

The failures are their mirror images:

• Paperwork first. Drafting assessments before understanding the flows produces documents that hedge rather than reassure.
• Assuming residency is enough. Data stored in Europe can still be reachable from elsewhere.
• Forgetting the invisible transfers. Logs, backups and remote support are where surprises hide.
• Trusting contract language over key control. If the provider holds the keys, a contractual promise is a weaker answer.
• One-off assessments. Without a maintained register, every legal change means starting from scratch.

Data location, hidden transfers and key control decide the exposure

1. Which categories of personal data do we move between Europe and the United States, for what purposes, and have we decided, with costs written down, where each should live?
2. How did we find our hidden transfers, such as logs, backups and support access, and did we look at the systems or only ask people?
3. For our most important cloud and SaaS providers, can they read our data in the clear, where are the keys held, and who controls them?
4. Do we have a transfer register, and when was it last updated?
5. If the legal basis for transfers changed again next month, which parts of our approach would need to change?

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. Signals intelligence is the collection of communications and electronic data by intelligence agencies, the very activity at the center of the court’s concerns.

The intermediate steps mattered too. The Board finalized its recommendations on supplementary measures in June 2021, keeping the core message that encryption and pseudonymization can help only when the recipient does not need the data in the clear. Organizations had until December 27, 2022 to replace old clauses in existing contracts with the new modules. Regulators also tested the ruling against everyday tools. In August 2020 the privacy group noyb filed 101 complaints about European websites sending visitor data to Google and Facebook. In early 2022, the Austrian and French data protection authorities found specific uses of Google Analytics unlawful under the Schrems II reasoning.

The largest consequence came in May 2023. Ireland’s Data Protection Commission, acting on a binding decision of the Board, fined Meta 1.2 billion euros over transfers to the United States under standard contractual clauses and ordered it to suspend them. That case was the direct descendant of the original complaint. The new framework arrived weeks later, which limited the practical effect of the order, but the fine stood as a measure of the exposure.

The framework spread. A UK extension took effect in October 2023, and Switzerland recognized a Swiss-US version from September 2024. The Commission’s first periodic review, published in October 2024, found that US authorities had put the necessary safeguards in place, including the new Data Protection Review Court. In January 2025, the removal of the Democratic members of the Privacy and Civil Liberties Oversight Board left that board without a quorum. That raised questions in Europe, because the adequacy decision had pointed to the board as part of US oversight.

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. These offerings package the same ideas, data kept in region, tighter control over who can access it and greater customer control over keys, into products organizations can buy.

Microsoft, for example, completed its EU Data Boundary in February 2025, adding technical support data to the customer and pseudonymized data it had already committed to keep in the EU and EFTA. Other large providers announced sovereign cloud offerings with European operating entities. The detail of each offering varies, and the same questions about keys and access apply to them all.

Over six years the legal basis for transfers changed three times. Well-made decisions about architecture did not need to change with it, which is the practical case for taking them first.

Legal frameworks for cross-border data are negotiated between governments and tested in courts, and they can be overturned with no grace period. An organization cannot control that cycle. It can control where its data lives, who can read it and how well it understands its own flows. Those choices hold steady while the law moves around them, and they make each new round of legal paperwork shorter, clearer and easier to defend. With the current framework under appeal, organizations that have done the architectural work have far less to fear from the outcome than those relying on paperwork alone.