Three months have passed since the Court of Justice struck down the Privacy Shield, and the useful question is no longer what the judgment means. It is what organisations have actually done about it, which turns out to be a much shorter list than the volume of legal commentary would suggest. The pattern across the summer is consistent. The legal analysis was completed quickly, usually within a fortnight. The register of transfers was built, or dusted off. And then almost everything stalled, not on law and not on technology, but on the discovery that remediating a transfer means persuading a supplier to change something, and a quarter is not long enough to persuade a supplier of anything.
Four postures, only one of which is remediation
Watch what companies did rather than what they announced, and they sort into four groups. Repapering. Replace the Privacy Shield reference in the contract with standard contractual clauses, file it, close the action. This is by some distance the most common response and it addresses the least. The Court did not say that the clauses were unavailable; it said that signing them is not sufficient where the law of the destination country undermines them, and that the exporter must assess this and add measures where needed. A contract swap with no assessment behind it is a document that proves you noticed the judgment. Waiting for the toolkit. Hold the position until the European Data Protection Board publishes its guidance on supplementary measures and the Commission issues the modernised clauses, both of which are expected within weeks. This is defensible and, for many organisations, sensible. What makes it indefensible is doing it silently. A deliberate decision to maintain existing transfers pending published guidance, recorded with a date, an owner and a review point, is a position. The same behaviour without the record is a gap. Technical unilateralism. Change the things you can change without anyone's agreement: encryption, key custody, deployment region, what data goes into the service at all. This is the posture of organisations with engineering capacity and no leverage, and it has produced more real change this quarter than the legal workstreams have. Actual renegotiation. Rare, and almost entirely confined to buyers who are large enough to matter to the vendor, or who are being sold a European hosting option the vendor wants to monetise anyway.
What suppliers did, and did not do
The supplier response through August and September was remarkably uniform: a public statement within days, a legal analysis published as a white paper, an updated transparency report, and a commitment to challenge government requests and to notify customers where permitted. What almost none of them did was change the contract because a customer asked. That matters for planning. If your remediation plan contains an action that reads "obtain amended data processing terms from the vendor", the dependency is not your legal team's drafting speed. It is the vendor's product roadmap and their standard terms committee, and the realistic date is a renewal cycle away. Plan accordingly, and stop reporting those actions as in progress when they are in fact queued behind somebody else's release schedule.
Keys moved, and the limits of what keys buy
The one genuinely technical shift this quarter has been the sudden mainstreaming of customer-managed keys. Bring-your-own-key, hold-your-own-key, key custody in a third country, external key stores: these were engineering curiosities in 2019 and are now part of the sales conversation. Be precise about what they achieve. Where a provider stores data it never needs to read, customer-held keys are a strong measure: a compelled disclosure of the stored material yields ciphertext, and the key sits with someone the order does not reach. That covers backup, archive, file storage and much of infrastructure hosting. Where the provider must process content in the clear to deliver the service, keys do far less. Mail platforms index, filter and scan. Collaboration suites search. Support engineers open tickets and reproduce faults. CRM systems match and deduplicate. In all of those cases the data is available in plaintext at the point of processing, and a key-management story that ignores this is marketing. Which leads to the cheapest supplementary measure available, and the one nobody puts in a remediation plan: have less data in the service. Passport scans do not belong in the collaboration tool. Full customer records do not belong in the marketing platform. A meaningful share of transfer risk exists because data drifted into systems that never needed it, and removing a data category is the only measure that requires no vendor, no contract and no guidance from anybody.
| Data use | Potential control | Limit to check |
|---|---|---|
| Storage and backup | Keep decryption keys outside the provider's custody | Confirm who can compel or access keys |
| Processing content | Restrict plaintext access and support paths | The service may need readable content to function |
| Unnecessary records | Remove data categories the service does not need | Check downstream copies and onward transfers |
| Operational dependency | Assess stop-cost and reversibility | Hosting region alone does not describe access |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
The long tail nobody remediated
The visible work went into the famous vendors. The exposure is mostly elsewhere. The judgment concerns transfers to any third country, not only the United States, and it applies to intra-group flows as much as to purchases. It also reaches onward transfers by your processors: the payroll bureau in Manila, the development team in Minsk, the support desk in Cairo, the integrator with standing administrative access to your production systems from another jurisdiction. Almost every organisation I have seen this quarter has a beautifully remediated position on its cloud suite and no idea who its processors' sub-processors are. There is also a sorting problem in the registers themselves. Most were built in risk order, which is correct for assessment and useless for planning. Sort the same list two other ways before you commit to a plan: by stop-cost, meaning what would actually halt if the transfer had to be suspended at thirty days' notice, and by reversibility, meaning which transfers you could genuinely move or terminate within a quarter. The intersection of high stop-cost and low reversibility is where your attention and your money should go, and it is rarely where the risk score pointed.
Practical Guidance for Transfer Remediation Planning
- Record a dated position for every transfer category, including the decision to wait. An undocumented pause is indistinguishable from inattention.
- Re-sort the transfer register by stop-cost and reversibility, not by risk score alone. That is the list that tells you what to fund.
- Treat vendor contract changes as long-lead items tied to renewal dates. Your negotiating window is the ninety days before renewal, not the week after a judgment.
- Implement the measures that need nobody's permission first. Deployment region, key custody where offered, restricted support access, and removing data categories entirely.
- Be honest about where customer-managed keys help. Strong for storage and backup, weak wherever the provider must read the content to deliver the service.
- Build and maintain a sub-processor list, including your own. Your customers are about to ask for it, and your processors will not volunteer theirs.
- Assign one owner per transfer category, with a review date before the end of Q1. Guidance is coming; the plan must have a scheduled moment to absorb it.
- Write the government-access answer once, centrally. Who receives a request, who decides, whether the customer can be told, and what has actually happened to date.
The Regional Angle
Four things look different from here. The first is the one that catches European-led remediation programmes by surprise: transfer restrictions in this region run in both directions. The DIFC's new data protection law took effect in July with its own export conditions, Bahrain's regime has been in force for a while, and sector rules from central banks and health authorities restrict where certain records may be held at all. A remediation plan that repatriates everything to a European region can therefore breach a Gulf localisation requirement while solving a European one. Solve it as a two-sided constraint and check the sector rules before the architecture is agreed, not after. Second, this quarter has flipped the direction of the conversation for most regional groups. You are no longer the party asking questions; you are the party being asked. European customers, principals and insurers have been sending transfer impact questionnaires since August, and they arrive at whoever answered the email — usually a salesperson, who improvises. Write the answers once: where data rests, who can reach it and from which countries, what the local access powers actually permit, what encryption and key arrangements apply, what happens if an authority makes a request, and a named contact. Groups that can return a complete pack in two days are already winning tenders on it. Third, leverage here is genuinely worse, and the remediation plans written in European head offices assume leverage that regional entities do not have. Much regional software is bought through resellers and distributors, which means the entity you are contractually asking to amend a data processing agreement is a local partner with no authority to amend anything. Establish who your counterparty actually is before you draft, and accept that renewal is the only point at which the request has any force. Fourth, resist the temptation to give the assurance the questionnaire is fishing for. European buyers would like to be told that no authority can compel access to their data in your jurisdiction. That is not a statement any regional supplier can honestly make, access powers here are broad, and there is no transparency-report convention to point at. The credible answer is procedural rather than absolute: this is who would receive a request, this is who decides, this is whether and how quickly we could tell you, this is what we would refuse, and this is how many requests we have received. Suppliers who answer that way are treated as serious. Suppliers who promise it cannot happen are not believed, and rightly so.
The objection worth taking seriously
The strongest objection is that none of this protects anybody. A national security service with legal compulsion and technical reach is not deterred by a contractual clause, a transparency report or a customer-held key on a service that must decrypt to function. On that reading, the judgment has generated an enormous compliance industry, a great deal of documentation, and no measurable improvement in the position of a single data subject. The people saying so include some who are broadly sympathetic to the Court's reasoning. There is force in this, and it deserves a better answer than indignation. The honest response is that the judgment's effect is not primarily protective; it is economic. It has put jurisdiction into the procurement conversation, and three months on you can see the result in vendor roadmaps: European regions, sovereign options, key custody products, support models that keep engineers inside a boundary. Those are structural changes, they are being paid for by buyers, and they would not have happened on a voluntary timetable. Whether that constitutes protection is arguable. That it has changed what the market builds is not. The second, narrower answer is that supervisory authorities are obliged to act on transfers they find unlawful, and the remedy available to them stops the flow rather than fining it afterwards. Regardless of one's view of the privacy merits, an operational dependency that a regulator can switch off is a continuity risk, and continuity risks get funded when privacy arguments do not.
Common Questions
Can we keep using US cloud providers?
In practice most organisations are, on the basis of standard clauses plus additional measures and a recorded assessment. What has changed is that the assessment has to exist, be specific to the service, and be revisited when guidance lands.
Do we need to redo everything when the new clauses arrive?
You will need to repaper on a transition timetable, and the assessment work you do now will carry over. That is an argument for doing the analysis properly and the paperwork once.
Does moving to an EU region solve it?
It helps and it does not close the question, because the analysis follows who can access the data and under what law, not only where the disks are. Support access and parent-company control are the parts that catch people out.
What should we expect over the next twelve months?
Expect the Board's recommendations on supplementary measures and the Commission's modernised clauses within weeks, followed by a scramble to repaper during 2021. Expect the first suspension decisions to emerge from the complaints filed over the summer, and expect them to be narrow, slow and heavily appealed. Expect a second front to open at the end of December, when the United Kingdom leaves the transition period without an adequacy decision in hand, which would put UK transfers into the same framework you are building now. And expect sovereign and regional hosting options to keep arriving as paid tiers rather than as defaults.
Transfer Remediation Planning — we turn the register into a funded plan sorted by what would actually stop, and write the answers your customers are already asking for.
