Webinar Replay: Life After Schrems II (12 min)

Webinar Transcript
Life After Privacy Shield - Strategies for Lawful Transfers of Personal Data from EU Countries to the U.S.

Life After Privacy Shield Schrems II Requires New Technology Controls
Gary LaFever Gary LaFever (Anonos)
The European Data Protection Board, as Christian mentioned in November of last year, issued preliminary recommendations, which will be followed up very soon with their final guidance. And in that, they identified three different types of supplementary measures - that being contractual, organisational, and technical. But they make very clear that only technical supplementary measures would be effective against a third country, a foreign government. And actually, in the first few sentences of the executive summary, they explain why. And in their interpretation of the decision in Schrems II by the Court of Justice, they feel that the protections needed to travel with the data and in traveling remain effective. The problem you have with contractual supplementary measures and organisational supplementary measures is that if a third country is not a party to the contract and is not a part of the organisations involved, those measures don't work. And so, the focus of my discussion is on technical supplementary measures. And really, Pseudonymisation is the technical supplementary measure that is highlighted by the EDPB to protect data when in use and I'll touch upon that. But really, what this is about is the difference between Trust Me, which is a promise, and Forgive Me, which is an excuse. And the Court said in Schrems, “That's not good enough anymore.” The Primary Focus of Cybersecurity Is Protecting Data At Rest and In Transit This may seem rather simplistic - and yes, I'm going to have a number of cartoons in my presentation. But I've actually found these simple concepts are oftentimes very difficult for lawyers to grasp because they are technology issues. And so, I'm going to hit them very quickly. Cybersecurity technology measures have been around for decades, and that's what the EDPB is talking about in Use Case 1, which is use of encryption to protect data when at rest, and Use Case 3 when they're talking about protecting data when in transit. So, technology has been around for decades to protect data when at rest (the soccer player resting on the field waiting for the game) and in transit (in the bus on the way home from the game). The GDPR Required Protection of Data When in Use However, the GDPR requires that you protect data when in use. This is not encryption. This is actually Use Case 2. So, Pseudonymisation oftentimes is not fully understood and was totally redefined within the GDPR, and this is highlighted in paragraph 80 and footnote 69 of the EDPB report. It requires that the data be protected when in use. This also is an example of Data Protection by Design and by Default, Purpose Limitation, and Data Minimisation. So, again, we're talking about technical controls for the data when in use. Protecting Data When In Use: A Driving Analogy So, some more cartoons. Very quickly, the difference between policies and technical controls. Let's pretend for a moment that the purpose - the intended purpose for this car is to drive down this road and take a right. That's the purpose. You can have all the contractual and the organisational supplementary measures you want, but the next slide highlights how effective those are. Speed Limits (Policies) Do Not Prevent Accidents Policies, words alone, whether it's in the form of a contract or a treaty did not stop the car from driving off the cliff. So, you see there's a caution sign. There's a speed limit sign. It's there to represent policies. The Court held and the EDPB has held you need technical controls. Physical Controls (Guardrails) Do Prevent Accidents Technical controls prevent unintended consequences, and they travel with the data. So, this is a new approach to ensure that the data is protected no matter where it goes. Encrypting Data Does Not Enable Lawful Use This is not encryption. Encryption is a wall across the road. You can't make use of the data. So, I apologise for the rather simplistic cartoons. The EDPB said that contractual supplemental measures alone will not be sufficient. Organisational supplementary measures will not be sufficient. When it comes to issues of third country access, technical measures to protect the data when in use are required. Schrems II: Policies Alone Do Not Prevent Accidents Here's the issue. It has been 8 months since the Schrems II decision. And the quote to the left, “Ignorance is not bliss, it's negligence.” And if you follow the footnotes, they are footnotes to a number of different European accounting agencies that lack of action with respect to a known obligation actually can amount to personal and criminal exposure for Chief Executives, Senior Executives, and even Board Members. And the Court of Justice says five times within the ruling that the appropriate remedy for infringement is actually not even penalties. It's the termination of processing, and this was touched upon earlier. We are talking about the violation of constitutional rights of the EU citizens. You can't buy those back with money. And so, the idea is the potential for termination of processing is a self-inflicted operational disruption. So, the assessment of technical tools is absolutely paramount. Schrems II Highlights Requirements for New Technology Controls to Protect Data When in Use And so, in essence, you've gone from Cybersecurity, which was talking about protecting data when at rest and in transit, which is still important. Don't get me wrong. It's reflected in Use Cases 1 and 3 by the EDPB. To protecting data when in use, which under the GDPR is embodied within the concepts of Data Protection by Design and by Default and Pseudonymisation. To under Schrems II, the need to protect data when in use, and if not, the termination of that infringing processing and the EDPB recommendation in Use Case 2 to pseudonymise the data. So, we'll talk very briefly about what this term means. The GDPR Redefines... I'm going to teach everyone one of my tricks, and people thank me for this when I meet them in person. Pseudonymisation is a hard word to say and spell. And so, I always remember I'm standing in front of a room speaking, and my friend comes through the door and back to the left. Her name is “Sue.” And then, her friend comes through the right. His name is “Don.” Pseudonymisation. This is not pseudo-anonymisation. Pseudonymisation has very specific statutory requirements, again, noted in paragraph 80 and footnote 69 of the EDPB Guidance. European Data Protection Board Recommends GDPR Pseudonymisation The importance of Pseudonymisation Use Case 2 is it actually can remedy much of - I will not claim all, but much of the illegality of Use Case 6 and 7 because you'll see in Use Case 6 it's processing of data in the clear. You can process pseudonymised data in the cloud lawfully. Use Case 7 - remote access to EU data for business purposes. That is access to data in the clear. If the business purpose can be satisfied and achieved in both Use Cases 6 and 7 using pseudonymised data, there's not an issue but you have to pseudonymise the data in accordance with the heightened requirements of the GDPR. EDPB Recommends GDPR Pseudonymisation So, what is it that Pseudonymisation requires? I look at it as you have to be able to show that you have functionally separated the information value - that's the reason you're processing the data - from the identity of the data subjects. Now, bear in mind, pseudonymised data is still personal data, but it is personal data that does not reveal identity without access to additional information that is kept separately and securely. So, looking at this graphic, you must be able to show statistically with auditable evidence that it is not possible to go back and forth over that wall between information value and identity but for access to the additional information that is kept separately, and this is imperative because that additional information oftentimes referred to as keys for international data transfer purposes can be kept in the EU. So, if what you're sending to be processed whether literally across the Atlantic or figuratively across the Atlantic because you're processing it in, let's say, a US operated cloud, it cannot be relinked to the identity of the EU data subject without access to the additional information that is kept in the locked courtyard below. Maturity of Technical Controls for Data When in Use Determines Schrems II Compliance Strategy What we find working with companies is there's a three-step approach to Schrems II compliance, and companies that have difficulty with complying with Schrems, oftentimes, what they discover is the reason for that difficulty is because they actually have been so busy with all the other obligations - data inventory assessments, data protection impact assessments, preparing for 72-hour breach notification, etc., etc., new consent management platforms - that what they didn't do yet is put in place the technical safeguards you need to control data when in use. This is an obligation that applies regardless of whether the processing is within or outside of the EU, and it's otherwise referred to as Data Minimisation, Purpose Limitation, Data Protection by Design and by Default. That's what we refer to as Step 1.

Once you've achieved that level of control of data when in use, what you're then positioned to do is actually have the technical controls you need in place to do further processing - processing beyond the scope of consent and contract, which are very strictly constrained under the GDPR. Legitimate Interest Processing is available if you pursue it from a protection technique. It is not a test of whether you have legitimate interest in the outcome. It's whether or not you have enforced legitimate interest controls in the process, so that you can show you have mitigated the risks of the data subjects. So, in balancing the interests of the data control and the data subject, the risks of the data subject are so mitigated that the data controller’s rights prevail. That is what we refer to as Step 2. Having put in place the technical controls necessary to satisfy our obligations to 1 and 2, the third step is actually a very small step. What you're doing is using the same technical controls to ensure that as the EDPB says the controls flow with the data. Therefore, the protection flows with the data so if intercepted or otherwise acquired by a third country, they do not reveal identity. 98%: GDPR Pseudonymisation Enables Schrems II Compliance for Vast Majority of Use Cases The important thing to realise here is that Pseudonymisation is not going to take care of 100% of your processing. But in our experience, it can take care of 98%. The circular ones around the outside, which we will refer to as edge cases, you're going to have to have a derogation or another arrangement to handle that. But we have found that that is available typically if you've processed the bulk of your data processing by Pseudonymisation. Centralized Controls for Context Specific Decentralized Protection And so, what Pseudonymisation does, as opposed to anonymisation which is on-off binary, can you or can you not re-identify someone, Pseudonymisation is very use case and context specific to enable you to achieve your business goals in a way that is both GDPR as well as Schrems II compliant. Thank you.