Standard Contractual Clauses or Data Privacy Framework – what to do? (Q&A Part 3)
Since July 10, 2023, the adequacy decision based on the “EU/US Data Privacy Framework” (“DPF”) provides a new possibility to legitimize data exports to the USA. Until now, the preferred (because: relatively easiest) way to legitimize such data exports was to agree on the Standard Contractual Clauses (“SCC”) in accordance with Article 46 (2) (c) GDPR. Accordingly, Most companies will therefore currently use SCC as means to legitimize their data exports. Now, the “DPF” offers another possibility to legitimize data exports in accordance with Art. 45 (1) GDPR. Raising the question: SCC or DPF?
Do the formalities towards data subjects differ between SCC and DPF?
For the data exporter, there are no significant differences in this regard between employing SCC or DPF. In both cases, the data subject must be informed about the data export and its legal basis in accordance with Art. 13 GDPR. Also, the data exporter must of course comply with the data subject rights according to Art. 15 et. seq. GDPR, regardless of whether SCC or DPF are employed.
For the data importer, signing up to the SCC will of course result in the data importer having to comply with in the obligations laid down in the SCC. These mirror the data subject’s rights according to Art. 15 et seq. GDPR, and being third-party beneficiaries of the SCC, the data subjects can invoke these obligations directly against the data exporter. These obligations do not apply when employing the DPF, no direct obligations arise for the data importer from European law. However, certifying for DPF does come with a number of obligations for the data importer. These do in part mirror the data subject’s rights laid out in the GDPR, but as a whole, appear to be significantly less comprehensive.
How does the relationship between the data exporter and the data importer differ in the case of SCC or DPF?
As a contract, the SCC set a comprehensive set of rules and obligations for the relationship between data exporter and data importer. For example, as per Clause 8 SCC, the data exporter guarantees the data importer’s ability to comply with the terms of the SCC. This inherently carries a risk for the data exporter, especially potential liability vis-à-vis the data subjects as third-party beneficiaries. Mirroring this, however, the SCC also contain strict rules for the data importer and provide the data exporter with means to enforce and sanction the data importer’s compliance with these rules. In addition, Clause 12 SCC provides for a distribution of liability between the parties, which in principle mirrors Art. 82 GDPR.
When using the DPF, the only contract in place between the data exporter and the data importer is the “data transfer agreement” (respecitvley whatever agreement from which the data export results). Thus, no further contractual rules and obligations apply. The DPF itself does not empower the data exporter to enforce and sanction the data importers compliance with the DPF – this is reserved to US authorities. However, there is also no need for such, as under the DPF, the data exporter does not assume liability for the behavior of the data importer.
So: which one to choose, SCC or DPF?
This analysis is only cursory and cannot replace a thorough assessment of the needs and interests in each individual case. However, from the perspective of both a data exporter and a data importer, there is a strong case for using the DPF as a legitimation for data exports instead of the SCC.
A key advantage of the DPF is its much easier use in practice. Employing the SCC requires a great deal of administrative effort, which – for the data exporter – is completely absent when using the DPF. Granted, the data importer will encounter certain efforts certifying for the DPF, which are of course absent when using SCCs. However, once the data importer is certified, the DPF can be applied to most, if not all of its data imports. On the other hand, the SCC need to be put in place on a case-by-case basis, can only be applied to specifically pre-defined data exports and must be adjusted or renewed for each change.
Above all, however, the SCC establish an additional contractual relationship between data exporter and data importer. Not only must this contractual relationship be carefully implemented in order to be effective (which, as already mentioned, requires a great deal of administrative effort, involving a number of pitfalls). This additional contractual relationship also brings along additional rights and obligations for both parties, which in turn bring along additional risks. These additional rights and obligations are not present for the data exporter when employing the DPF: when relying on the DPF, the data export is legitimate by law, without further ado.
This line of argument also applies for the data importer. Granted, certifying for DPF requires the data importer’s compliance with the DPF’s set of rules and obligations, whose implications should to be thoroughly assessed by a US counsel. Still, employing the DPF appears to be advantageous for the data importer as well. From a European perspective, the DPF may contain familiar requirements, but as a whole, these do not appear as strict when compared to the SCC (respectively GDPR). In addition, DPF shields the data importer from the reach of European data protection authorities – and thus, as a consequence, also from fines and claims for damages under GDPR. This might prove a major factor for U.S. companies, as under the DPF, the data importer is exclusively subject to the supervision of the U.S. authorities.
But will the DPF remain effective in the long term?
Probably not. Quite a few data protection experts and supervisory authorities consider the DPF to be inadequate. Max Schrems, the driving force behind the “Schrems I” and “Schrems II” rulings, has already announced that he will also challenge the DPF in court.
With this outlook, it is not unlikely the DPF will have a limited shelf life and might suffer the same fate as “Privacy Shield” in 2020. Should a future “Schrems III” ruling invalidate the Adequacy Decision, the DPF would not be available anymore to legitimize data exports. Notably, like in 2020, such invalidation would be effective ad hoc upon the release of such judgement, and everybody would have to go back employing the SCC immediately. It is hard to predict when, if ever, such situation may occur. However, it should hardly be the case before 2026.
It is up to each party to weigh the implications and risks associated with this scenario. At least in the medium term, it should be possible to use the DPF without any problems. However, anyone seeking a legal solution for their data exports that is viable long-term should employ and/or continue to employ the SCC.
What do I have to do if I want to switch to using the DPF?
As mentioned in the first part of our series, it is not mandatory to switch to using the DPF. If correctly implemented, SCCs which are in place now remain in full force and effect. On the other hand, having SCC in place also does not mean one cannot switch to employing the DPF.
Still, a caveat: those who wish to switch to employing the DPF must note that such would require a thorough update of the data protection paperwork! In particular, all relevant privacy policies, contracts and data processing agreements must be adapted.
Feel free to contact us if you need any further guidance or support in this process.