Schrems II in Practice: Encryption Is Not Always Enough

Sixteen months after the Court of Justice struck down the transatlantic adequacy arrangement, the interesting question has stopped being whether a transfer is lawful and started being whether the supplementary measure written on the file actually does anything. For a great many organisations, that measure is one word: encrypted. It appears in the transfer assessment, it satisfies the reviewer, and it closes the item. The European Data Protection Board's recommendations on supplementary measures, finalised in June, are considerably less accommodating than that single word suggests — and the regulator decisions issued this year turn on exactly the point the word conceals. Encryption is not a transfer mechanism. It is an argument about who can read the data. The argument is only as good as the answer to one question: who can obtain the keys, and who can compel them to?

What the guidance actually asks for

Read as a checklist rather than as reassurance, the conditions under which encryption is accepted as an effective measure are demanding. The algorithm must be strong and current, the implementation flawless. The data must be encrypted before transmission and must remain encrypted in the destination country. The keys must be retained solely by the exporter, or by an entity in a jurisdiction offering an essentially equivalent level of protection, and must be unavailable to the importer. And the protection must be expected to hold against cryptanalytic resources available to the public authorities whose access prompted the concern in the first place. Apply that honestly to a production estate and it authorises two things: encrypted transmission, which was never the issue, and encrypted storage of data the provider does not process. It does not authorise the ordinary case, which is a service that reads your data in order to do its job.

Three states, and where the argument collapses

In transit, encryption is universal, cheap and beside the point. Nobody's transfer assessment fails because traffic was unprotected on the wire. At rest, encryption works as a supplementary measure if, and only if, the keys are genuinely outside the importer's reach. This is where most files quietly misstate reality. A service marketed as offering customer-managed keys frequently means the provider's own key management service holds the key material on the customer's behalf, in the provider's infrastructure, under the provider's operational control. That is a useful control against a stolen disk. It is not a control against lawful compulsion of the provider, because a party that can be ordered to produce the key can be ordered to produce the plaintext. In use, the argument usually collapses entirely, and no amount of contract language repairs it. A mail platform that filters spam and indexes for search must see the message. A database service that executes a query must decrypt the rows. A support engineer reproducing a defect needs the record that caused it. A machine learning feature needs the text. If the service is doing anything other than storing an opaque blob, plaintext exists somewhere in the destination, however briefly, and the encryption argument covers everything except the moment that matters.

Stop asking whether it is encrypted

The better question, and the one a safeguards review should be built around, is an enumeration: list every party that can obtain plaintext, in each state, and name the legal instrument that could compel each one. The list is longer than most people expect. The provider's operations and site reliability staff. The provider's key management service, where keys are provider-held. Support and engineering teams, often in a different country from the region you selected. Sub-processors performing telemetry, log aggregation, content delivery, anti-abuse or disaster recovery. Your own administrators, who may sit in a third country. And the provider's parent company, where control of a subsidiary is itself sufficient to bring data within reach of an order. When that enumeration is written down, the transfer assessment stops being an exercise in adjectives and becomes a design document. Most of the useful remediation that has happened since the judgment came from organisations that did this and discovered their architecture, not their paperwork, was the problem.

What genuinely helps

External key management, where key material is held by a third party in a jurisdiction you are comfortable with and the provider must request access for each operation, with the ability to revoke. Client-side encryption before upload, which is realistic for archives, backups, document storage and file exchange, and unrealistic for anything transactional. Proper pseudonymisation, where the additional information needed to re-identify is held only by the exporter and re-identification cannot be achieved by combining the transferred data with anything else the importer holds — a test that defeats most attempts. Splitting processing so that identifiers never leave, and the offshore system works on tokens. And the unglamorous option that outperforms all of the above: keeping the workload out of scope, by not sending the data at all. The honest ranking is that architecture beats cryptography here. Cryptography is what you use when the architecture has already been decided well.

The decisions this year told you which way this is going

The Portuguese authority ordered a national statistics body to suspend transfers to a United States headquartered service provider during the census. The Bavarian authority found a company's use of an American mailing platform unlawful in the absence of supplementary measures. The European Data Protection Supervisor opened investigations into European institutions' use of large American cloud services. In France, by contrast, the administrative court accepted an appointment-booking arrangement in which the health data was encrypted and the keys were held by a trusted third party inside the country. The pattern across all four is consistent, and it is not about the nationality of the logo. It is about who holds the key and whether the service needs plaintext to function. That is the distinction to bring into your own assessment.

Practical Guidance for Safeguards Review

• Enumerate every party that can obtain plaintext, in transit, at rest and in use, and the instrument that could compel each.
• Establish where key material physically resides and who administers the key service, rather than accepting the phrase customer-managed.
• Correct any assessment that claims encryption as a measure where the provider can obtain the keys; an inaccurate file is a worse exposure than an imperfect architecture.
• Reserve client-side encryption for storage-shaped workloads and stop trying to stretch it across transactional systems.
• Test pseudonymisation against the combination rule, not against whether the field looks unreadable.
• Check whether disaster recovery crosses the key boundary, because failover is where carefully designed custody quietly breaks.
• Ask providers for external key management commitments in writing, including per-operation authorisation and revocation.
• Rank workloads by whether plaintext must exist in the destination, and re-architect only the ones where the data justifies the cost.

The Regional Angle

Three things complicate this for organisations operating from the Gulf, and the first is a genuine bind rather than an inconvenience. The European argument requires that keys be beyond the importer's reach. Local obligations frequently require the opposite. Several jurisdictions in this region regulate the use of encryption, reserve lawful access to authorities, and expect a locally licensed entity to be able to produce records to a regulator, a court or a sector supervisor on demand. A design that puts the keys entirely outside the reach of the regional entity may satisfy a European exporter's assessment and leave your local managing director unable to comply with a production order addressed to the company he signs for. The workable answer is usually a split rather than a single answer: keys for data flowing in from Europe held by a third party in a jurisdiction the exporter accepts, and keys for locally generated regulated records held where the local entity can reach them, with the two data sets deliberately separated in the system design. What does not work is one key model applied across an estate governed by two incompatible expectations, which is what most organisations currently have. The second is a procurement trap that catches people who did the right thing. Buying an in-region cloud deployment for sovereignty reasons does not mean the controls the European guidance effectively demands are available in that region. Key management features, hardware-backed key stores, external key manager integrations and confidential computing options are released region by region, and newer regions often run a long way behind the flagship ones, sometimes by years. Ask three questions before signing: which key management services are generally available in this specific region today, at what price, and what happens to the key boundary during failover to the paired region. That third question is the one that fails most often, because disaster recovery configurations routinely replicate into a region with a different key posture and nobody re-runs the assessment afterwards. The third is operational, and it is the reason some of these designs should not be attempted. Holding your own keys is a capability, not a purchase. It requires documented ceremonies, rotation schedules, hardware support contracts, separation of duties, tested recovery of the key material itself, and people who can be reached at two in the morning. Regional mid-market technology teams are small, and key custody in such a team frequently resolves to one competent individual who has the passphrase. In a workforce where a resignation is often an exit from the country within thirty days, a single custodian is not a control; it is an outage waiting for a notice period. If you cannot staff custody properly, a trusted third-party key holder is the better engineering decision as well as the better legal one.

The objection worth taking seriously

The strongest objection is pragmatic. No organisation of ordinary size has been fined for using a major American cloud provider with the standard clauses and a competently written assessment. The board's recommendations are guidance rather than law, and the maximalist reading of them would suspend a large share of normal commercial activity, including activity the regulators themselves depend on. Re-architecting a production estate around key custody is a multi-year programme with a real failure rate, and an organisation that loses control of its own keys has converted a theoretical privacy exposure into an actual loss of its data. That is all true, and any adviser who responds to it by recommending a wholesale migration is not weighing costs honestly. But the exposure is being measured against the wrong instrument. The consequence visible in this year's decisions is not a fine; it is an order to stop transferring, which cannot be settled with money and arrives with a deadline measured in weeks. The second consequence is commercial: enterprise customers and public bodies now ask the plaintext question directly in tender documentation, and an organisation unable to answer it loses the work regardless of what any regulator does. The third is the one that should concern general counsel most, and it has nothing to do with architecture. In a large number of files, the statement that data is protected by encryption with customer-held keys is simply not accurate. Discovering that during an investigation, after the statement has been repeated to a supervisory authority and to customers, is a materially different problem from having an architecture that a regulator considers insufficient. So the sequence is: make the record true, publish the enumeration, and then spend the re-architecture budget on the two or three workloads where plaintext in the destination is genuinely indefensible. That is a proportionate programme. Writing encrypted in a box and moving on is not.

Common Questions

Does provider-side encryption at rest count as a supplementary measure?

Generally not, where the provider controls the keys. It protects against theft of storage media, not against compulsion of the provider.

Is client-side encryption realistic for our core systems?

For file storage, backup and document exchange, yes. For systems that search, calculate, validate or report on the data, no — and pretending otherwise produces an assessment that will not survive scrutiny.

Can strong contract terms substitute for key custody?

Contracts govern what a party will do voluntarily. They do not govern what a party can be compelled to do, which is the entire question the judgment raised.

What should we expect over the next twelve months?

Expect more suspension-style decisions rather than large fines, and expect the long-running complaints filed against European websites using American analytics and hosting to start producing published outcomes. Expect the United Kingdom's own transfer instrument to be finalised and to need mapping alongside the European clauses. Expect the major providers to market external key management, per-operation key authorisation and partner-operated sovereign arrangements as paid features, with regional availability lagging the announcements. And expect the implementing regulations now being drafted in this region to ask their own version of the same question, at which point the enumeration you build this quarter answers three regulators instead of one.

---

Safeguards Review — we enumerate every party that can reach your plaintext, establish where key material actually sits, correct the assessments that overstate your protection, and rank the workloads worth re-architecting.