Schrems II, Six Years On: EU Data on US Clouds Is Still Unsafe

Six years ago today — 16 July 2020 — the Court of Justice of the European Union handed down its judgment in Case C-311/18, the ruling the world calls Schrems II. It invalidated the EU-US Privacy Shield with immediate effect, left the Standard Contractual Clauses standing but on probation, and told every organisation moving personal data across the Atlantic that a contract is not a shield against a foreign state's surveillance apparatus. The industry answered with paperwork, then with relief when a successor deal arrived. Six years on, the relief looks premature: the successor framework is in court, the US oversight bodies it relied on have been hollowed out, and the underlying question — can EU personal data sit safely on infrastructure a US company controls — still has the same uncomfortable answer it had in 2020. This is an engineer's read of where the law actually stands in 2026, why residency is not sovereignty, and what architecture removes the transfer question instead of re-papering it.

What Schrems II actually held

Be precise about the ruling, because a great deal of vendor marketing depends on people misremembering it. Schrems II did two things. First, it invalidated the Privacy Shield adequacy decision, finding US law did not offer EU data subjects protection "essentially equivalent" to the GDPR — because Section 702 of the Foreign Intelligence Surveillance Act and Executive Order 12333 permitted bulk collection of the kind EU fundamental-rights law forbids, with no effective redress for a European whose data was swept up. Second, it upheld the Standard Contractual Clauses as a transfer mechanism — but with a sharp condition attached.

That condition is the part engineers need to internalise. SCCs create binding obligations only between the contracting parties; they cannot bind a government that never signed. So where the destination's law lets public authorities compel access in a way that overrides the clauses, the exporter must add "supplementary measures" that close the gap — or, if none can, must not transfer at all. The EDPB's Recommendations 01/2020 named those measures, and the strongest is technical: encryption where the keys sit outside the destination authorities' reach and the provider cannot see the plaintext. Contractual and organisational measures alone were deemed insufficient against a surveillance-access problem. This is the sovereignty argument stated in a court judgment: a legal guarantee is only as strong as the technical reality beneath it.

The Data Privacy Framework was a patch, not a cure

The response to Schrems II was diplomatic, not architectural. In October 2022, President Biden signed Executive Order 14086, adding proportionality language to US signals intelligence and creating a two-layer redress path culminating in a Data Protection Review Court (DPRC) — an entity inside the Department of Justice, staffed by executive-branch appointees. On that basis the European Commission adopted a fresh adequacy decision on 10 July 2023, and the EU-US Data Privacy Framework (DPF) went live the next day. Transfers to DPF-certified US companies were "adequate" again as a matter of EU law, and the compliance anxiety of 2020 largely evaporated.

Look at what actually changed, though. FISA 702 was not amended; EO 12333 was not repealed. The DPRC is not an Article III court but an executive-branch review body whose independence rests on an executive order a later president can revise with a signature. EO 14086 layered oversight and proportionality on top of the surveillance regime — it did not remove the access, and nothing about the CLOUD Act obligation on a US-parent provider changed. The DPF made the transfer lawful on paper by declaring the destination adequate; it did not make the destination stop being reachable by US authorities. That distinction is the whole game — and exactly what the next round of litigation turns on.

2026: the ground is moving under the framework again

If you are betting your architecture on the DPF's durability, look at the docket. French parliamentarian Philippe Latombe challenged the adequacy decision directly; the EU General Court dismissed his action on 3 September 2025, upholding the DPF — but he appealed to the Court of Justice on 31 October 2025 (Case C-703/25 P), and that appeal is pending in 2026 with no hearing date set. Separately, noyb — Max Schrems's organisation, the same litigant behind Schrems I and II — has signalled a broader, more substantive challenge, arguing in a letter to the Commission dated 30 June 2026 that developments in the US have knocked out the independence the redress mechanism depended on. Commentators are already calling the combination "Schrems III."

Those "developments in the US" are not hypothetical. In January 2025 the administration removed members of the Privacy and Civil Liberties Oversight Board (PCLOB) — the independent body the Commission's own adequacy analysis cited as a safeguard — leaving it without a functioning quorum, compounding the concern that the DPRC and the wider redress architecture no longer sit on the independent footing the 2023 adequacy decision assumed. The stakes are large enough that Microsoft publicly committed in June 2026 to help the Commission defend the framework in court. When the destination's own hyperscalers are lawyering up to preserve an adequacy decision, that is not a settled legal environment; it is a live one.

The engineering lesson is not to predict how the CJEU will rule. It is that transatlantic adequacy has now been invalidated twice and re-litigated a third time in a decade — so an architecture whose lawfulness flips with a court date is not a stable one. The transfer-risk chain below shows why the exposure is structural rather than a matter of which way one case goes.

Click to zoom

The CLOUD Act is the part the framework never touched

The Data Privacy Framework governs commercial adequacy: whether a US company may lawfully receive EU personal data for business purposes. The US Clarifying Lawful Overseas Use of Data Act (the CLOUD Act, 2018) governs something else entirely — whether a US provider can be compelled to hand data to US law enforcement. These are different instruments solving different problems, and the DPF does not speak to the second at all. The CLOUD Act lets US authorities compel a US-domiciled provider to produce data in its "possession, custody, or control" regardless of where in the world that data physically sits, bypassing the Mutual Legal Assistance Treaty process that would otherwise route the request through EU authorities.

For a US-parent cloud, an EU data centre and EU-resident support staff do not remove the reach: the order is served on the parent, which controls the subsidiary. This is not theoretical. On 10 June 2025, the director of public and legal affairs at Microsoft France told a French Senate inquiry, under oath, that he could not guarantee French citizens' data would never be transmitted to US authorities without French authorisation; asked whether a properly framed US request would oblige compliance, he answered "absolutely." No misconduct was alleged — the testimony is evidence of structure, not behaviour. Corporate separation is a real signal of intent, but it is not a jurisdictional firewall. This is the gap the European sovereign cloud debate keeps circling: a certificate can attest a control, but it cannot revoke a jurisdiction.

Why data residency is not the answer buyers think it is

"Our data stays in eu-central-1" is the single most widespread misconception in European enterprise IT, and it survives because it is half true. The data does stay in Frankfurt. What does not stay in Frankfurt is jurisdiction over the entity that operates Frankfurt. Residency is a statement about geography; the transfer risk Schrems II identified is about who can be lawfully compelled. A US-parent provider can keep every byte in the EU and still be obliged, as an entity, to respond to a US order. The physical location of the disk is not where the legal exposure lives.

There is a subtler point too. Chapter V of the GDPR — the international-transfer rules Schrems II interprets — is engaged when personal data is transferred to a third country or made accessible from one. With a US-parent provider, remote administrative access from the US, support tooling, and telemetry can each be an onward transfer or access that triggers Chapter V, separately from where the primary copy resides. Residency addresses one narrow clause and leaves the access surface untouched. The honest framing is not "is my data in the EU" but "can anyone outside the EU be compelled to reach it" — and for a US-controlled provider, the answer is yes by construction.

Supplementary measures and their ceiling

The EDPB's answer to Schrems II was supplementary measures, and encryption is the headline one — genuinely effective up to a hard ceiling. If data is encrypted and the keys sit with a party the destination's authorities cannot compel, an order to the provider yields ciphertext. The trouble is that most cloud encryption does not meet that bar. Provider-managed key services (KMS in the default tier) put the keys within the provider's control, so an order that reaches the provider can reach the plaintext. Bring-your-own-key on the provider's HSM is better, but the plaintext still transits provider-controlled memory during processing. Hold-your-own-key with client-side encryption is stronger still — yet the data has still left your perimeter, so Chapter V remains engaged even where the plaintext is protected.

Ranking the measures by the only test that matters under compulsion makes the ceiling visible. The question is not "is this encrypted?" but "does this survive a lawful order to the provider, and does it remove the transfer entirely?" Encryption can win the first and never the second — because as long as the operator has a US nexus, there is a party to serve and a third-country transfer to account for. The only measure that clears both columns is the one that removes the US nexus from the chain.

Click to zoom

Key custody is therefore the load-bearing engineering decision, not the encryption algorithm. If you must use a managed platform, the minimum defensible posture is that the keys live in a secrets and key-management layer you operate, on hardware outside the provider's compulsion surface, and that no plaintext is processed where a foreign authority can reach it — the problem that confidential computing with hardware attestation exists to address. Those measures shrink the exposure. They do not make the transfer disappear.

Removing the transfer question entirely

There is an architecture in which Schrems II simply does not apply to your workload, and it is not exotic. If the entity operating your infrastructure is incorporated in and subject to EU law only, on EU hardware, with the control plane and keys in your own custody, there is no export of personal data to a third country and no US party to compel. Chapter V is not satisfied by a better contract — it is not engaged at all, because no third-country transfer occurs. That is the difference between mitigating the risk and dissolving it. Self-hosting is usually argued on cost or control; here it is the cleanest answer to a legal question, because it removes the jurisdictional nexus the entire transfer-risk analysis hangs on.

Concretely, for a Kubernetes platform, the cluster runs on hardware you own or rent from an EU-incorporated provider, the control plane and etcd are yours, the keys sit in an HSM you hold, and residency is enforced at the scheduler and network layers so a workload processing EU personal data cannot be placed on — or egress to — anything outside the jurisdiction. The controls are ordinary Kubernetes primitives; the sovereignty comes from who operates them and under whose law.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: eu-pii-processor
  namespace: regulated
  annotations:
    gdpr/chapter-v: "not-engaged"        # EU operator, EU keys -> no transfer
    gdpr/data-classification: "eu-personal-data"
spec:
  template:
    spec:
      # Only schedule onto nodes an EU-jurisdiction operator controls.
      nodeSelector:
        topology.kubernetes.io/region: eu-central
        sovereignty.stribog.io/operator-jurisdiction: "eu-only"
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                  - key: sovereignty.stribog.io/us-nexus
                    operator: NotIn
                    values: ["true"]
      # Keys resolved from a self-operated HSM/Vault, never a provider KMS.
      containers:
        - name: processor
          image: registry.internal.eu/regulated/pii-processor:1.7.0

The exit-ramp framing matters as much as the compliance one. An organisation that keeps its control plane, keys, and data residency under its own operation is not betting on the outcome of Case C-703/25 P. If the DPF survives, nothing here is wasted; if it falls, there is no scramble to re-paper transfers under Article 46 or negotiate emergency SCCs, because there were never any third-country transfers to re-paper. Optionality here is not a slogan — it is the property of not having your lawful basis for processing depend on a diplomatic instrument you do not control. It is the same anti-lock-in logic that drives replacing a US identity provider like Okta with self-hosted SSO: keep the systems your compliance depends on inside your own jurisdiction and custody.

A decision procedure for engineering leaders

You do not need to repatriate everything to respond to Schrems II sensibly. Classify workloads by whether they touch EU personal data, apply the transfer-risk test to each, and address the exposed ones by severity. The procedure is defensible to an auditor because every step is a factual question, not a judgement call.

1. Inventory the personal data. Find every workload that processes or stores EU personal data — including logs, backups, telemetry, and support tooling, the paths teams most often miss. If it touches EU personal data, it is in scope for Chapter V.
2. Map the compulsion surface. For each in-scope workload, list every entity that operates it or holds a key — provider, parent, intermediary, KMS operator, observability vendor — and flag any that is US-incorporated or US-parented.
3. Apply the two-column test. Ask of each flagged dependency: could a US order compel access, and does it constitute a third-country transfer? A single yes on either column is a Schrems II exposure a contract cannot close.
4. Remediate by severity, not size. Move keys off provider-controlled KMS first — the fastest exposure reduction — then relocate the highest-classification workloads to EU-jurisdiction operation. A small workload adjudicating individuals' rights outranks a large batch job over anonymised data.
5. Prefer measures that dissolve the question over ones that mitigate it. Client-side encryption reduces exposure; EU-jurisdiction operation removes it. Where residual risk is intolerable, choose the architecture with no US nexus over the strongest contract.
6. Rehearse the exit. Document and actually test how each critical workload moves off a US-controlled dependency within a bounded time and budget. A rehearsed migration is optionality; one only written down is a hope.

This is the same shape as the testable-architecture discipline sovereignty demands everywhere else: state the property you need, make it a factual question, build the system so the answer is verifiable rather than promised. Schrems II is not a compliance checkbox; it is a forcing function that rewards architectures whose lawful basis does not depend on anyone else's political weather.

The long game

Zoom out to the decade. Safe Harbor lasted fifteen years and fell. Privacy Shield lasted four and fell. The Data Privacy Framework is three years old and in court. The pattern is not an accident of litigation; it is the structural tension between a European fundamental-rights standard and a US surveillance regime that no adequacy decision has reconciled because none of them changed the underlying access. Betting an architecture on the next framework holding is betting against a six-year track record. The durable posture does not need the bet: keep the data, the keys, and the operating entity inside a single jurisdiction you can name and defend, and the transfer question stops being a risk you manage and becomes one that does not arise.

That is the quiet advantage of building for sovereignty before you are forced to. The organisation already running its regulated workloads on EU-jurisdiction infrastructure reads each new Schrems headline as news about other people's problems; its lawful basis for processing does not move when a court date does. Six years after Schrems II, the ruling's real lesson for engineers is not about transfers at all — it is that the systems you depend on should be the systems you control, because the alternative is re-architecting your compliance every time the diplomatic weather turns. Build it so the weather cannot reach you, and you will not have to.