GDPR and International Data Transfers and Processors (Part 2)

Transcript of the Video

Good afternoon ladies and gentleman, this is Anne Dibble here, data protection expert coming to you raw and uncut. I am enjoying the discussion about data processes and transfer outside of the EEA and the issue about US data controllers, US processes, etc. I did a video a few days about whether you needed a processor agreement and the standard contractual clauses, and I also talked about what happens if you are a US data controller using a US data processor. I just wanted to revisit that and update you on a conversation that I had with the ICO today after holding for, this was a record actually, I think this was one hour 15 today, but this time they didn't cut me off, which they did ... I was waiting for 45 minutes the other week, and then the cut me off and I had to wait another 15 minutes to speak to somebody. I do feel very sorry for the support desk, the helpline staff at the moment that must be a complete nightmare.

The first thing that I want to say, that I didn't cover on the video, but is fundamental, is that if you have a data subject in the EEA who is signing up for your lead magnet, or in some way giving you their personal data that is not an international transfer of data in itself. When we're talking about international data transfers, and making sure that there are appropriate safeguards in place for those data transfers, we're talking about transfers from organization to organization; so whether that be a data controller within the EU that's transferring that data outside of the EEA, or whether that is a US data controller and a US data processor. The transfer, if you like, of the data from the data subject to the data controller is not an international data transfer where you need the appropriate safeguards. That's the first part that I want to make clear.

It's not actually completely obvious from the regulations, but I think if you ... Anyway, I also just confirmed my thoughts with ICO today and they said yes, that's not what is meant to be covered by that. It's only organization to organization transfers; if they are international, i.e. within the EEA to outside of the EEA that's an international data transfer, and that's when we need to be concerned about things like is there an adequacy decision, which means that the EU has judged that the country the data is being transferred to has sufficient data protection legislation in its own right and doesn't need further safeguards. Canada is an example of that, in so far as you're sending it to corporate entities. New Zealand is another example. The US isn't, it hasn't had an adequacy decision, so what the US does have is a privacy shield, which replaced the safe harbor; but as a number of people have commented on this group, the privacy shield is currently under review as well and it is looking a little bit on shaky ground.

What the privacy shield is, is it's basically a self-certifying way that companies within the US can say we take data protection very seriously, and here's what we do, and it's enforced by the FCA, etc. Actually, there's, in terms of the size of the US and the number of companies that I imagine there are in the US, only 4400, I think approximately, 4400 companies have signed up to the privacy shield. The big ones, yes I think that the majority of people have signed up to it, but even people like Infusionsoft, who I use as my email service provider and my CRM system, they are not signed up to the privacy shield. We do have this, if you haven't found it already, there's a list ... Well it's not a list, it's a spreadsheet that people within the group have put together as to what status certain companies, a lot in the US, but around the world, the sort of big software that online businesses typically use, where they're up to in terms of whether they are part of the privacy shield, or whether they have made any statement about being GDPR compliant, whether they've got the standard contractual clauses in place, etc.

If you're wondering about your processes that you use, hopefully, you've done the data inventory in my pack, you know who you're transferring all of your data to, you've worked out which country they're in, and then you've looked at the final column in the data inventory that says okay well what is this, what is the relevant safeguard. I say the first thing to check the adequacy of the country. If that doesn't apply then if they're in the states are they part of the privacy shield. Privacy shield is really, we'll call that an adequacy in itself, so that's an adequacy decision. If it isn't an adequacy decision, then you're looking really at putting the, what is called standard contractual clauses or sometimes I call them model clauses, they're the same thing, it's just used interchangeably.

Then you're really into putting those into place, which is fine if you are an EU data controller who is transferring data outside of the EEA. They work fine in that instance and the SCCs for the data controller to the data processor are in my pack. There are also SCCs for data controller to data controller. They're not in my pack at the moment although I could add them in if anyone particularly needs them. But, if for any reason ... Let's say, if you're within the EU and you're transferring it outside of the EEA then the SCCs, the standard contractual clauses, are generally a good solution, which will mean that you won't have to go and rely on a derogation, which could be for example getting explicit consent from every data subject.

SCCs... Oh, the light just got a bit funny there in the background. Something always happens on these videos, doesn't it? Either the phone falls off, or the tripod is wonky, or gets some strange lighting. Makes it a little bit more interesting, doesn't it really?

So, if for some reason you can't enter into the SCCs then you are looking at the derogation's, okay? Because in GDPR there are other mechanisms, other safeguards, you can put into place in theory for the international transfer, but they're just not in place yet. For example, an approved code of conduct. We haven't got one of those yet, there's none of those yet. An approved certification mechanism, haven't got those yet. Then binding corporate rules, people have heard about binding corporate rules, they're really for the international organizations, the multi-nationals, they take 18 months to get approved with the supervisory authority, it costs a fortune in legal fees, and back and forth, and whatever. BCRs are really only relevant if you are a multi-national, or on that top of a scale.

So really, we're left with the SCCs and these derogations. The derogations are: article 49 if anyone happens to want to go and read them. The first one is that the data subject has explicitly consented after having been informed of the possible risks of such transfers due to the absence of an adequacy decision and appropriate safeguards. That does mean that on the derogation you would have to get explicit consent, and that would, for me, that explicit consent would need to be a tick box or something that's similarly obvious as that so that you know that you are ... So you know that the data subject has really understood the risks, and they're still happy to proceed regardless of that.

The next derogation I haven't really talked about before, and that is that the transfer is necessary for the performance of a contract between the data subject and the controller, or the implementation of pre-contractual measures taken at the data subject request. So, if you are a data controller, based in the states for example, and the issue is that the SCCs won't apply if you're a data controller based in the states, because they are written as those you are based in the EU is the problem. I covered this in the video the other day. If you are a data controller in the states and you're transferring data to a US data processor, and that data processor is not part of the privacy shield, then the next thing to look at would, in theory, be the standard contractual clauses, but they won't apply because they're written as though the data controller is in the EU.

I spoke to the ICO about this today. We looked at it, I said could we use the SCCs but just amend the clauses slightly to reflect the fact that it's a controller within the US rather than in the EU. She Googled something, and came back and said there's this specific thing that says that the standard contractual clauses can't be altered in any way. They can be lifted into another agreement, but the actual clauses can't be altered in any way. So in her view, at the ICO, she thought that you would not be able to alter the SCCs so that a US data controller could use them.

So if you are in that position, you're a US data controller using a US data processor who's not part of the privacy shield, then according to the ICO that standard contractual clauses will not do the job. Then you're left looking at the derogations. The first one, explicit consent, we just talked about that. The second one is that if the transfer is necessary for the performance of a contract between the data subject and the controller, or the implementation of pre-contractual measures taken at the data subject request. That might be where they're requesting a quote or something like that.

Now, I gave the ICO an example here. Say you've got a US data controller who is a weight loss coach; they've got a lead magnet that says sign up here for your 10 steps to whatever, a leaner weight. I'm not very good at marketing, am I? Your 10 steps to a leaner weight, I haven't really got the marketing speaker there. But, an EU data subject signs up for the free report on the US data controllers website, and that US data controller uses somebody like Infusionsoft in order to store that person’s name and email address, uses it as a CRM to send them emails, etc., so a processor within the states. Infusionsoft at the moment is not part of the privacy shield and that weight loss coach could not put in place standard contractual clauses with Infusionsoft, because as I said, it anticipates that it's an EU data controller.

So, this derogation about being necessary for the fulfillment of a contract, if you have contracts with people, so you've got customers who have signed up for a product or something like that and you're storing their details on Infusionsoft, and that is necessary for the performance of the contract. Is it necessary that maybe they've bought an eight-week program to a leaner waste, still not getting anywhere with the marketing speaking, but they put out their six-week program and you are facilitating that through Infusionsoft? You've set up a sequence in Infusionsoft, you're sending them the materials through Infusionsoft, etc. Well, that is, I think, necessary for the performance of the contract between the data subject and the controller.

For that, I think you could certainly argue that that derogation would apply, and you wouldn't need explicit consent. My questions are over what's necessary. Does necessary mean that if actually there's another processor that can do that job, but who is, for example, part of the privacy shield or is based in the EU, or whether or not it's an international transfer of data, does that mean that it's not necessary because ... I don't know the answer to that, but I'd make a good argument that it was necessary to use Infusionsoft for the performance of the contract between the data subject and the controller. I don't think, it's not necessarily clear cut, but there's an argument there.

But of course, that's only in relation to where there is a contract. If you've got just people who've signed up for your free lead magnet, is there a contract there? Again, certainly in terms of for a contract to be formed under English law, anyway, there has to be an offer, there has to be an acceptance, there has to be a consideration, and there has to be an intention to create legal relations. Is there an offer? I suppose the offer is would you like my lead magnet. Acceptance is yes please and pops their email address is. What's the consideration? The consideration arguably is the use of their email address. I don't know. I don't know if that's what this means, but there's a question mark over it. The ICO didn't know either, so what are we supposed to do?

The other derogations are is the transfer necessary for the conclusion, or performance, of a contract, concluded in the interest of the data subject between the controller and another person, but it's in the interest of the data subject. The transfer is necessary for important reasons of public interest. I mean, what on earth does that mean? The transfer is necessary for the establishment exercise or defense of legal claims. So, I mean again, there could you argue that transferring it to a processor in the US, maybe you're storing documents on Dropbox, and I think Dropbox is actually privacy shield, but say Dropbox wasn't part of a privacy shield and you're storing important documents on that processes service in the states, because you want to keep it there in case one day there is a legal claim. Is that sufficient for that? I don't know. I just don't know.

The next one is the transfer is necessary in order to protect the vital interests of the data subjects, or of other persons where the data subject is physically or legally incapable of giving consent. The final one is, the transfer is made from a register, which according to the union or member state law is intended to provide information to the public and which is open to consultation either by the public in general or by any person who can demonstrate a legitimate interest. Blah, blah, blah. It's complex, isn't it? I think that if you want to be... If you're a data controller in the EU it's fairly straightforward. If you're transferring outside of the EEA and there's no adequacy finding, not in the privacy shield, then you put the standard contractual clauses into place and there shouldn't really be a reason why you can't do that.

The US, if you're a US controller and you are transferring to a US processor, and then I think that I would ... Look, we've got to take commercial judgments here, haven't we? There's like a week and a half to go until GDPR, or something like that until GDPR comes into force. You're not going to ... Your processor is not going to be able to become privacy shield certified within that time, neither are you going to want to transfer those operations to a processor who is privacy shield compliant, so that's your risk. You're probably not going to want to obviously go and get explicit consent from every person on your database. So, it's a commercial risk appraisal, isn't it? If I were in that position of a US data controller using a US data processor that is not privacy shield compliant, then I would be speaking to that processor and I would be saying what are your plans for becoming part of the privacy shield. If they said we haven't got any then I would be looking for other suppliers and doing a phase transition as soon as I could to limit my risks in that behalf.

This isn't going to go away and although there are certainly question marks about whether the privacy shield is the right mechanics for that safe transfer of data, if that goes away it's going to be something very similar with a few more bulletins. It's not going to be a wasted exercise in trying to work with processors who are a part of the privacy shield.

If you are in a position where you're a data controller outside of the EEA, and you are dealing with processors that aren't able to be part of the privacy shield, maybe you are a data controller in India and you are using data processors in China, for example, then you're looking at the derogations. Obviously, the safest one is that the data subject has explicitly consented to the proposed transfer after having been informed of the possible risks of such transfers, etc. So, none of it is ideal and I entirely share your frustrations. I know a few of you were voicing your frustrations in the group the other day and I completely agree.

What we have to remember is that there is not, as I've said so many times, there isn't this vast, worldwide data protection police force that is going to be there on the 25th of May making sure that all of this is absolutely buttoned out. I think if you are working towards compliance and you're taking sensible safeguards with regard to ... Particularly with the security of the data, and you've vetted your suppliers, and they have the appropriate technical and organizational measures in place to protect that data, then you shouldn't necessarily lose sleep at night. I completely agree. As did the lady at the ICO who I just talked to, it's a far from ideal situation. To a great extent, of course, we are playing catch up. One of the options is that I didn't actually mean is standard ... So in terms of the safeguards. You've got the safeguards and then you've got the derogations. One of the safeguards is ... I'm sorry, examples of safeguards, binding corporate rules, standard contractual clauses, the approved code of conduct that doesn't exist yet, approved certification mechanisms that don't exist yet. I mentioned all that before.

The one thing I didn't mention is standard data protection clauses adopted by a supervisory authority and approved by the commission. She also actually mentioned, she didn't mention the bit approved by the commission, but she said she had some notes somewhere that said that you could have your own contract as approved by the ICO. But then she was saying but we haven't got any guidance as to how that process would work, she said certainly if anyone ... They haven't had one person apply for that and they just wouldn't know what to do if somebody did. So, you know, it's all very unsatisfactory really. But there you go.

This is an advanced video, okay. For those of you who have watched this far and you haven't been following the conversation about processes and international data transfers, I'm sure this will have gone way above your head. But I just wanted to feedback my discussion with the ICO, and also make that point that I did at the start about the fact that an international data transfer is an organization to organization and not data subject to an organization. So yes, I enjoy the conversation, but like I said ... I don't really ever feel like you get to a satisfactory outcome. The only comfort I can give, I'll say, is that even if you're not doing everything exactly in accordance with what the GDPR says, you're probably going to be fine. Don't say I said that though. All right, I'll see you tomorrow.