First impressions: New EU Standard Contractual Clauses - the Good, the Bad, and the Ugly

Having promised their arrival before the end of the year, the European Commission finally published yesterday (12 November 2020) draft new EU Standard Contractual Clauses (or "SCCs") for consultation.

The new draft SCCs have been long-awaited by privacy professionals - the current (soon-to-be-old) SCCs, and their repeated references to the former EU Data Protection Directive, have looked increasingly long in the tooth since the arrival of the GDPR in May 2018.

No doubt plenty of well-considered, erudite articles will be published by the global privacy community on the SCCs in the coming days and weeks. However, having speed-read through the draft SCCs overnight, here are my immediate takeaways (with thanks to my privacy partners at Fieldfisher who also shared their insights too):

The Good

• Scope of coverage: The new SCCs adopt a modular approach enabling data exporters and importers to select the clauses that are relevant to the types of transfers they engage in. In doing so, the SCCs finally provide a tool to cover all major data transfer scenarios (i.e. C2C, C2P, P2P and, yes, even P2C).
• Applicability to non-EEA exporters: The new SCCs do not require the data exporter to be established in the EEA – meaning non-EEA entities can also sign the SCCs as data exporters (the governing law and jurisdiction provisions in Section III, Clauses 2 and 3 of the SCCs make this clear). This provides a solution (currently sorely-lacking) for non-EEA controllers and processors who transfer EEA data to other non-EEA third parties.
• Implementation grace period: There will be a one year grace period to implement from entry into force of the implementing Commission Decision (see Art 6(3) of the draft implementing decision).
• Light-touch approach to "reverse transfers": The Commission has proposed a light touch set of clauses for "reverse" P2C transfers, i.e. where a non-EEA controller appoints an EEA processor to process non-EEA data, which the EEA processor then transfers back to the controller (note that more detailed clauses apply if the processor processes EEA data). This will help avoid putting EEA processors at a commercial disadvantage to non-EEA processors when touting for business from non-EEA controllers.
• Recognition of local law sensitivities: The SCCs (perhaps surprisingly) show some limited tolerance for importers who are subject to conflicting local law requirements – e.g. where local law requires ongoing retention of data by the importer (e.g., Section II, Module 2, Clause 1.5), and local law prohibitions against the importer giving notification of a public authority request for data (Section II, Clause 3.1(b) and (c)).
• Audits: The SCCs expressly recognise that a data exporter may "take into account" a data importer's relevant audit certifications when conducting an audit, and that the data exporter may rely on an independent audit mandated by the data importer (e.g., Section II, Module 2, Clause 1.9(c) and (d)). This will be welcome news to data processors (though keep an out for the references to potential on-premise audits: that will be less popular...).
• Security: Annex II to the SCCs provide much greater clarity as to the types of security controls the parties should have in place - though this could potentially be both a blessing and a curse (i.e. for suppliers who cannot satisfy all of the suggested control types listed.)

The Bad

• Conflicts with DPA terms: The SCCs set out such a comprehensive set of data protection terms that it is all but inevitable they will conflict with (at least) some of commercially-agreed data protection terms between the parties. Where conflicts arise, the SCCs make clear that the SCCs will prevail (Section 1, Clause 4). The implications of this will need careful thinking through - for example, commercial liability terms between parties will need careful drafting to ensure they can complement, but not conflict with, SCC liability provisions.
• Direct interaction between subprocessors and controllers? The P2P provisions of the SCCs seem to contain some confusing (and unrealistic) expectations about when there must be direct interaction between a subprocessor and the ultimate data controller. See, for example, the SCC's breach notification requirements (Section II, Module 3, Clause 1.6(c)), which require a subprocessor to notify the ultimate data controller directly "where appropriate"; audit requirements (Section II, Module 3, Clause 1.9(c)) where a subprocessor must accept being audited, not just by the processor engaging it, but also by the ultimate data controller; and subprocessing requirements, where the subprocessor - if it wants to appoint further subprocessors itself - must inform the ultimate data controller (Section II, Clause 4(a)). Aside from the impracticalities of this direct interaction between subprocessors and ultimate data controllers, it assumes that subprocessors will know who the ultimate data controllers are - which, in many cases, they won't (see the bullet "Processors need to identify their controllers" under "The Ugly" heading below).
• Express breach reporting requirements for non-EEA controllers: The SCCs place an express obligation on importing non-EEA controllers to notify EEA authorities (and data exporters, and potentially even data subjects) about data breaches they suffer (Section II, Module 1, Clauses 1.5(d) and (e)). This could include non-EEA controllers that receive EEA data under the SCCs but which are not subject to the GDPR under Arts 3(1) or (2). Somewhat oddly, the duty to report a breach arises only where the breach is likely to result in "significant adverse affects", which is a different reporting standard to that under the GDPR (which instead applies a presumption of notification to competent authorities unless the breach is "unlikely to result in a risk"). If the objective is to export EU data protection standards with the data, it's not clear why recipient non-EEA controllers should be subject to a different data breach reporting standard than their EEA-based counterparts.
• Schrems II leaves its mark...: The new SCCs contain extensive Schrems II obligations (see Section I, Clauses 2 and 3). These include a warranty on the data exporter to document a transfer risk assessment in all cases (no allowance for low-risk or SME transfers) which can be made available to the competent authority on request (Section II, Clause 2(d)). Further, there are very onerous obligations on data importers to resist data access requests from public authorities (including a requirement to "exhaust all available remedies to challenge the request" if there are "grounds under the laws of the country of destination to do so") – so cue the data importer having to seek potentially expensive legal advice/engage in expensive legal process under local laws in these circumstances.
• "Shop the importer" provisions: Alarmingly for suppliers, the SCCs include requirements for a data exporter to notify its competent authority if a data importer notifies it that the data importer may not be able to comply with the SCCs. This requirement for the exporter to inform the competent authority applies both if the exporter decides to continue the transfer anyway after having taken appropriate measures with the data importer to remedy the issue and if it instead decides to suspend the transfer – seemingly amounting to a "shop the importer" requirement (Section II, Clause 2(f)), and likely to discourage importers from informing exporters about any issues they experience.
• Joint and several liability provisions: The new SCCs include joint and several liability provisions (Section II, Clause 7) – but these really only reflect the joint and several liability provisions that already exist at GDPR Art 82 and so should be viewed in that light. The bigger issue is the potential for the liability provisions to conflict with commercially-agreed DPA terms – especially since the SCCs' liability provisions do not explicitly reference any potential to cap liability between the parties.

The Ugly

• Repeal of prior SCCs: The new SCCs repeals all of the current SCCs (both the 2001 and 2004 C2C SCCs and the 2010 C2P SCCs). While this perhaps shouldn't come as too much of a surprise, given that these new SCCs are designed for GDPR compliance whereas the current SCCs were designed against prior EU Data Protection standards, it will mean an awful lot of repapering of legacy contracts. Businesses reeling from already having had to repaper contracts following the invalidation of Safe Harbor, the entry into force of the GDPR, the entry into force of the CCPA, and the collapse of the Privacy Shield, will not relish yet another round of large-scale contracting all over again.
• Brexit: The consultation period for the new SCCs expires on 10 December and, in light of this, it seems all but certain that they won't be adopted before the end of the Brexit transition period (assuming the 31 Dec deadline is not extended) – with the consequence that the current SCCs may (at least initially) remain the legal export tool from the UK, even if the EU moves on to the new SCCs.
• Processors need to identify their controllers: For processor to processor transfers under the new SCCs, the parties are seemingly expected to list all of the ultimate data controllers in an Annex IA (Section II, Module 3, Clause 1.1(a). This means, for example, that if you're an exporting enterprise SaaS business hosted on non-EEA third party hosting infrastructure then, when signing the new SCCs with your infrastructure provider, you theoretically need to list all of your data controller customers (numbering in the 100s, or 1000s). Let's face it: that won't happen in reality - expect lots of broad, generic references to "EEA customers" instead. 
• Uncertainty about whether controllers are parties to P2P SCCs: Also somewhat ambiguous is whether the SCCs intend the controllers to be an executing party to P2P SCCs as well. On the one hand, requiring this would seem to defeat the purpose of having P2P SCCs in the first place (by making the controllers a party, you would simply be creating a direct contract between the controller and the subprocessor, as is technically meant to happen with the current SCCs), but then see the slightly oddly-worded parties language in Section 1, Clause 1(b)(ii) and the listing of the ultimate data controllers under the heading "List of Parties" in Annex IA. On balance, it seems unlikely it is the intention to make controllers parties to P2P SCCs, not least given the creation of third party beneficiary rights for ultimate data controllers to enforce SCCs against subprocessors (Section II, Module 2, Clause 4(e)), but the drafting could be usefully clarified.
• Flow-down audit rights controllers: Also problematic for P2P transfers is the fact that controller audit rights flow down the processing chain – i.e. the SCCs make clear that any subprocessor can be audited by the ultimate controller (rather than just by the processor instructing it - Section II, Module 3, Clause 1.9(c) and (d)). This will be alarming to many suppliers.

The European Commission's consultation is open until 10 December 2020, visit the site if you are interested in submitting a response.

This article was first published on LinkedIn: First impressions: New EU Standard Contractual Clauses - the Good, the Bad, and the Ugly. Have I missed anything critical? If so, do share your thoughts by joining the coversation on LinkedIn.