On July 10th, the European Commission issued its Implementing Decision regarding the adequacy of the EU-UD Data Privacy Framework (“DPF”). The Decision has been eagerly awaited by US and Europe based commerce, hoping it will help business streamline cross-Atlantic data transfers, and by activists who have vowed to scrutinize the next framework arrangement (thereby maintaining their relevance). Regardless of the legal resiliency of the decision, it poses an interesting set of considerations for US businesses, not the least of which is whether or not to participate in the Framework.
For those who followed the development and demise of the Privacy Shield program and the Schrems II case, it has been apparent for some time that the fundamental objection of the activists and the Court of Justice of the EU (“CJEU”) to the original Privacy Shield was the perception that the US intelligence community had an ability to engage in disproportional data collection without any possibility of recourse by EU residents whose personal information may be swept into an investigation. The actual functioning of the program for the certifying businesses were much less controversial.
Since the structure of the program wasn’t the primary reason for Privacy Shield’s revocation, from a business perspective, the current DPF looks a lot like the old Privacy Shield. For businesses who made the decision to participate in the Privacy Shield program in the past, the operational burden shouldn’t be much different under the new DPF, if they have already taken steps to operationalize the requirements.
What is interesting about the new DPF is how it may impact a company’s decision to choose between the Standard Contractual Clauses (“SCCs”) and the alternative adequacy mechanism for transfers. There is also some interest vis-à-vis the DPF and its interactions with state privacy laws.
DPF v. SCCs
One of the components of the new SCCs that were adopted in 2021 (which did not exist in the prior version of the SCCs) is the requirement for all SCCs to be accompanied by a transfer impact assessment (“TIA”)[1]. A TIA is designed to assess whether there are legal barriers to the enforcement of the SCCs in the relevant importing jurisdiction – in this case, the US. Many commentators, and some courts, have applied the Schrems II reasoning to argue that use of the SCCs as a transfer mechanism to the US is not effective in all circumstances, because the Foreign Intelligence Services Act (“FISA”) authorizes US intelligence to engage in bulk collection under section 702 and such programs are not proportional and do not have reasonable safeguards required under EU law.
Although the SCCs are still used to transfer European data to the US (mostly because after Privacy Shield was invalidated, practically speaking, they had been the only remaining transfer mechanism for many businesses), several commenters have taken the position that, if Schrems II is taken to its logical conclusion, then any use of SCCs in the US is effectively impossible, because US companies cannot live up to their promises in the SCCs. This was noted in an expert report commissioned by the German Conference of Independent Data Protection Supervisors to assess the broad reach of FISA section 702 programs. Needless to say, companies who undertake a TIA as part of their deployment of SCCs are also under some level of uncertainty as to the effectiveness since a TIA is not the opinion of a supervisory authority, but rather their own interpretation, and that of their legal counsel – which said expert report may cast doubt on.
The DPF is not plagued by such uncertainty. Specifically, recital 200 of the Decision expressly states the legal protections surrounding FISA programs are adequate and “essentially equivalent” to EU protections related to intelligence and national security. This is a momentous declaration, in our estimation, because as a consequence, participation by a company in the DPF seems to remover the need for a TIA for a transfer mechanism. Put another way, the recital 200 provides binding authority for the assertion that the primary motivation for a TIA (i.e. FISA section 702 programs) is now moot in that the DPF participants have sufficient safeguards (even in light of FISA 702) regardless of undertaking a TIA. Note that the removal of a TIA requirement only works for participants in the DPF and TIAs are still required when relying on the SCCs as a transfer mechanism.
DPF v. State Law
Because the DPF establishes “essentially equivalent” controls for participants, the differences between the scope and requirements of EU privacy law and US state privacy law are brought into more apparent contrast. Looking across the two general frameworks, the differences in concepts, protective requirements, and other controls may actually motivate businesses who are already subject to the various state omnibus privacy laws, to skip participation in the DPF. This is mostly because the DPF is a bit more reasonable to businesses with respect to the exercise of individual rights than some state laws.
For example, the GDPR does not require the controller to comply in full with an access request if the response would “adversely affect the rights” of others, including, a business’ trade secrets or intellectual property[2]. The California Consumer Privacy Act has no such express limitation related to business’ data. That being said, there are a number of possible arguments available under other laws (trade secret, confidentiality obligations, etc.) that could justify a limiting a response to an access request. However, those limitations are not express in the California law – and they are in the GDPR and the DPF.
Similarly, the principles in the GDPR and DPF allow for a denial of an access request where responding to such request triggers an undue burden on the business. The California law’s limitation is a bit narrower than the GDPR/DPF limitation in this instance. California requires responsive disclosures to access requests unless the request is “manifestly unfounded or excessive” [3]. This standard narrower than the DPF standard of “…where the burden or expense of providing access would be disproportionate to the risks to the individual’s privacy…”[4].
Conclusion
This lack of alignment between DPF requirements and state law may lead to operational confusion and uncertainty by US businesses interested or actively involved in the transfer of personal information from the EU. Regardless of the confusion related to the overlapping US and EU privacy laws, businesses who have previously participated in and are familiar with the Privacy Shield program may find it useful to also participate in the DPF. Additionally, for some business models, participation in the DPF can mean reduced administrative and legal costs as compared to putting in place and maintaining SCCs. However, it must be remembered that the DPF is not the same as compliance with US state privacy laws – even though some omnibus state privacy laws echo GDPR concepts. There are significant distinctions which have to be managed between the tactical implementation of a privacy program for US state law and a DPF compliance program.
Finally, even though there has been a commitment by some to challenge the DPF at the CJEU, the Commission’s approval of the DPF does not necessarily signal a “wait and see” approach. It is instead a time for companies to carefully evaluate and review their transfer activities, their regulatory obligations, and the most appropriate path forward. All these years after Schrems II, it is at least nice to have a potential alternative to SCCs, in the right business conditions.
[1] Commission Implementing Decision (EU) 2021/914 Recitals 19 through 21
[2] GDPR, Article 15(4) and Recital 63.
[3] Cal. Civ. Code 1798.145(h)(3)
[4] Commission Implementing Decision for DPF Annex I, Section III.4; 8.b, c, e; 14.e, f and 15.d.
