No Silver Linings: EDPB Issues a Grim Forecast on U.S.-Based Cloud and Data Access with New Guidance
On November 10, 2020, the European Data Protection Board (“EDPB”) issued highly anticipated guidance intended to clarify how data exporters could legally transfer data to “third countries” under GDPR following the Schrems II decision. That decision invalidated the U.S. Privacy Shield program. It also cast significant doubt on whether another transfer mechanism, known as Standard Contractual Clauses (“SCCs”), could be used to support transfers of EU personal data to the United States. This post provides an overview of the guidance, followed by practical suggestions about next steps for U.S.-based organizations.
What just happened?
Following the Schrems II decision, it was clear EU data protection regulators would expect data exporters to evaluate each of their data transfers to third countries, particularly if government bodies in those countries could access EU personal data in contravention of data subjects’ privacy rights. If that evaluation reveals that personal data are susceptible to such access, then the data exporter must identify “supplementary measures” to support the transfer in addition to executing SCCs. To that end, the EDPB stated that the supplementary measures would need to “ensure that U.S. law does not impinge on the adequate level of protection [the SCCs] guarantee.” Shortly after Schrems II, the EDPB formed a taskforce to develop more detailed guidance regarding the required evaluation and potential supplementary measures that would satisfy EU data protection authorities. The new guidance provides the results of that task force’s work.
Evaluating data transfers, one at a time
The guidance addresses the evaluation required of data exporters, laying out six steps for analysis. The overall purpose of the evaluation is for controllers or processors, when acting as data exporters, to verify “on a case-by-case basis . . . if the law or practice of the third country impinges on the effectiveness of the appropriate safeguards contained in Article 46 GDPR transfer tools,” such as SCCs. If so, the Schrems II decision “leaves open the possibility for exporters to implement supplementary measures that fill these gaps in the protection and bring it up to the level required by EU law.”
The steps to be followed in this evaluation are:
- Know your transfers (inventory and map personal data flows to, including mere access from, third countries).
- Identify the transfer tools you are relying on. These may be Article 46 tools, like SCCs, adequacy findings under Article 45, or derogations (exceptions, such as individual consent). Only Article 46 tools will immediately require consideration of supplementary measures.
- If relying on an Article 46 tool, assess whether it is effective in “all circumstances.” Spoiler alert: if the U.S. government has legal authority to snatch up the data, the tool is not effective standing alone.
- Adopt supplementary measures (more on that below).
- Implement procedural steps to execute effective supplementary measures.
- Reevaluate the analysis at “appropriate intervals.”
You can read more about these steps from the IAPP. You should complete the analysis for every data flow relying on Article 46 transfer tools that may not sufficiently guarantee data subject rights, particularly if the infringement arises from potential government surveillance in the recipient’s jurisdiction. The guidance repeatedly states that the analysis must be conducted “case-by-case” to comply with GDPR. The analysis should be fully documented and repeated periodically.
Supplementary measures, a failure of imagination, and a setback for U.S. business
If the requisite evaluation reveals that an Article 46 transfer tool is not adequate to ensure “an essentially equivalent” level of data protection, then the data exporter must implement effective supplementary measures to ensure GDPR compliance. The EDPB guidance categorizes its proposed supplementary measures as technical, contractual, or organizational.
The technical measures are, for the most part, unhelpful to data flows where the data importer requires meaningful access to personal data. A few are conceivable, if unlikely to be useful, such as:
- For data that are merely stored, use of strong encryption (“robust against cryptanalysis” and “flawlessly implemented”) where the importer cannot access the data or the encryption key;
- Use of pseudonymization where personal data “can no longer be attributed to a specific data subject, nor be used to single out the data subject in a larger group” without the use of additional information, and that additional information is held by the data exporter separately; and
- For data that are only routed through, but not stored or accessed in, a problematic third country, “state of the art” encryption may be used if several stipulations are met including “decryption is only possible outside the third country in question” and “the parties involved in the communication agree on a trustworthy public-key certification authority or infrastructure.”
As to cloud providers with access to “data in the clear,” that use case arises in a section of the guidance titled “Scenarios in which no effective measures could be found” (emphasis in original). The guidance states that “the EDPB is, considering the current state of the art, incapable of envisioning an effective technical measure to prevent that access from infringing on data subject rights.”
A separate use case considers a processor in a problematic third country remotely accessing personal data stored in the EU for legitimate business purposes. The EDPB explicitly states that, in this scenario, transport encryption and data-at-rest encryption “do not constitute a supplementary measure . . . if the data importer is in possession of the cryptographic keys.” Here too, the EDPB concludes that it “is incapable of envisioning an effective technical measure to prevent that access from infringing on data subject rights.”
Simply put, the guidance does not offer any technical measure that would support continued use of U.S.-based cloud providers or other processors that require access to personal data, nor support remote access to EU personal data by any organization based in the U.S. In those two pivotal scenarios, the EDPB was simply unable to imagine any technical measure that could sufficiently ensure GDPR compliance. Further, these use cases cannot, according to the guidance, be salvaged through use of contractual or organizational measures. The EDPB notes that contractual measures cannot bind governmental authorities that are not parties to the agreement, and the suggested organizational measures all appear intended to complement technical or contractual measures.
Will newly proposed SCCs bring clear skies?
As if all that wasn’t exciting enough, the day after the EDPB issued its guidance, the EU Commission released draft set of new SCCs, upgraded to accommodate GDPR’s requirements. The clauses support a “plug and play” approach that permits users to choose appropriate provisions depending on each party’s role, with modular provisions for controller-to-controller, controller-to-processor, and processor-to-processor transfers. It does not, however, appear that the new SCCs fully implement the EDPB guidance, and both documents are drafts subject to further comment.
These new SCCs will constitute “appropriate safeguards” under Article 46 of GDPR, as with the current set of much-maligned SCCs. The new SCCs will therefore be susceptible to the same criticisms highlighted by Schrems II and the EDPB guidance. But their draft publication is an important development because they are likely to become the backbone of both data transfers (with supplementary measures) and data protection agreements (“DPAs”). For years, organizations have used bespoke DPAs with the older SCCs to support data transfers. This new model would address all substantive GDPR requirements and may, as it evolves, be revised to align with the EDPB guidance.
What should U.S. companies and/or cloud providers do now?
Assuming you cannot localize personal data processing to the EU, or limit data transfers to countries blessed with an adequacy finding (the Faroe Islands are lovely this time of year!), you may now be wondering what to do. A quick caveat: it’s still early, so we have provided below some practical suggestions that seem safe for now. Do not consider them the last words on the subject. After all, the guidance isn’t final.
- Engage in self-care. Have a drink, take a walk. It’s been a heck-of-a-two-weeks here in the states. (Hello CPRA!) Accept that you are a sane person. The privacy bar has been quick to judge these guidelines “practical,” “pragmatic,” and “impressive.” If you are genuinely wondering whether these learned professionals are reading the same document you just read, don’t worry, you aren’t nuts. The EDPB’s guidance is not helpful or practical. It is not even particularly imaginative (see above) which belies the unresolvable conflict we need to accept: the EDPB exists to protect European data subjects’ data protection rights. It has no duty or incentive to facilitate the U.S.-based technology and data economy. The EDPB also is correct to imply, through its relative lack of proposed solutions, that there really is very little that private parties can do to effectively prevent the U.S. government from putting its tiny hands in the cookie jar.
- Do not spend time commenting on the guidance. Given the EDPB’s mandate and lack of incentives as described above, submitting feedback on this guidance is likely a waste of time. Instead, spend your energy seeking meaningful U.S. reforms. Specifically, adoption of a comprehensive U.S. privacy scheme that can earn an adequacy finding (and preferably preempt CCPA and CPRA), or real reform of the government surveillance powers that brought us to this impasse.
- As we earlier advised, do not stop complying with the Privacy Shield program if: (1) your certification is still active with the U.S. Commerce Department (the FTC and Department of Transportation will continue to enforce the program); (2) you still claim membership in Privacy Shield on your website and/or in your privacy policies; or (3) you maintain ongoing contractual engagements that require ongoing certification (i.e., your DPAs still say you will comply).
- Get creative. Just because the EDPB is “incapable of envisioning” effective measures, doesn’t mean that no technology solution exists that would deter or prevent surreptitious snooping by government authorities. But don’t look at us for answers here, we’re lawyers not tech wizards. Get your tech teams on it and come back to us for a legal view on whether the tech meets the guidance.
- Once the guidance is finalized (no need to aim at a fast-moving target), pursue contractual and organizational methods of protecting EU personal data. Those measures will be necessary to bolster your technology-focused supplementary measures.
- Do your paperwork. You cannot justify your supplementary measures without ANALYSIS. That analysis should support and explain how you arrived at the technology, contractual, and organizational supplementary measures that you implemented.
- As we earlier advised, stay apprised of enforcement actions on this point and position statements or contractual postures from major telecom and cloud providers in the U.S. These parties have the most to lose if data transfers to the U.S. are effectively illegal, and the most incentive and resources to innovate in this space.
- Recall that the obligations ultimately fall to data exporters. I.e., the organization in the EU that is transferring personal data to organizations based in inadequate third countries. These issues may not be relevant if your organization is covered by GDPR, perhaps under Article 3.2, but does not have an establishment in the EU collecting personal data and “transferring” it to third countries. If you are a U.S.-based processor in receipt of data from EU-based controllers, these obligations fall in the first instance to your customers. That perspective is important to ensure the correct frame of reference to assess whether this work is required, how to go about it, and which party should be driving the initiatives. Ultimately, if your organization is not a data exporter, you may either refrain from this work, or adopt a posture that you will assist customers seeking a solution, but you may not wish to unilaterally develop an approach because you could find it is not acceptable to those customers who must satisfy this guidance.
Watch this space for updates on this guidance, the new proposed Standard Contractual Clauses, and all things practical in privacy law. We are always happy* to discuss developments!
*Happiness may be achieved through liberal use of sarcasm.