International data transfer madness: listing 4 misunderstandings and mistakes

The law is quite commonly misunderstood, and privacy legislation seems to hold the throne. Privacy seems to be the hardest word (contrary to what Elton John likes to tell us) out there, and it harnesses fear within organizations. Fear leads to stress, stress leads to rash decision making. Boo for rash decision making.

Especially when it comes to the terrifying “international data transfer” there’s a lot of misunderstanding as to the safeguards that need to be taken, and when. When there’s an “international data transfer” (transfer of personal data from within the European Economic Area (“EEA”) to outside the EEA), one needs to comply with Chapter V of the General Data Protection Regulation (“GDPR”). This chapter provides several mechanisms to safeguard a transfer. One way is to conclude standard contractual clauses (“SCCs”). This basically is a contract that the European Commission drafted and said: you know what, if you conclude this you’re good to go (kind of). The how and when of these SCCs seems easy – it is a contract to offer and acceptance, right? – but appearance can be deceiving.

Therefore, I’d drafted this blog, to go over the most common misconceptions. Don’t make the mistake to think: “Caroline, this is too obvious, what are you on about?”. People, including lawyers (who are also people), fail to recognize these situations, or do not want to recognize them, because it is often paired with complex data flows, and it’s even more complex to allocate responsibilities over the data processing. Let’s break it down. 

1.    Data sharing from outside the EU to inside the EU is considered an “international data transfer”

I often see the request to conclude SCCs for a data flow from for example the United States, to the European Union. Two things are mixed up in this situation: 1) the extraterritorial scope of the GDPR and article 28 GDPR, and 2) the requirement to either conclude SCCs or any other action in Chapter V. If you’re outside the EU and monitoring data subjects, the GDPR can be applicable, and you need to comply with it in full and conclude a data processing agreement (“DPA”) if sharing personal data (article 28 GDPR). But that doesn’t mean when you work with an EU entity and sharing personal data, it constitutes an international data transfer as meant in Chapter V of the GDPR. Better yet, there is no module of the SCCs covering this situation, as being a ‘data exporter’ always implies you’re situated in the EU. If you want to dive deeper, check out the Guidelines of the European Data Protection Board. 

2.    If your processor works with a third party outside of the European Economic Area, you need to safeguard that transfer

Often I come across companies that conclude the SCCs for a transfer that their supplier initiated. This would for example be the case if an organisation concludes SCCs with their Dutch HR bureau, which works with Microsoft (in the US). That international data transfer happens between the HR bureau and Microsoft, not between the company and the HR bureau. Of course, you can add wording to your DPA about (not) wanting cloud providers from outside the EEA, but you cannot “safeguard” a transfer if you do not carry it out. This little misunderstanding might be a relic left over from the former SCCs, that did not have a version that covered the processor – sub processor relationship. 

3.    SCCS are the only mechanism to safeguard transfers

Don’t forget the other possibilities! I’ve seen requests to conclude SCCs with the United Kingdom, or with Canada. Chapter V of the GDPR provides for more than one way to safeguard international data transfers. One of them is that the European Commission has stated: you know what, this country seems quite all right, their laws and practices bring about sort of the same data protection as we want to give people in the EEA, go for it. Such decision we call an adequacy decision. Right here you can find the latest information on which countries are deemed adequate.

4.    Safeguarding your international data transfers is the only thing to do

If you safeguard your transfer by concluding the SCCs, you’re not done, unfortunately. The SCCs require us to take a look at the laws and practices in the importing country, and check if nothing stands in the way of this organisation complying with the SCCs (clause 14 SCCs). Nowadays people refer to this as a Data Transfer Impact Assessment (“DTIA”). Apart from this, if the GDPR is applicable to the organisation as a whole, the rest of the GDPR should also be taken into account. For example, if you want to refrain from using Google Analytics on your webpage because it might constitute an unlawful international data transfer, don’t forget that in general, tracking technologies may only be used after obtaining GDPR-compliant consent first.

In general, just remember:

• it’s about ensuring that the European bar for data protection is safeguarded not only within the EEA, but also outside the EEA. Data protection shouldn’t end at the borders of the EEA;
• data flows can be tricky, especially with SaaS providers, but remember that legal frameworks solely want to allocate responsibility over this data wild west we’ve created. So which party involved is the one who most logically has to safeguard the transfer?

Long story short: the law is settled in a way that you cannot run from European data protection rules by simply transferring your data to a different place. But don’t start the hassle of negotiations over a situation that is not considered an international data transfer as meant in Chapter V GDPR. Be that critical thinker we know you are. 
Or call us.