On Nov. 12, 2020, the European Commission published a draft implementing decision on new standard contractual clauses for the transfer of personal data to third countries. The clauses try to reflect what is required under the "Schrems II" judgment and also to help those transferring data incorporate safeguards for data transfers that go above and beyond the current SCCs. They also address known deficiencies in the current SCCs — catering for data transfers by EU processors to sub-processors and from EU processors back to their instructing controller.
The commission has tackled a difficult topic with skill and insight and has introduced significant improvements to the current SCCs. There will, however, be a significant job for parties to move to the new clauses to resign agreements, provide enhanced transparency to data subjects, and flow down new terms to third parties and sub-processors. The clauses propose allowing a one-year transition period for this to be done and are open for consultation until Dec. 10.
Heavy influence of 'Schrems II'
The clauses are drafted to take account of and work with the "Schrems II" judgment. As one would expect, the draft implementing decision refers extensively to the judgment and also to the European Data Protection Board's (draft)
The clauses retain the principles in the current SCCs that were considered positively by the Court of Justice of the European Union in “Schrems II” and were the basis for the CJEU's decision that the SCCs should remain valid. These principles are: an obligation on the data exporter (assisted by the importer) to consider the level of protection of personal data in the third country; an obligation on the data importer to notify the data exporter of any inability on the part of the importer to comply with SCCs; and a corresponding obligation on the exporter to suspend data transfers, terminate the agreement or notify the SA if it continues to transfer personal data having received such a notice.
The new clauses incorporate further elements from “Schrems II.” In particular, the data exporter is required to document the transfer impact assessment it carries out and make this available to the competent SA on request (Section II.2(d)). The clauses set out the factors that the data exporter must consider in a transfer impact assessment. In addition to considering the law and practice in the third country, the draft clauses also helpfully reference the duration of the contract; scale and regularity of transfers; length of processing chain and transmission channel used; type of recipient; purpose of the transfer and nature of the data transferred.
The new clauses also include stronger commitments on the data importer vis-a-vis attempts by public authorities in the third country to access EU originating personal data. The data importer must, where possible, notify both data exporter and data subject that it has received a request by a public authority to access such data; it must assess the legality of any such order by reference to the law in force in the third country and, where it considers it has grounds to challenge the order it must do so; where possible it must seek an interim measure to suspend any requirement to disclose data while the challenge is pending; and it must also disclose the minimum amount of personal data reasonably possible in response to an order.
The importer must document these requests and steps it follows and make these available to the exporter. It must also prepare a transparency report (i.e., more general information about the nature of requests received). Readers may recognize these obligations — they are included in the EDPB’s draft recommendations. The commission has not included all of the EDPB’s suggested supplementary measures; in particular, the suggestions relating to “warrant canaries” and “no-backdoor warranties” have not been included.
The requirement in the clauses that the importer should document requests and make documents available to the exporter can be found in the EDPB’s list of organizational measures, as can the requirement that a processor importer should apply access controls to personal data strictly, only allowing access to personal data where strictly necessary to perform or manage the contract. The annex of technical measures could also include references to encryption or pseudonymization — again, methods recommended in suitable cases by the EDPB.
These new provisions will increase the likelihood that, in appropriate cases, a data exporter will be able to use the clauses to undertake transfers without needing to put in place additional safeguards.
Where additional safeguards are needed, then the commission strengthens the role to be played by SAs. If a data exporter has reason to believe that a data importer cannot fulfill its obligations under the clauses, either because the importer has been notified of this or it has reached this conclusion itself, then the data exporter may only continue transferring personal data if it puts in place additional safeguards. However, if a data exporter takes this approach, it must notify and provide full detail of the safeguards adopted to the SA.
What happens to existing SCCs?
The draft implementing decision provides a one-year sunset period for parties to put the new clauses in place. During this period, transfers can continue to be made on the basis of existing SCCs, unless those contracts are changed. If the contracts are changed, then the parties lose the benefit of the sunset provision and must move to the new clauses. If parties change existing contracts to introduce additional safeguards as required by "Schrems II" and the EDPB recommendations, then they can still benefit from the sunset provision.
Implementing the new clauses will take significant effort — both because of the requirements associated with documenting transfer impact assessments, also because of the requirements to provide enhanced information to data subjects (see below) and to flow-down the same terms to third parties/sub-processors if there are onward transfers.
New clauses fix known gaps
The current SCCs can only be used by data exporters in the EU that are controllers. This means that there are no approved SCCs that can be used when a processor in the EU transfers personal data to a sub-processor outside the EU, thus putting EU processors at a disadvantage compared to non-EU processors, or when a processor in the EU returns personal data to the controller on whose behalf it is processing the personal data. There are also no approved clauses for use by data exporters that are subject to the EU General Data Protection Regulation but are not established in the European Union.
The new clauses address these gaps, with content for use in controller-to-controller, controller-to-processor, processor-to-sub-processor and processor-to-controller situations. They also expressly state they can be used by parties that are not established in the EU.
The new clauses are also designed to be used by multiple parties and to allow for change over time by including arrangements for new parties to accede to them via a — perhaps Star Trek inspired – “docking clause.”
New clauses impose GDPR-like obligations on data importers
The existing controller-to-controller SCCs requires the controller importer to agree to follow data protection principles based on those set out in Directive 95/46. The clauses include some new obligations in line with the GDPR. The controller importer has to agree to transparency obligations, with an emphasis on clear and plain language, as in Article 12 of the GDPR. Access, erasure and rights to object to processing for direct marketing are also included.
One of the innovations of the GDPR was to include an accountability principle and both controllers and processors have to agree to demonstrate their compliance with the clauses; processors also have to keep records of the processing which they carry out on behalf of the controller.
However, the clauses do not seek to impose obligations that are identical to those in the GDPR. Controller importers do not have to agree to implement portability or restriction and restrictions on automated individual decision making remain closer to those in Directive 95/46 with an emphasis on safeguards and a right to object rather than those in the GDPR. Similarly, the clauses are not (generally) prescriptive as to how accountability is achieved — so the specific provisions in the GDPR relating to records of processing activity and data protection impact assessments are not included.
What could the clauses do better?
There can often be uncertainty as to what extent parties can introduce supplemental terms without falling foul of the prohibition on contradicting provisions in the SCCs. The commission has tried to make clear that additional clauses can be used, so long as they do not contradict the clauses or undermine protections for individuals.
However, this is an area where uncertainty is likely to remain.
While there is uncertainty around this, it will make using the clauses more complex than needed and will divert attention away from substantive matters toward constant rounds of signatures. By way of example, one SA has expressed concerns to the authors that even the seemingly uncontroversial change of adding a counterparts clause, allowing parties to sign separate physical documents, could invalidate the SCCs. It would be helpful if the commission could do more to reduce this uncertainty — by including more optional clauses and making clear clauses that are concerned with process, rather than substance, do not contradict the clauses.
Where an EU controller transfers personal data to a non-EU controller, then the clauses introduce onerous transparency obligations. The importing controller must notify the data subject of all data transfers that it intends to make to third parties — including identifying the third party and the purpose of transfer. When an EU processor transfers personal data to a non-EU processor, then the clauses require that the importer provider notices and assistance directly to the controller, rather than leaving this for the exporting processor to manage. By way of example, if the importing processor wishes to appoint sub-processors, then it must provide notice of this to the ultimate controller. It is likely that the exporter will already include the importer’s sub-processors in its list of approved sub-processors, which are already notified to the controller under Article 28 of the GDPR. This could easily lead to duplication and confusion.
The docking clause concept, to allow for new parties to join, is helpful. However, the mechanism by which new parties join is not clear. The clauses say the new party may accede by completing a new data transfer Annex, “by agreement of the Parties.” It is not clear how the existing parties would give agreement — any mechanism that requires multiple existing parties to sign an agreement will quickly become unwieldy and undermine the welcome flexibility which this introduces. It would be helpful if the implementing decision noted that it is for the parties to determine, at the outset, how this agreement may be documented — thus allowing solutions to be used which best fit the circumstances.
The clauses provide that, from the date of accession, the new party shall have the rights and obligations of a data exporter or importer, as applicable. From a good drafting perspective, the clauses should also state that the parties transferring data to or receiving data from the new party shall undertake the obligations of data importer or data exporter, as applicable, in relation to the new party. We have also noticed a small number of other drafting glitches, some of which are flagged in the table below.
Where the clauses cover transfers to a processor or sub-processor, they inevitably cover the same ground as Article 28 data-processing agreements. This will lead to potential duplication or inconsistency. The clauses address this by containing a hierarchy provision, which states that, in the event of any conflict with other agreements covering the same subject matter, the clauses will prevail.
There will inevitably be questions over this. By way of example, the clauses follow the GDPR in requiring that a processor provide notice of a personal data breach “without undue delay”; a data-processing agreement may stipulate a precise time period. In this example, there is probably a good argument that a more precise period is not in conflict (unless the period would involve undue delay), but one can imagine the kind of debate that will arise on this. There is no easy way of addressing this, and the commission proposal seems a good way forward to us, providing certainty without overriding all previous terms that have been put in place. However, this will no doubt be an area where comments are made during the consultation process.
What do the new clauses look like?
Because the new clauses address controller-to-controller, controller-to-processor, processor-to-processor and processor-to-controller transfers, they look very different compared to the current SCCs — where there are separate, freestanding, agreements for each type of data transfer. The new clauses contain certain content that is applicable to all situations — for example, introductory provisions, provisions on noncompliance and termination. They also contain modular content that is only applicable to that specific type of transfer (controller-to-controller, controller-to-processor, processor-to-processor and processor-to-controller transfers). As a result, they feel very different from the current SCCs — practitioners will need some time to get used to them.
The structure is:
Section 1 — General: General introductory provisions, third party rights, details of transfers covered, accession mechanism.
Section 2 — Modular: Substantive data protection obligations; transfer impact and associated obligations.
General with edits: Redress, liability, indemnification, supervision.
Section 3 — General with edits: Termination, governing law and jurisdiction.
For those who want a deeper analysis of the new clauses, the table below sets out a full summary and also shows how the modular provisions compare to each other. For brevity, in the table, we have used "DS" for data subject and "SA" for supervisory authority.
Photo by Yannis Papanastasopoulos on Unsplash
