1. What are SCCs and why do we need them?
Given the high standards of data protection under the EU (and UK) GDPR, when data is transferred outside of the EU then these standard need to be maintained. The European Commission has recognised some countries and business sectors as having “adequate” status because their laws provide sufficiently equivalent protections. For other international transfers we need to put in place other safeguards, one option for which consists of signing officially approved, standard contractual clauses. For the EU (and EEA and UK) there have for some years existed sets of clauses for international transfers from controllers to processors, and controllers to controllers (Set I and Set II). Now, for the EEA, the European Commission has published a new set of standard contractual clauses for all international transfers.
2. Why are the existing SCCs being replaced?
Replacement of the existing clauses is seen as necessary because of: (1) new requirements brought in by the GDPR; (2) significant changes in the “digital economy” (new and more complex processing, multiple parties in longer chains etc.); but most urgently and essentially (3) the European Court’s judgment in Schrems II, under which the existing SCCs may need supplementary measures to support transfers to destinations where government surveillance potentially goes beyond what is seen as necessary in the EU.
3. Is this the same as a Data Processing Agreement?
The new clauses are designed to also over the GDPR requirements for Data Processing Agreements (DPAs), so we won’t need a separate DPA. This will be a fairly significant change to the established practice of signing a DPA with an optional annex for international transfers – now we’ll most likely need our own DPA for EEA/adequate country transfers and these SCCs to cover other international transfers. And although we can include other clauses with the SCCs, we are not permitted to amend or contradict them, so this will now also apply to the DPA provisions.
The European Commission also published at the same time a set of clauses which make a standard DPA for controllers and processors within the EEA (or any other adequate country). These are optional and perhaps not likely to be so much used, as most businesses who are in a position to use their own terms have their own tailored DPAs by now (and various national Supervisory Authorities have also published standard DPAs).
4. What situations do these SCCs cover?
In a significant improvement we now have one document containing “modules” capable of covering most data processing relationships :
Module One: Controller to Controller
Module Two: Controller to Processor
Module Three: Processor to (sub) Processor
Module Four: Processor to Controller
This is welcome, as for processor to (sub-)processor transfers, there were no clauses that could expressly be used, leading to attempts to overcome this by just using controller to processor clauses, committing to sign SCCs with the controller (who one of the parties often didn’t have a relationship with), or by seeking to make the exporting processor the data controller’s agent.
Module Four (processor as exporter, controller as importer) will probably be the least common – as it stands it doesn’t seem intended to catch the mere transfer back to a non-EEA controller of data processed by an EEA processor. A hint is in the recitals where the provisions on local laws indicate that no assessment of local laws is required unless non-EEA data is combined with data subject to GDPR and then transferred.
We don’t have to use the new clauses “as is” and in fact we should delete the parts that don’t relate to the module(s) we are using.
5. What if we are located outside the EU/EEA?
The new causes can expressly be used to cover transfers or onward transfers from a non-EEA entity to another non-EEA entity which is another welcome clarification. So at present is does seem that these SCCs cover all situations that we could be contemplating.
On the other hand, the recitals to the new SCCs indicate that they should not be used when the importer’s activities are already directly subject to the GDPR.
6. Can we add multiple exporters or importers?
The new SCCs have a “docking clause” which allows new parties to adhere to them as additional data exporters and/or data importers. All that is needed is for the new party to compete and sign the relevant annexes (this must be with the “agreement” of the other parties, but that can be separate and it’s not necessary to sign an entire new set of SCCs).
7. What governing law do we use?
One potentially important detail is that data subjects must have rights under the new SCCs as third party beneficiaries (i.e., they can enforce and claim benefit under our contract even though they are not parties to it). This means that while we are in principle free to choose a governing law of an EEA state for the SCCs, in practice it must be one that permits this. Some legal systems have strict rules on privity of contract which don’t allow this (including – as a general rule – Irish law) so in principle those laws are not a choice open to the parties (which given the importance of Ireland as an EU headquarters for many technology companies presents an interesting conundrum).
8. Can we negotiate liability & indemnity clauses?
The new clauses contain express clauses providing for liability and indemnity: “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.” and that … “if one Party is held liable [towards a data subject], it shall be entitled to claim back from the other Party/ies that part of the compensation corresponding to its/their responsibility for the damage.”
As under the existing clauses we are allowed to add provisions that don’t contradict the SCCs. This would seem to indicate that any limitation of liability between the parties could be unenforceable for “contradicting” what we have in this section. To be discussed…
9. What happens if laws in the destination conflict with the SCCs?
This is the part that we are really interested in. The Schrems II judgment, some Supervisory Authorities’ reactions, and recommendations from the European Data Protection Board (“EDPB”), made it look as if transfers to “problematic countries” were going to be near impossible to manage for many common processing operations.
The new SCCs couldn’t and wouldn’t make these issues go away. However, they do introduce some flexibility by requiring a risk-based approach. And of course we have to remember that these SCCs are not intended only for EEA-US transfers – they will be used for all other “non-adequate” countries which may throw up fewer or different issues in their local laws.
The main requirements are:
a) the parties need to warrant that they have no reason to believe that the laws and practices of the destination prevent the importer from complying with the SCCs.
b) however ignorance is not sufficient: the parties also have to declare that they make the warranty having taken account of:
- the circumstances of the transfer;
- the laws and practices of the destination; and
- any contractual technical or organizational safeguards agreed.
This is being called the “Transfer Impact Assessment” or “TIA”.
c) the data importer needs to use best efforts to provide relevant information for the TIA.
d) the parties need to document the TIA and if requested provide it to the Supervisory Authority.
e) the data importer needs to notify the data exporter if the TIA is not (any longer) correct.
f) if notified, or based on any other reason, the data exporter needs to identify additional protective measures, suspend the transfer, or otherwise terminate the contract.
This is not unexpected – the Schrems II decision made it clear that when dealing with problematic destinations, contractual measures would be unlikely to create sufficient safeguards, and so since then we have been looking at how to put in place reasonable supplementary measures. Now, the European Commission, in adopting a risk-based approach, has left the door open for other factors to be taken into account, e.g.:
1) in relation to the circumstances of the transfer: the length of the processing chain, the number of actors involved and the transmission channels used; intended onward transfers; the type of recipient; the purpose of processing; the categories and format of the transferred personal data; the economic sector in which the transfer occurs; the storage location of the data transferred; and
2) in relation to the laws and practices of the destination: practical experience with requests for data from public authorities or the absence of such requests. This should be properly documented and corroborated but does allow the parties to bring in some realism, particularly in relation to data that objectively has little relevance to national security.
This will inevitably be a snapshot as at the time of the assessment, and the parties need to keep this under review and proactively take action to pause or terminate transfers if things change. But it is very far away from the original EDPB recommendations describing “scenarios in which no effective measures could be found”, including very common ones such as transfers to cloud services providers or other processors which require access to data in the clear, or remote access to data for business purposes. The finalised EDPB recommendations accept the risk-based approach though with some typically careful warnings that assessments based on experience need to be documented (and shareable – which some authorities often try to prevent).
On the other hand, there is a significant amount of work to do here. In particular, in addition to describing in detail the processing envisaged, and considering what if any supplementary measures to add, the parties will need to obtain up to date advice on the reality of law and practice in the destination country. It’s possible that this may over time become more formulaic, as standardized descriptions appear and are reused (and possibly industry associations might begin to produce these for their members). However, for many, there will be a significant additional cost of doing this – essentially signing SCCs won’t now be feasible without a lawyer somewhere in the process.
10. What if we receive a request from an authority for data that is subject to GDPR?
If the data importer gets a request for data from or becomes aware of any access or interception by public authorities, then it should notify the data exporter and if possible the data subjects (or for Module 3 the data controller). If we are prohibited from making such notification we should try to get that waived; and where permitted provide regular information on requests received.
Here, also there is more. The data importer must review the legality of the request and challenge it if there are reasonable grounds, pursue possibilities of appeal seek interim measures to prevent disclosure pending a decision on the challenge, and document the legal assessment and provide it to the data exporter. Overall, we have to provide the minimum amount of information permissible. All of this is likely to be expensive, time consuming, and burdensome for most data importers. Simply acceding to such requests on costs or expediency grounds is not acceptable.
11. Can we continue to use the old SCCs?
If we are signing new agreements from 27 June 2021 and before 27 September 2021, we can either (i) use the new SCCs; or (ii) continue to use the existing clauses.
If we are signing new agreements after 27 September 2021, then we are obliged to use the new SCCs.
Any agreements signed using the old clauses will need to be updated to the new clauses by 27 December 2022.
The new clauses will take some processing, and there is plenty of work to do on documenting the relevant laws and practices, so many may choose to continue with the old clauses (as long as the processing is unchanged and they provide appropriate safeguards – so even here we should be taking account of Schrems II) and commit to updating to the new SCCs during 2022.
12. What other details are required?
The Annexes are slightly changed from those used under the current SCCs. Annex 1 has the parties’ details and description of the transfer, but also should identify the responsible supervisory authority (where the data exporter is located, has its EEA representative, or otherwise where some of the relevant data subjects are located), and the data importer commits to that jurisdiction and to work with that authority.
Annex II is for the agreed security measures (which should be specific and related to the relevant data). A list of possible generic categories of security measures is given (and may be useful as a checklist in developing our external facing IT Security policies).
Annex III is for the approved subprocessors, and the required information is more specific than typically seen today, needing a contact person and description of the processing to be carried out.
13. Will the new SCCs work for transfers to or from the UK?
With an adequacy decision promised for the UK, no SCCs (new or existing) will be required for exports to the UK. They will also not apply for exports from the UK, as the UK Information Commissioner’s Office has said that it will publish its own SCCs later during 2021. That said, despite some discussion about the UK deviating from (or replacing) the GDPR, it seems probable that the ICO’s clauses will take inspiration from these new SCCs.
14. Conclusions
The new SCCs cover most possible data transfer situations and resolve some of the practical doubts arising under the old ones. And they will allow us to take into account the actual risks associated with a particular transfer and practical experience in our industry sector when undertaking the Transfer Impact Assessment now required to address local laws in the destination country. However, this assessment and the tailoring of the clauses may mean that in future international data contracts will need additional legal input and additional time to set up, and will look significantly different from contracts used within the EEA (or with “adequate” countries).
Given this, for many situations we may prefer to keep using the old clauses until 27 September 2021 (assuming they cover our proposed transfers). After that we must use the new ones and take care to review all our existing data transfers (both from the EEA, and onward transfers between non-EEA parties of data subject to GDPR) so that we can get the new clauses in place for all by 27 December 2022.