The 2021 EU SCCs: practical issues… & some solutions?

On 4 June 2021, new standard contractual clauses (SCCs) were issued by the European Commission under an implementing decision, for use in legitimising the making of international transfers outside the EEA under the EU General Data Protection Regulation (GDPR). The 2021 SCCs replace the forms of Commission-approved SCCs previously in effect: 2010 SCCs for controller-to-processor (C2P) transfers and 2004 SCCs for controller-to-controller (C2C) transfers.

As is well known, in the July 2020 Schrems II case, the Court of Justice of the EU (CJEU) confirmed that SCCs (the 2010 C2P version) remain valid as a transfer method provided that, before the transfer, the exporter has “verified”, on a case by case basis (“where appropriate, in collaboration with the recipient”), the adequacy of protection afforded by the law of the importer’s country, “by providing, where necessary, additional safeguards to those offered by those clauses” – verifying that the law’s mandatory requirements do not go beyond what is necessary in a democratic society to safeguard, inter alia, national security, defence and public security.

The relevant paragraphs could be clearer in the English language version (“verify… by providing” safeguards”?). But, generally, this sentence seems to be read as if wording along the lines of “and where necessary ensure such protection” were inserted before “providing” – i.e., the judgment is taken to mean that what’s become known as a “transfer impact assessment” must first be conducted, regarding both the importer country’s regime and the circumstances of the particular transfer or set of transfers envisaged; and in light of that, if necessary, “additional safeguards” must be implemented to protect the transferred personal data adequately; but then, if adequate protection cannot be assured, the data cannot be transferred. On 18 June 2021, the European Data Protection Board  also issued recommendations on possible “supplementary measures” (now often used interchangeably with “additional safeguards”) that could “ensure” adequate data protection.

This article does not generally discuss Schrems II supplementary measures. Its aim is to outline some practical issues arising when seeking to complete the 2021 SCCs, with particular reference to certain published SCCs terms reflecting the approaches of three cloud computing giants: Amazon Web Services (AWS), Google and Microsoft. Less can be said regarding Microsoft’s terms, as its internal P2P SCCs have not been made public.

2021 EU SCCs – overview

The 2021 SCCs are in modular format, with different modules to be used for transfers, from:

• controller exporter to controller importer (C2C, module 1)
• controller exporter to processor importer (C2P, module 2)
• processor exporter to subprocessor importer (processor-to-subprocessor or P2P, module 3) and 
• processor exporter to controller importer (processor-to-controller or P2C, module 4).

Rather than providing four separate stand-alone forms of SCCs, certain clauses are stated to apply only to certain modules, so it’s necessary to stitch together all the clauses relevant to a particular module in a separate document. (However, such documents are available for example  from the International Association of Privacy Professionals.) Unfortunately, unlike with the clauses in the main body of the SCCs, it’s not stated which Annexes or, more crucially, which parts of which Annexes, apply to which module. This omission has led to some practical uncertainties, as covered below.

The 2021 SCCs must be used for transfers from 27 Sept 2021 in place of the old EU SCCs. But, for “legacy” transfers made under previously-signed old SCCs, there is a longer grace period: the old SCCs must be transitioned to the 2021 SCCs by 27 Dec 2022 (implementing decision Art.4).

By the way, in my view it’s possible to incorporate the 2021 SCCs by reference if the relevant jurisdiction’s contract law allows it. That is a matter of contract, not data protection law.

One transfer problem solved

Before 2021 SCCs, no form of SCCs existed to cater for transfers from an EEA processor to a subprocessor. Hence the EDPB’s predecessor the Article 29 Working Party, had suggested some possible workarounds. A commonly used solution was for the non-EEA subprocessor to enter into 2010 C2P SCCs directly with the EEA controller.

With the 2021 SCCs, given the availability of module 3 for P2P transfers, these kinds of workarounds are no longer necessary. So, when an EEA controller uses an EEA processor that transfers to a non-EEA subprocessor (such as  a group company affiliated with the EEA processor), the processor can – since 27 Sept 2021 – sign P2P SCCs with the subprocessor to legitimise the transfer without needing to involve the EEA controller. (Of course, non-EEA subprocessors should also terminate any existing SCCs in the old form previously signed directly with EEA controllers to avoid continuing liability under those old SCCs.)

To illustrate, “Google exporter” SCCs were entered into by certain EEA (and, interestingly, some non-EEA) entities as exporters, with the US entity, Google LLC, as importer. Microsoft’s Sept 2021 Data Protection Addendum refers to and defines “2021 Standard Contractual Clauses” as “standard data protection clauses (processor-to-processor module) between Microsoft Ireland Operations Limited and Microsoft Corporation for transfer of personal data…”, but no copy of those intragroup clauses is online, unlike with Google. 

In contrast, although the “AWS Contracting Party” for EEA customers (s.14 AWS Customer Agreement) is its Luxembourg entity Amazon Web Services EMEA SARL:

• the AWS Data Processing Addendum states that it is entered into with “Amazon Web Services, Inc. and the AWS Contracting Party or AWS Contracting Parties (as applicable) under the Agreement (together “AWS”)” (emphasis added), and
• AWS offers C2P SCCs (for EEA customers who are controllers) or P2P SCCs (for EEA customers who are processors), in both cases between the customer and “AWS” as defined.

From a GDPR risk perspective, it seems odd that (unlike Google and Microsoft) Amazon has not implemented internal P2P SCCs between its Luxembourg entity and Amazon Web Services, Inc., but has maintained what seems to be the now-obsolete structure (under the old SCCs) of direct (2021) SCCs between the US entity and EEA customers, thus unnecessarily exposing the US entity directly to liability under the 2021 SCCs.

For transfers from the UK, Schrems II applies but the old SCCs are still in effect because the 2021 SCCs were issued post-Brexit. Therefore, P2P transfers from the UK still require use of one of the old workarounds. For instance, for transfers from the UK Microsoft has maintained 2010 C2P SCCs signed directly with the US importer Microsoft Corporation, as has Google (with the importer being “Google”). However – for operational simplicity and convenience – global groups might use the 2021 EU SCCs in all cases in any event, given that the ICO proposes to allow their use subject to completion of a UK addendum, and take the (relatively low) risk of enforcement for that use.

But one transfer problem remains

There is one remaining gap. The 2021 SCCs include a (lighter touch) P2C module to enable EEA processors to transfer to non-EEA controllers. The policy motivation is that non-EEA controllers should not be discouraged from engaging EEA processors because of the difficulties of transferring personal data “back” to those controllers, so the 2021 SCCs provide a mechanism for those transfers.

By the same token, however, surely non-EEA processors should similarly not be discouraged from using EEA service providers as their subprocessors, e.g., EEA cloud hosting providers, particularly given the EU policy aim of fostering the use (surely including by non-EEA customers) of EU-bred cloud services. Yet, the P2P module provided only works one way – for transfers from EEA processors to non-EEA subprocessors. Strictly, it’s a P2SP module. It can’t be used for transfers from EEA subprocessors to non-EEA processors (or SP2P transfers if you like).

Neither the EDPB nor the Commission has mentioned this issue yet. I hope the Commission will in future provide SP2P SCCs for these other types of P2P transfers, to deal with this lacuna.

Scope of usage

The 2021 SCCs can be used by exporters who are non-EEA entities, unlike with the old SCCs. But, can they be used to legitimise transfers to non-EEA importers who are subject to the GDPR, given the text of the relevant Decision’s Art.1 and Rec.7 suggesting that they can only be used for transfers to importers who are not subject to the GDPR?

No doubt partly to resolve this uncertainty, following the adoption of EDPB guidelines on the relationship between Art.3 (territorial scope of GDPR) and Ch.V (transfers), issued in draft for consultation in Nov 2021, the Commission plans to develop a separate set of SCCs specifically for transfers to importers subject to the GDPR under Art.3(2) (processing personal data not in the context of activities of an EEA establishment, but related to the offering of goods/services to, or monitoring of, EEA data subjects).

In a speech on 12 Dec 2021, head of the Commission’s international data flows and data protection unit Bruno Gencarelli said that this new module was intended to be added in “the first part of [2022]”, and would be a much lighter module, but replicating most of the substantive requirements of the SCCs.

However, again a gap remains. What about transfers to non-EEA importers who are subject to the GDPR under Art.3.1 because they process personal data in the context of activities of their EEA establishment, such as the US Google entity in the Costeja case? What can be used for transfers to them? I hope the Commission’s 2022 SCCs will cater for that situation, and not just for importers subject to GDPR under Art.3.2.

Overlap with Art.28 terms

The 2021 SCCs include terms seeking to enable the parties to comply with Art.28 GDPR’s requirements to cover certain minimum areas in contracts between controllers and processors, i.e., module 2 (and module 3, as terms from the C2P contract must be flowed down to subprocessor agreements).

No doubt the Commission intended to be helpful in including Art.28 terms, to save the parties from having to sign a separate DPA as well as SCCs. The 2021 SCCs’ Art.28 terms are similar (but, interestingly and inexplicably, not identical¹) to the Commission’s standard contractual clauses for Art.28 controller-processor data processing agreements, also issued on 4 June 2021 (Art.28 SCCs). However, their inclusion in the 2021 SCCs gives rise to two issues.

Issue 1. The Art.28 terms are of course part of the 2021 SCCs, and the SCCs’ terms are stated to prevail over any related agreements between the parties (Clause 5). This means that the 2021 SCCs’ Art.28 terms take priority over any Art.28 terms agreed between the parties in a separate data processing agreement (DPA), e.g., in the processor’s standard online terms. That can obviously cause difficulties in relation to any conflicting terms in a party’s standard form or indeed the parties’ negotiated DPA, particularly in cloud computing, where many Art.28 requirements are already tricky to apply (see my earlier article).

What to do? At least the 2021 SCCs state that the parties can include SCCs as part of a “wider contract”, and indeed can add to the SCCs other clauses or additional safeguards that do not contradict, directly or indirectly, the SCCs or prejudice data subjects’ fundamental rights or freedoms (Clause 2(a)). Therefore, the wider contract could seek to clarify and/or particularise the relevant terms (such as how audit rights are to be exercised, and how the right to object to subprocessors should be exercised e.g., with cloud, a right for the exporter to terminate its processing agreement but without being able to block the subprocessor appointment), while confirming that of course the SCCs must prevail in cases of conflict.

While attempts to limit liability as against data subjects are very unlikely to succeed, it’s unclear if importer’s liability to exporters (or vice versa) can be restricted or excluded, particularly as the SCCs state that “each Party shall be liable to the other Party/ies for any damages it causes the other Party/ies by any breach of these Clauses” (Clause 12). However, no doubt the wider contract would also seek to limit liability. Indeed, in the SCCs themselves (both C2P and P2P), AWS added an Annex III explicitly stating that its customer agreement’s Limitations of Liability section was an additional clause pursuant to Clause 2 SCCs (which makes its maintenance of the pre-2021 SCCs contracting structure, discussed above, more difficult to understand).

In addition, constituting problem 1.5 perhaps, in fact the SCCs omit or don’t fully cover all the terms required by Art.28(3). Notably, they require assistance regarding certain aspects explicitly, but not data protection impact assessments (DPIAs) under Art.28(3)(f) – contrast Clause 8(c) of the Art.28 SCCs, which do cover this point. Clause 8.6(d) requires the importer to assist the exporter to comply with the exporter’s GDPR obligations, in particular to notify the controller/competent supervisory authority. This broad requirement (along with Annex II’s description of security measures) could arguably be taken to cover assistance with the exporter’s own Art.32 security obligations also, as required by Art.28(3)(f), but the only explicit reference in Clause 8.6(d) is to notification obligations. Requiring a processor to implement appropriate security measures, is not the same as requiring it to assist the exporter with its own security measures, of course. Therefore, those wanting to ensure compliance with Art.28 might well, in any event, implement a separate DPA or wider agreement explicitly covering assistance with DPIAs/supervisory authority consultations and the exporter’s own security measures.

Importers would want the wider agreement to cover reimbursement of their importer’s fees and reasonable costs/expenses of providing any required assistance to the exporter. The EDPB has made clear in its opinions on national Art.28 SCCs (see Denmark for instance) that costs are a commercial matter for the parties. Exporters might want costs clauses in the wider agreement too, as in some cases the SCCs require exporters to provide assistance to importers.

Now for issue 2. Clause 3 of the 2021 SCCs gives third party beneficiary rights to data subjects against both importer and exporter in relation to, not just transfers, but also several (but not all) of the 2021 SCCs’ Art.28 terms. Art.28 itself doesn’t require or impose any such third-party beneficiary rights, although data subjects who have suffered material/non-material damage resulting from a GDPR infringement can claim compensation against parties “involved” in the relevant processing under the palindromic Art.82. The Art.28 SCCs don’t impose any such third-party rights either, save only if the processor has factually disappeared (Clause 7.7(e) Art.28 SCCs, also replicated in the 2021 SCCs under Clause 9(e) of the C2P and P2P modules).

Therefore, both exporters and importers, who may have no choice but to sign the 2021 SCCs, are now also forced to accept potentially greater risks and be exposed to potentially greater liability in relation to the specific SCCs Art.28 matters than under the GDPR itself. That includes the explicit requirement in Clause 9(b) to flow down to subprocessors the SCCs’ additional Art.28 third party beneficiary rights, i.e., oblige importers’ subprocessors/(sub)subprocessors etc. to agree contractually to such direct rights in favour of data subjects (something that GDPR itself doesn’t require). Again, importers’ subprocessors/(sub)subprocessors etc. may have no choice but to accept though it’s possible that some might simply refuse to sign altogether. All this gold-plates GDPR in relation to Art.28 matters, and no doubt many data subjects will seek to weaponize the SCCs’ Art.28 third party beneficiary rights, by, perhaps  querying the security measures of certain disfavoured processors or subprocessors, the legality of onward transfers to them under Clause 8.8, or the adequacy of (sub)subprocessor contract terms under Clause 9(b). Also, note that importers must contractually submit to the jurisdiction of the competent supervisory authority, including audits (Clause 13(b), with no equivalent provision in the Art.28 SCCs, although this particular obligation is not expressed to be subject to third party beneficiary rights in favour of data subjects or indeed regulators).

Now to flag some other issues regarding Clause 8 or the SCCs’ Art.28 terms.

Controller processing. In relation to the processing terms, in real life many processors/subprocessors conduct some “controller” type processing of customers’ personal data, for the purposes of analytics, improving or developing products generally, etc. While the SCCs override conflicting terms in any wider agreement, in the latter processors/subprocessors may well seek to preserve, or at least be instructed to conduct, any such processing.

Sensitive data. Clause 8.6 (module 1 C2C) or 8.7 (C2P, P2P) and Annex I seem to envisage specific restrictions and/or additional safeguards for sensitive data (special category or criminal offence-related data), such as additional security measures (such as pseudonymisation) and/or additional restrictions with respect to further disclosure (Clause 8.6), “strict purpose limitation, access restrictions (including access only for staff having followed specialised training), keeping a record of access to the data and restrictions for onward transfers” (Annex I). The Art.28 SCCs take the same approach here. Whether or not a processing service targets such types of data, e.g., specialised health data storage, it seems likely processors will state that their Annex II measures are strong enough to cover sensitive data (particularly for processing or transfers of mixed data, some sensitive and some not), although exporters may well want to impose specific restrictions on controller importers regarding sensitive data.

Post-termination deletion. Clause 16(d), for Modules 1, 2 and 3, requires transferred personal data to, “at the choice of the data exporter immediately be returned to the data exporter or deleted in its entirety”. However, the “immediately” requirement is not imposed by the Art.28 SCCs, nor was it required by the 2010 SCCs.

Notification of all non-compliance. Obliging the importer to notify the exporter of any and all non-compliance, including of the 2021 SCCs’ Art.28 terms, goes beyond the GDPR’s requirements, but this term is in both the 2021 SCCs and Art.28 SCCs (Clause 16(a) and 10(a) respectively). So even minor non-compliance with a minor Art.28 term must be notified, which could lead to a flood of notifications. There is no materiality qualification. Surely this is not desirable or practicable. It should be for the parties to agree which breaches of which terms should be notified. In the 2010 SCCs, the notification obligation was limited to law enforcement requests, accidental/unauthorised access and data subject requests.

Suspension and termination. While the 2010 SCCs entitled the exporter to suspend transfers for any non-compliance, the 2021 SCCs require (“shall”) suspension for breach of or non-compliance with “these Clauses”. Hopefully this refers to the SCCs as a whole, rather than specific (e.g. Art.28) terms, as compelling the suspension of transfers (e.g. under third party beneficiary rights) for a minor breach of a non-material term, or even a gold-plated, tougher than GDPR one, seems to go too far. There may well be arguments in the future about whether the former or the latter is intended and, if the former, how many breaches of what terms would amount to breach of “these Clauses” overall. Also, the “set in stone” one-month period for restoring compliance following any suspension is quite rigid (Clause 16(c)(i) 2021 SCCs, 10(b)(1) Art.28 SCCs); it might need to be shorter for some processing but longer for others, and some flexibility here would have been helpful. At least, the termination right in Clause 16(b) 2021 SCCs or 10(b) Art.28 SCCs is more circumscribed, for example  referring to “substantial or persistent breaches of these Clauses” (although again the meaning of “these Clauses” may cause future arguments). The wider agreement could seek to address some of these issues, such as the consequences of termination for a minor breach of a non-material term of the SCCs, but the SCCs’ terms, including the suspension and termination rights, will override in cases of conflict.

Mr Gencarelli has said (see speech referenced above) that the Commission wants to develop online FAQs regarding the 2021 SCCs, intended to be answered in a “very user-focused and implementation-friendly way” and updated on an ongoing basis (which I hope is the Commission’s 2022 New Year’s resolution!). He said the FAQs would be launched at least with the first set of questions “at the beginning of next year” (early 2022). These FAQs would be most welcomed by practitioners. Mr Gencarelli acknowledged that the Commission had been receiving queries on the relationship between the part of the contract covered by the SCCs and the rest of the contract (which I take to mean, including the Art.28 terms). So, let’s hope the FAQs will address these Art.28 issues too.

Paperwork galore – onward transfers and more

The 2021 SCCs (Clause 8.7 or 8.8 depending on the module) restrict onward transfers of the transferred personal data, e.g., disclosure by the importer to another entity in the same or different “inadequate” third country (including within the same group). 

To comply with the SCCs’ conditions for permitting onward transfers (which again are more restrictive, prescriptive and detailed than under the GDPR itself), SCCs will often have to be entered into with the onward transferee (with the same issues flagged above regarding “greater than Art.28” obligations/liabilities for the onward transferee). Working these out is a cold towel job, but here I can do no better than to refer to Renzo Marchini’s excellent table summarising the flowdown requirements and which modules to use between which parties in different situations. Still, confirmation by the Commission would be helpful here.

Clause 13 and Annex I.C

This Clause requires Annex I.C to state the competent supervisory authority (SA), basically in relation to a data exporter who is established in an EU (read EEA) Member State or who is not so established but is caught by GPDR under Art.3.2 and has (or has not) appointed a GDPR representative.

As practitioners know, it’s already tough enough to try to work out who the competent SA is, especially where “cross-border processing” (Art.4.23 GDPR) is involved and there is a “lead” SA who would be primarily competent. But Clause 13 doesn’t envisage the possibility of a lead SA at all.

Another gap – Clause 13 doesn’t envisage an exporter who is not itself established in the EEA but is subject to the GDPR under Art.3.1 by virtue of processing personal data “in the context of” the activities of its EEA establishment (such as the US Google entity in Costeja, mentioned above).

Google’s Annex I.C simply states, for its intragroup P2P SCCs (including for ads), that the competent SA is Ireland’s Data Protection Commission (as Google’s main contracting party for EU customers is its Irish affiliate). However, in its forms of SCCs (C2P, P2P) to be entered into directly with EU customers regarding its Google Cloud Platform, Workspace or Cloud Identity services, Google has shifted the decision to its customers: the competent SA in Annex I.C is stated to be “The authority identified by the data exporter as its competent supervisory [sic – authority] via the Admin Console” (access instructions). Similar but different, in the C2P and P2P SCCs relating to its ads processor terms (which link to the relevant SCCs), the competent SA is the Irish SA “unless the data exporter notifies the data importer of an alternative competent supervisory authority from time to time” in accordance with Section 12.2 of the Data Processing Terms,whereby customers must provide such information to Google and keep it updated (similarly with the Firebase service’s P2P SCCs.)

For its ads controller terms and C2C SCCs, the competent SA is stated as Ireland’s DPC. But, for its separate controller-controller data protection terms with partners for Controller Services, the C2C SCCs’ Annex I.C provides: 

“To the extent the data exporter is in Ireland, or is located outside the EEA, the Irish Data Protection Commission. Where the data exporter is located in a member state other than Ireland, the supervisory authority of the member state in which the data exporter is located shall be the competent supervisory authority.”

All these slightly different approaches, albeit for different services, demonstrate the complexity of the situation in relation to just one Clause of the SCCs. We can’t blame AWS simply stating in Annex I.C of its SCCs, both C2P and P2P versions, that “The data exporter’s competent supervisory authority will be determined in accordance with the GDPR”!

Annex I “For transfers to (sub-) processors, also specify subject matter, nature and duration of the processing”

Unfortunately, the SCCs don’t state which module or modules this odd final sentence of Annex I.B, “Description of Transfer”, is meant to apply – presumably the C2P (for transfers to processors) and P2P (for transfers to subprocessors) modules, hence the “(sub-)”? It is identical to a sentence at the end of Annex II of the Commission’s standard contractual clauses for Art.28 controller-processor agreements, seemingly echoing the first sentence of Art.28(3), which requires the C2P data processing agreement to set out the “subject-matter and duration of the processing, the nature and purpose of the processing, the type of personal data and categories of data subjects and the obligations and rights of the controller”.

The head-scratching issue is that Annex I.B already has headings such as: categories of data subjects whose personal data is transferred; categories of personal data transferred; frequency of transfer; nature of the processing, purpose, and period for which data will be retained. The sentence quoted above does not seem to add anything to those headings. Yet similar wording (indeed largely the same wording, but with “process” instead of “transfer”) appears in the Art.28 SCC’s Annex II “Description of the processing”, where it does not make much sense either given the preceding headings.

Therefore, it’s unsurprising that Google’s C2P and P2P SCCs (including intragroup) simply state “As above” against that puzzling sentence, or “Not applicable” for its C2C and P2C SCCs – while AWS’s SCCs state “The subject matter, nature and duration of the processing are described in Section 1.3 of the Addendum” (with the preceding headings of Annex I often completed by cross referencing other parts of the Addendum).

Annex II “For transfers to (sub-) processors, also describe the specific technical and organisational measures to be taken by the (sub-) processor to be able to provide assistance to the controller and, for transfers from a processor to a sub-processor, to the data exporter”

This is the easiest SCCs puzzle to solve. In relation to the importer’s obligation to assist the exporter in responding to data subject requests, Clause 10(b), Data subject rights, requires in the C2P and P2P modules that “the Parties shall set out in Annex II the appropriate technical and organisational measures, taking into account the nature of the processing, by which the assistance shall be provided, as well as the scope and the extent of the assistance required”.

Therefore, that sentence in Annex II, while not expressed to apply only to modules 2 and 3, must surely be read as applying only to those modules. For many cloud services, no doubt the description would be that the importer has provided tools ( a dashboard or console), enabling the exporter to deal with data subject requests directly in self-service fashion without needing active assistance from the cloud provider.

However, a minor point, the Art.28 SCCs Annex III includes the above quoted wording with the addition of “and, for transfers from a processor to a sub-processor, to the data exporter”. That Annex III also includes a further sentence not included in the 2021 SCCs, perhaps because the further sentence seems superfluous: “Description of the specific technical and organisational measures to be taken by the processor to be able to provide assistance to the controller.”

Annex II Technical and organisational measures including security measures

Annex II is needed for all modules except P2C. The headings under “Examples of possible measures” include: Measures of pseudonymisation and encryption of personal data; Measures for ensuring ongoing confidentiality, integrity, availability and resilience of processing systems and services; Measures of pseudonymisation and encryption of personal data; Measures for ensuring the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident. They are virtually identical to those in Annex III of the Art.28 SCCs, but referring to data importer instead of processor. Otherwise, there are no substantive differences (see the previous section on an additional unnecessary sentence in the Art.28 SCCs).

How should the required security measures be described? (The following is relevant to the Art.28 SCCs and Art.28 agreements generally, as well as to the 2021 SCCs.)

The EDPB has already indicated, in its guidelines on the concept of controller/processor, that, in its view, Art.28 data processing agreements must contain 

“more specific, concrete information as to how the requirements will be met and which level of security is required for the personal data processing… The contract needs to include or reference information as to the security measures to be adopted, an obligation on the processor to obtain the controller’s approval before making changes, and a regular review of the security measures so as to ensure their appropriateness with regard to risks, which may evolve over time. The degree of detail of the information as to the security measures to be included in the contract must be such as to enable the controller to assess the appropriateness of the measures pursuant to Article 32(1) GDPR…”

This view of the EDPB causes difficulties. Firstly, giving too much information about security measures – especially in terms published online – can itself create a security risk, enabling attackers to mount more targeted attacks. Secondly, it is critical for organisations to keep updating their security measures to defend against threats that will inevitably evolve over time, often very quickly. Stating the required security measures in too much specific detail would give rise to operational issues if amended contracts with updated security measures have to be re-signed continually. 

Therefore, in this area, I disagree with the EDPB (whose opinions are in any event only advisory and strictly not legally binding, even if authoritative). Large cloud providers generally have much better security expertise than their customers, particularly SME customers, and requiring customer approval for every security change is completely unworkable. Nevertheless, leaving aside the problematic approval issue, it is still possible to try to provide more specific information about security measures than pre the 2021 SCCs, without giving hackers the keys to an organisation’s virtual house.

Here, as elsewhere, different approaches have been taken. From the viewpoint of easing regulatory interactions (and enabling supervisory authorities to tick the boxes), the best approach is  to mirror the example headings used in Annex II, or to at least map those headings to the relevant parts of other documents, as in Twilio’s data protection addendum. However, both AWS and Google have chosen simply to cross-refer briefly to the security measures set out in other applicable terms, for example, in the case of AWS its data processing addendum. Google in addition generally states in its C2P and P2P SCCs that its security standards must be “at least as protective” as those set out in such other terms, and also cross-references terms setting out the security measures to be taken by Subprocessors. But, in its C2C SCCs (e.g. for ads, other), Google has set out specific security measures in Annex II, not mapped against the 2021 SCCs’ Annex II example headings but following some of the ISO 27001 headings (covered next).

How much detail should be given? The SCCs of the organisations mentioned above provide a few examples. Some borrow descriptions from industry standards such as ISO 27001, 27017, 27018, as McAfee has done in its enterprise data processing agreement for customers and SCCs for suppliers (and as set out for instance in EU security agency ENISA’s Guidelines for SMEs on the security of personal data processing, which also use ISO 27001 headings and subheadings). For example, under a heading of “Access control”, include sentences such as “Specific access control rights must be allocated to each role (involved in the processing of personal data) following the need to know principle”. Even organisations that are not ISO-certified should be able to use at least some of the statements from such industry standards in Annex II. Cloud providers would of course emphasise the shared responsibility model and make clear which aspects are for the customer to implement, such as in AWS’s data processing addendum section 5.2.

There is another issue with Annex II. The example headings also include certain measures related to obligations imposed on controllers (but not processors) under the GDPR. For example, Measures for ensuring data minimisation, Measures for ensuring data quality, Measures for ensuring limited data retention, Measures for ensuring accountability, Measures for allowing data portability and ensuring erasure, Measures for ensuring ongoing confidentiality, integrity, availability and resilience of processing systems and services.

How are such measures to be described, for transfers to processors or subprocessors? Presumably those measures are only “Examples of possible measures”, as stated in Annex II itself, so they are not mandatory for processor/subprocessor importers. Cautious processor/subprocessors, such as cloud providers, could still seek to complete them, by stating they are the responsibility of the controller, and/or that self-service tools have been provided for the exporter to delete, update and port its data or similar.

Annex III

The list of authorised subprocessors in this Annex is meant to be completed only when specific prior authorisation to subprocessors is required for C2P or P2P transfers under the SCCs’ Clause 9(a) OPTION 1, as opposed to general written authorisation under OPTION 2.

It’s interesting that, although Google has chosen general authorisation in Clause 9(a), so that Annex III is not required, it has nevertheless decided to include an Annex III with links to its relevant lists of subprocessors.

Supplementary measures

While this article does not discuss the EDPB supplementary measures, there is one point to raise here in relation to both the Commission and EDPB, namely the interaction between the 2021 SCCs and the EDPB recommendations.

Would signing the 2021 SCCs be sufficient to meet all or some (and if so which) of the EDPB recommendations on supplementary measures, such as those regarding any government access requests made in the importer country (SCCs Clause 15)? Some of the SCCs do wholly or partly meet the EDPB recommendations. Can a robust approach be taken here, in the case of partial matches, to assume those recommendations can be met, and if so, which ones?

Summary

To conclude, the above are just some issues by way of illustration – there are quite a few more that I haven’t covered. That even huge, sophisticated companies like AWS and Google take different approaches when trying to complete the 2021 SCCs illustrates the scale of the practical uncertainties arising, and underlines the importance of clarifying the issues outlined (and more).

I urge the Commission to address, if not in a future iteration of the 2021 SCCs at least in its FAQs the following (and other SCCs issues) in the promised practicable manner, and perhaps in liaison with the EDPB:

• Provide further SCCs modules, not just for transfers to non-EEA established importers caught by Art.3.2 GDPR, but also for: 
• SP2P transfers, by EEA subprocessors “back” to non-EEA processors
• Transfers to non-EEA importers processing personal data in the context of an EEA establishment’s activities under Art.3 GDPR.
• Expand on the Art.28 terms overlap and clarify the non-compliance notification and termination provisions.
• Clarify the approach to Clause 13 on specifying the SA.
• Explain the purpose of the odd Annex I final sentence.
• Provide some concrete examples of acceptable Annex II security measures descriptions, and clarify the position regarding “controller”-type measures.
• Clarify the relationship between the 2021 SCCs and the EDPB recommendations.

In addition, I hope the future online FAQs will be versioned with tracked changes, downloadable previous versions and dates, so that practitioners can follow exactly which change was made when.

We will all look forward with interest to the issue of the first set of Commission FAQs in early 2022!

Note

[1] For example, the Art.28 SCCs’ Clause 7.1(a) qualifies an obligation, to process only in accordance with the controller’s documented instructions, with “unless required to do so by Union or Member State law to which the processor is subject. In this case, the processor shall inform the controller of that legal requirement before processing, unless the law prohibits this on important grounds of public interest.” Transfers are also permitted “in order to fulfil a specific requirement under Union or Member State law to which the processor is subject… ” (Clause 7.8(a)). Even the EDPB acknowledges that “A processor may process data other than on documented instructions of the controller when the processor is required to process and/or transfer personal data on the basis of EU law or Member State law to which the processor is subject” (para.121, Guidelines 07/2020 on the concepts of controller and processor in the GDPR).

This reflects GDPR Art.28(3)(a)’s wording, is clearly limited to the requirements of EU/Member State law (not third country law), and EU/Member State law could conceivably compel transfer by a processor to a third country in some circumstances. However, that  qualification, allowing processors to transfer personal data when so required under EU/Member State law, is completely missing from the 2021 SCCs. Other differences between the Art.28 SCCs and 2021 SCCs are flagged later