Webinar:
Briefing the C-Suite & Board of Directors on Schrems II Risk Exposure

Welcome everyone to this webinar, Briefing the C-Suite & Board of Directors on Schrems II Risk Exposure. We've had a surprising amount of interest in this webinar. You are joined with over 1000 of your colleagues,over 25% of which are new to Anonos webinars. We want to welcome everybody. For those of you who are new, over the last four months, we've held over 10 hours of live webinars featuring everyone from Anna Buchta from the European Data Protection Supervisor to Romain Robert from NOYB and a host of industry experts, including the two panelists that we have with us today. Thank you very much both for joining. So, I'd like each of our panelists to introduce themselves. Gabriela, if you would, please.

Thank you so much, Gary, and thank you for the invitation to participate in the webinar today. My name is Gabriela Zanfir-Fortuna. I'm a Senior Counsel for Global Privacy and EU Data Protection Law with the Future of Privacy Forum, a think tank based in Washington, DC, with offices in Brussels and Tel Aviv. And prior to my life in the US, I was a Legal Officer for the European Data Protection Supervisor in Brussels at the most exciting of times when we were discussing the GDPR, as well as the Privacy Shield for that matter.

Fantastic. Maggie...

Thank you. I'm Maggie Feys. I'm the European Chief Strategist - Ethical Data Use for Anonos. And in addition to that, I'm an IP, IT, and Data Protection Lawyer in Belgium at the law firm AContrario, wherewe also stress very much on GDPR compliance. And next to that, I'm also doing research for my PhD on the secondary use of medical data for different purposes. Thank you.

Thank you both. We are very fortunate to have global experts in both Gabriela and Maggie. My name is Gary LaFever. I'm both the CEO and General Counsel at Anonos, and both of those titles are actually very important because we believe in order to brief the Board and C-Suite and, in fact, in order to comply with Schrems II, you need a balanced approach between both business and law.

Today, we have an audience of very senior level executives - General Counsels, Chief Privacy Officers, and Data Protection Officers, and I believe for the first time a number of actual Board Members from major corporations globally, as well as governmental representatives, as well as a very large constituency from India. This is not surprising if you look at the fact that India is an outsourcing powerhouse and that both the use of the cloud (what the EDPB calls Use Case 6) and outsourced access to data (what the EDPB calls Use Case 7) are impacted.

So, today is about positioning you in the audience to have a better ability to brief your Board and C-Suite and quite honestly, hopefully, to make yourself the hero of your organisation. It's difficult sometimes to overcome the fatigue, the jaded attitude of many people when it comes to privacy and compliance - particularly when it comes to the GDPR. They will ask, “Aren’t we done with that?” But I think you will see that you will have fresh information and insights to bring to the Board and C-Suite to show that it actually can be about much more than just compliance.

So, a couple of housekeeping matters. Number one, thank you for joining us for today's webinar. We believe this topic, and I think the fact we have so many people attending and participating is proof of this, is going to be one of the most critical issues that you face this year. In order to keep this community and communication and dialogue open, we have a LinkedIn Group on Schrems II with over 4400 people and that's how we continue to engage with this audience. This is a very select audience. It's hard to get access to you and your colleagues, but in this Schrems II group, you have access to your peers. And so, the LinkedIn Schrems II Group is something that we highly encourage. And in fact, we will be following up by Wednesday of next week with a recording of today's session.. We're also going to provide you with a briefing template with answers questions that Board Members commonly ask our clients in meetings to help you to prepare. We will provide what we believe to be, based on our interaction with clients, the Eight Most Common Misconceptions as well as also a Legal Memorandum on insurance and its likely applicability and availability in the event of Schrems II noncompliance.

So, again, the way we interact with this community and the way we'll be following up from this webinar is through the Schrems II LinkedIn Group. And if you look, it's a very select and targeted group. It's for those that are interested in continuing to do business internationally, using primarily Standard Contractual Clauses (SCCs) with technical compliance, by means of supplementary measures or additional safeguards, so that Schrems II is not a problem.

So, I would actually like everyone right now - I know you're in front of your browser - to go on to LinkedIn and actually search for Schrems II and join the group because we want to make sure you don't miss out on additional information and interaction with your colleagues on these important measures. So, again, if you would please go to LinkedIn.It's also posted in the Zoom chat and please register. We are very selective with who we allow in this. We don't allow just everybody in. Also if you have a suggested topic or post, please suggest them, okay? All right.

So, let's go to the agenda here and this first part is critical. Briefing the C-Suite and Board is NOT - I know it's capitalised but it should be red and blinking. It's not about providing the Board or your C-Suite details on the Schrems II ruling. We will go through what we mean by that, and that is the primary objective of this webinar. But it's also very important, and we're very lucky to have two experts like we have with Gabriela and Maggie to talk about existing obligations under the GDPR for Data Protection by Design and by Default and Pseudonymisation, because those come into play. We're going to hit those at a decent level of detail today, but that's not what you're going to talk to the Board about. The reason you need that information and knowledge is so that when they ask questions, you're well positioned to answer them. And lastly, we'll talk to you about how Anonos can help you prepare to brief your Board.

All right. Let's hit it. What are the critical risks to the Board of Directors and the Executives of a company? And this is where you have to learn a different language. This is what they're most interested in - Revenues and Share Value. It's not that they don't care about privacy. They do care about privacy, but they're evaluated on Revenues and Share Value. And so, you need to talk to them in their own language. The fact of the matter is, in five places the Court of Justice of the European Union (CJEU) in the Schrems II ruling says that the appropriate remedy is termination of processing, and that has much more of a disruptive impact on companies than a fines or penalties, which can be fought for years. So, the first thing you start with is the reason this is relevant and the reason to bring it to their attention, or the reason you've been asked to come present to them, is because of the potential for material adverse effect on Revenues and Share Value, something you may not say in your common vernacular.

The second thing is that lack of any corrective action and not taking action can actually expose both Board Members and Executives to both personal and even potential criminal exposure. This varies from EU Member State. But as an example, in the version of the GDPR that was enacted in the UK, there's an additional provision, Article 198, that is not in the general GDPR. It specifically provides that if Board Members, Managers, and Executives are aware of responsibilities and they fail to take action, that they can be held liable. So, again, this is something that is very much at the top of their mind and of interest to them. Lastly, something you may not think of or have thought is the availability of insurance that Boards and C-Suites rely upon to make sure that they don't have personal issues. In the interaction that we've had with both insurers, Board Members and key executives, it is likely not - I repeat, not to be made available if the company is aware of an issue and has not taken remedial action or at minimum documented the reasons that they have not taken any remedial action. So, these are the top three things that you may not think of as a privacy professional, but it's going to be top of mind for the Board.

Okay. So, what's changed here? Well, the reality is, there's a lot of attention being paid on Schrems II in the press. Also, a number of different non-governmental organisations (NGOs) have been very active and we'll touch upon that. So, the reality is, there's further attention, almost like a spotlight that has been turned on to issues raised by Schrems II. And policies alone are not enough. Most of the companies we talked to have been advised by outside or internal advisors: “Update your SCCs.” Well, you absolutely should update your SCCs, but more than that is necessary and we'll go into detail on that. You need technical controls that help prevent bad things from happening.

So, what we'd like to do now is to ask Gabriela to kind of step back for a moment. She was featured in a recent Wall Street Journal article that talked about the importance of Big Data, and the reality that countries other than the US are making the rules, primarily Europe. So, with that, Gabriela, if you could please give us an overviewparticularly with regard to how Schrems II - even though it's a ruling by the Court of Justice of the European Union - is having an impact globally on Big Data.

Schrems II is certainly having an effect, if you want to call it that, of the high level of protection that personal data enjoys in the European Union where the legal system is truly outstanding in the sense of protecting this right as a fundamental right under the EU Charter of Fundamental Rights. And what I've been observing with the GDPR, primarily, around the world many jurisdictions are taking inspiration from the rules of the GDPR. Now, this trend actually happened or started to happen already prior to the GDPR on the basis of the former Directive and primarily, thanks to or because of, depending on what end of the spectrum you're seeing, the rules on international data transfers, right? Because the European legal framework sets us the basic principle of transferring personal data outside of Europe, outside of the EU, the fact that wherever the personal data is traveling, an equivalent level of protection should be ensured. And this is why scholars have been observing in numerous jurisdictions around the world legislation that strives to ensure this type of level of protection. Now, of course, under this framework, we've seen the Schrems II judgment last summer, which primarily decided that the existing legal framework for transferring personal data from the EU to the US is invalidated, right? The Privacy Shield. By doing so, this time around, you know, in comparison to the first Schrems judgment from 2015 actually questioned transfers from Europe to everywhere around the world, not only to the US. This is because not only the US system and the EU-US Privacy Shield were the subject of the judgment, but also the standard contractual clauses, which is the mechanism that actually allowed transfers from the EU to all of the jurisdictions that have not been declared adequate by the European Commission, right? So, therefore, whatever the court found for the SCCs absolutely affects transfers to jurisdictions that have not been declared adequate yet, at least. So, you know, think of India, as you had mentioned, and think of Brazil as well. So, I would say, this is kind of the big picture, the helicopter view. But of course, I'm happy to dig into some of the details of this.

Thank you, Gabriela. And I believe we will have some questions toward the end that we can do just that. But thank you very much for that perspective.

So, if we take a look at it, what is it about this case? What about the Schrems II ruling that actually starts to increase risk exposure? Why is it that Boards and C-Suites are asking for briefings. And the reality is, this is what from our interaction with customers we see as the top three. The first is inaction for a period of 6+ months since the ruling came down actually starts to raise an accounting issue of an ongoing concern. Does the potential of a risk of terminated access to processing rise to the level that it could actually jeopardise operations of the company? And tied with that, is the analysis inaction covered by insurance? The second one, Gabriela just very well helped to summarise, almost every global company is involved in these two types of data processing actions, which have now been ruled by the European Data Protection Board in their initial recommendations as unlawful. So, international data transfers is a broad concept that includes processing EU data in cloud systems operated by US and other non-EEA or equivalency country companies, as well as remote access to data that's in the EU. So, there are very few companies that aren’t impacted by this. And also, non-governmental organisations like Privacy International and None of Your Business have actually emerged as the new enforcers in town. And it's funny, I had someone mention to me something about privacy activists and I looked it up. And the definition of an activist is someone who supports strong actions, such as public protest, in support of or opposition to one side of a controversial issue. And so, whatever you think of organisations like Privacy International and NOYB, it doesn't seem to me that they're activists because what they're actually doing is holding companies accountable to the laws that were passed.

So, we're going to look at two examples. The first is Privacy International. It has been around for a long time, a very accomplished non-governmental organisation. About two years ago, they brought this action. And by action, it's important to realise what they did. They had a very well documented complaint that they filed with three different Data Protection Authorities and principally arguing that these companies did not have a lawful basis for processing and that their purported reason for processing was unlawful. And what's most important here because a lot of people say: “Well, there hasn't been that much in the way of enforcement. The Data Protection authorities are understaffed. They're underfunded.” These are not Data Protection Authorities. These are NGOs. So, what was the impact? One of the impacts - because these actions are still ongoing - of this very public investigation, let's look at Oracle.

Oracle, due to reputational risk and negative publicity, shattered hundreds of millions of dollars of business operations. That's right. And the quote at the bottom says it all. What had been a rather ignorable value-added solution all of a sudden became something that they wanted to get away from as quickly as possible. So, again, yes, enforcement by supervisory authorities is highly relevant, but it's not the only thing to be concerned about.

More recently, Max Schrems’ organisation, None of Your Business, brought an investigation and this investigation and the results of this are publicly available at the URL at the bottom left of your screen. They went to 33 companies from A to Z. I don't know how they picked them. But the most important thing is this could have been any company, and they sent them letters asking: “How are you complying with Schrems II?” And not a single one of the companies could answer the question. And I just wonder and I know for a fact, let me say, that a number of the companies on this list are participating on this webinar. So, when you look at this webinar slide here, do you see your company? Do you see partners? Do you see your competitors? And ask yourself, how many members of their Boards of Directors or C-Suites are aware that this is now publicly available? That Shareholders could look at that and say: “You're not taking the appropriate action that you need to take.” So, this is why I am emphasising the lack of enforcement to date by Data Protection Authorities and Supervisory Authorities is not the only thing to consider and not the only risk factor to take into account. The NGOs are holding companies accountable. They don't make the policy, but they certainly are a big force when it comes to enforcing it.

 

This is an example and I'm not picking on Airbnb. It's just the first one that appears. But if you go to this URL, this is an example of the questions that they sent out. And they basically said to each of the companies and they were sent by data subjects that: “Under the GDPR, I have the right to get a responsive answer to this question. Please let me know within a week.” And look at what's highlighted. “If in fact, you're sending data to the US, which technical measures are you taking so my personal data is not exposed?” And every single one of the responses from these companies is publicly available.

So, the first poll that we'd like to take is: “Would your company be able to answer a similar question to an NGO - whether it's Privacy International, None of Your Business, or another one - within a one-week timeframe regarding the technical measures you have in place to comply with Schrems II?” Again, we're not talking about updating your SCCs. Specifically, the technical measures that you have in place. “No” means you're not in a position to do so lawfully. And therefore, you’re at risk of terminated processing. And “Yes” means that you have the technical controls in place. Very interesting. A very large majority is saying they do not have those technical controls in place. And the reason this poll is so relevant is how do you position that to the Board? What are you saying to the Board when they ask you: “Are you in such a position?” All right, so let's move on from there.

 

So, this will be interesting. I'm trying to use a very simple analogy to get across what I believe and what our clients have encountered is one of the principal rulings of Schrems II. Let's draw an analogy between driving a car and using data. The intended purpose here is for this red car to go straight, turn left and right again. That's the purpose for which this car is intended, much as data processing is supposed to have a purpose.

Here's the problem. Policies alone do not prevent accidents. As you see, something happened. The red car did not do what was intended. It's now over the cliff. And hopefully, the driver is okay. But that's not that different from what happens to data subjects when their fundamental constitutional rights are violated. Sometimes there is no remedy. There is no redress. So, if you look at the signs here. The speed limit sign, the second sign, may have been the first policy. By analogy, the first SCC. They thought it wasn't adequate. They added a second policy, the caution sign. But no matter how many policies you have in place, if all you have is policies, it does not prevent bad things from happening. And so, now you have the second purpose, the yellow car is supposed to go down and take a left and go right. But there's no guarantee that it's not going to end up over the cliff. Compare that, and I'm not belittling the importance of policies. They're absolutely critical.

But when you combine policies and technical controls, physical controls, you now can influence if not prevent bad things from happening.

So, in this example, the blue car, our third purpose, we have both the policies, but we now have technical safeguards in place, the guardrail, to help ensure that bad things don't happen. And one of the things we're going to touch upon is that addressing Schrems II requires a balanced approach. You can't just involve technologists. You can't just involve lawyers.

Because if you involve just technologists, you're going to hear: “Let's encrypt the data. Everything's good.” The problem is, you can't then use the data.

So, as we move forward, this is about coming up with resolutions. The first thing the Board is going to want to talk about, at least in our experience, is doing nothing is actually risky, okay? The quote: “Ignorance is not bliss, it's negligence.” The little red footnote, the asterisk, the Accountancy Europe actually holds moving forward with knowledge of rules but not complying as potential evidence of fraud, and outside auditors actually have an affirmative obligation to report. So, this is something that the Board takes very seriously. And if in fact, their operations and processing were terminated, it would be self-inflicted. So, then we look to the right hand, the third column. The reality is the technical controls, the safeguards, and additional measures that the Schrems II Court talks about and the reason they're important is because the GDPR - Schrems II is not a new law. It's just highlighting certain elements of the GDPR that already exist. It's taking the battlefield, as it were, the realm where you're supposed to protect the data away from just the premises of the processing. And now, it needs to flow with the data assets as it is internationally transferred, and technical solutions are required and can actually help you to prevent or mitigate damage.

And how did we get here? Look, cybersecurity has been with us for a long time and it will be. It only increases as a problem. But that's focused on protecting data at rest and in transit. And it's pretty well known that GDPR and the Directive before it, but the GDPR introduced a new concept, two new terms. One that never existed before, Data Protection by Design and by Default. And a second one that unfortunately did exist before but now is entirely different in its interpretation and definition, Pseudonymisation. And because of those and the obligations that companies have regardless of international data transfers to use those, what the Court of Justice and Schrems II really focused on is you cannot trade, it is not lawful to trade the fundamental constitutional rights of EU citizens for either commerce or surveillance. And that is why contracts and treaties and words alone are not enough, okay? You have to have these technical controls. And at least in its initial recommendations, the EDPB is recommending Pseudonymisation as a means of protecting data in use. So, next, Gabriela is going to spend some time in the next two slides, and I have to say no one has schooled me as much in Data Protection by Design and by Default as Gabriela. But if you would please, Gabriela, just some background from your perspective. And I think one of the things people sometimes get confused about is: “I'm doing Privacy by Design, isn't that enough?” And so, how is it and what is it that makes Data Protection by Design and by Default, which is mandatory, different from just Privacy by Design?

 

 

 

 

 

Thank you, Gary. Well, the answer to this question has to be rooted in the difference between data protection as a fundamental right and privacy and the right to respect for private life as a distinct fundamental right protected in the European Union. This is why we have Article 8 of the Charter for Data Protection and Article 7 for Privacy. They are separate rights that have different goals. And this is also why Data Protection by Design and by Default is different than the concept of Privacy by Design as it was coined in the literature and by some policymakers in the past 10 to 15 years. Data Protection by Design and by Default (DPDD), first of all, is a legal obligation. So that's, I would say, this is the first real difference between the two concepts. DPDD is a legal obligation under the GDPR in Article 25. Whereas Privacy by Design, it's a goal that is nice to have but, you know, nobody actually cares to enforce it. With Data Protection by Design, it's very important to take into account safeguards to be brought to how you collect and use personal data from the very early stage of designing your product, of creating your project, any sort of operation that requires collection and storage and further use of personal data or what we call processing needs to take into account specific safeguards from the very beginning. Those are both technical and operational safeguards.

And, indeed, we have here the text of the article. I am for sure not going to spend time reading it since I'm sure you will share the slides with the participants. But you have already here in the text of the article itself, some pointers about what can be done to ensure Data Protection by Design. And, of course, you have to take into account the risks that it's possible for your processing to create on the rights of individuals, and you have to measure and calibrate the types of safeguards you implement to the risks that can be posed to individuals. And then, as I was saying, both technical and organisational measures are required. Pseudonymisation is specifically mentioned indeed. But the ultimate goal is to implement data protection principles. You have to take into account data minimisation and purpose limitation as well. You have to take into account the fact that you will need to comply with the rights of the data subject. Look, if you are going to build a system where it will be impossible to erase data, that's a breach of Data Protection by Design because data subjects have a right to ask for erasure under certain conditions. So, I would say this is the best I can do in a very short time to give you an overview of the DPDD obligation.

Thank you, Gabriela. And I think she hit upon a number of the things. DPDD is mandated. It is a lawful requirement that exists both with respect to primary and secondary processing, whether that processing occurs within or outside of the EU. And so, Schrems II didn't introduce a new legal obligation. It highlights obligations that already existed, that are more evidently missing when it comes to missing that capability with regard to the protection of data when it is transferred internationally. So, that is Data Protection by Design and by Default. So, now we are going to move on to GDPR Pseudonymisation.

But before we do, I want to teach everyone in the audience a trick that I've learned. You may laugh, but many people actually thank me for this. First off, Pseudonymisation does not mean what it did in 2014 when the Article 29 Working Party did a review of anonymisation techniques. And yet, that's what most people believe it means. It was redefined under the GDPR. And it's hard to say and it's hard to pronounce. So, here's my trick. I imagine myself standing on a stage. I'm about to speak when my friend on the back left comes out. Her name is Sue. And her friend Don comes in the other door - SUE - DON - NYMISATION. So, for whatever that's worth, it's a tough word to spell and to say. That's my intro and segue to Maggie who is going to talk to us about just that.

Thank you, Gary. And I'm going to show you on this slide the same picture that was shown on Gabriela’s slide, and I definitely want to come back to what she has been saying on Pseudonymisation. It definitely is a new concept defined under the GDPR, and I really want to highlight and bear with me please on why it is so fantastic and such a great concept because what you all want, and I think Gary also touched upon that, is if you also have to convince Board Members, you also have to be able to talk about data utility and data is gold and the ways you could use the data. On the other hand, you have Schrems II decision, you have the GDPR, and as Gabriela said, you have Data Protection by Design and by Default as a legal obligation to comply with and to implement within your company. So, you have those two things, and you have to be able to balance them and GDPR Pseudonymisation really lets you do that. Now, what does it mean? Because it is not - and let me start with what is not before I say what it is. It is not just replacing some direct identifiers with pseudonyms because we see that in a lot of times that people think whenever we didn't reach anonymisation, then the outcome of the data where we mask or delete some of the parameters, like direct identifiers and name, that the result is a pseudonymised data. Well, in a lot of the cases, that will be not the case because Pseudonymisation under the GDPR in Article 4(5) really states that you have to be able to separate identity from information value, and that you should not be able to get from the information value to the identity as such, unless you have access to additional safeguards, additional information that is kept very separately, and those are the technical and also at times organisational controls that Gabriela was referring to. So, that is very important and we will definitely come back to that.

What is very good to see is indeed that although we have under recommendations from the EDPB saying that transfer to cloud services from data in the clear is no longer possible. And so, with Use Case 7 and Use Case 6 that were seen as unlawful use cases, we really have a big issue. So, how can we help with that? And then, you see that the EDPB really recommends and say that transfer of GDPR-compliant pseudonymised data is a way to go about this. Now, how can we do that?

So, as already explained, very important that there are new requirements and there's GDPR-compliant Pseudonymisation. Those requirements - they will enable Schrems II compliance. Why is that? Well, you will keep the identities separate from the information value, and you cannot jump over the wall, which you put in between both of them. You must really be able to have a controlled relinkability. Now, also very important is that relinkability because a lot of people will go back and say: “Well, let's just anonymise the data.” First of all, we can all agree that if you only can work with anonymised data, you have thrown away a lot of useful data. And if data is your gold and data utility, you already set yourself short. On the other hand, you also have to be able to protect the privacy of your data subjects. And with having these additional controls being able to relink it, which you can't do with anonymised data, that is the great benefits of on the one hand actually working with valuable data and information value, but on the other hand being able to exercise, as Gabriela also pointed out, the data subjects’ rights.

And now, I want to come to a very important point because I hear a lot and and I have to admit at the beginning when I heard about Pseudonymisation, and definitely when having pre-GDPR Pseudonymisation in mind, you think like how can that be sufficient as additional safeguards under Schrems II. But if you then look at the new heightened standards for Pseudonymisation under the GDPR, it really works because you can really keep the additional information, which are your keys to unlock. It's a little bit too short of an analogy, but you can see it as really the keys to unlock and re-identify the data. You can keep them in a separate server, really an EU server, for example, and only use the Pseudonymised data to, for example, share that with the US. And then, the great thing is because if it's truly GDPR-compliant Pseudonymised data, you know that if it even falls under surveillance laws what they will get is Pseudonymised data - the information value, but they will never be able to go back to the identity of the data subject, thus protecting the personal data and privacy of the data subject as those additional information is kept separately with controls in the EU. So, that is already very good. Now, you're gonna say to me: “Yeah, but if we have to Pseudonymise data, we really have to use it in different types of use cases.” And that is exactly what Pseudonymisation allows you to. It allows you to have context specific at use protection, and it will allow you to comply with purpose limitation, data minimisation, but on the same time be able to give you value maximisation.

As already explained, anonymisation, that really means if you want to do that within, for example, the company, that means you really have to throw away a lot of data and there is no possibility of relinking the data. If then, for example, you want to do AI and there is a data subject that says: “Well, I object to this AI on further use of my data,” you have no way of actually going back. And actually, you're not that much protecting your data subject. And on the same time, you set yourself short. Now, a lot of people think that Pseudonymisation or that the outcome of a Pseudonymised data set, there is like only one outcome. For example, a lot of people say to me: “But it's then sort of a language or a data set, which I don't understand. So, how can then, for example, if we would send this Pseudonymised data to the US, how can they work with that?” Well, it really depends and that is the beauty of Pseudonymisation on your use case. If, for example, you're in ad tech, and you want to have a microsegment in order to be able to know - I want to know that, for example, for my ads, I need females of a certain age and of a certain education, well, they need that value. And then, if they get that value, that's enough. And then, you have the other party, a trusted party, for example, who can do the relinking but they could use the data. If you need a lot of data, let's for example say Use Case 4 in this analogy, that is really one of the use cases for AI and what is the great thing you can ask your data scientists to say: “Okay, let's talk about the different parameters you want.” And if they say: “Well, we want as much as parameters and a lot of data as possible.” You can provide that and they can select that. Then, you can pseudonymise at that point the data sets. And then, of course, you will get probably if you're dealing with a lot of data and a lot of parameters, data that probably for you is not that readable. But for a computer, that doesn't mind because the computer doesn't read English either and will definitely be used and be useful for AI. But at the same time, Use Case 3, for example, could be data that is pseudonymised in order to do talent analytics. In an HR context, send that over to the US, you can definitely do some talent analytics on that. But in the US, you have then no idea if you would, for example, say: “We want to be able on the talent analytics to select the people that deserve a promotion in the EU.” Then, maybe in the US, they won't be able to re-identify that data. But then in the EU, you can do that and you still have valuable data, and you then can easily promote Jesse and John if they come up for a promotion.

So, GDPR Pseudonymisation is really putting those controls in place so that you can do the relinking on the one hand, but on the other hand, can comply with data minimisation and on the other hand, also with the type of data so comply with purpose limitation.

I think what you've seen already from Gabriela’s presentation and discussion about Data Protection by Design and by Default and Maggie's on Pseudonymisation is that these are controls that you're supposed to have in place at the time of use. We call that at-use controls. And most people have focused in the past on controls for data at rest or in transit but not when at use. This is something important to present to the Board because if they say: “Why am I just hearing about this? Wasn't the GDPR two years ago or four years ago? Aren't we “done” with the GDPR?” The response is quite candidly and honestly, most companies were focused on preparedness, awareness, and protection of data at rest and in transit. What Schrems II has highlighted is the need for controls at use, at the time of use. And the important thing here is what we have here is step three, which is Schrems II compliance. But you already have an obligation to comply with steps one and two. One being purpose limitation, data minimisation, and Data Protection by Design and by Default, which applies to primary and secondary processing, whether it's inside or outside of the EU. Second, Pseudonymisation is a means of helping you to process data for purposes that go beyond consent or contract. It helps you with other technical and organisational measures to satisfy the balancing of interest test. And so, if you have the controls for 1 and 2 in place, in most instances, the step to 3 to show that you have technical controls that would enable you to have international data transfer in compliance with Schrems is a small step. But what we discover with most companies is steps 1 and 2 are lacking. And so, very importantly, having the technical controls in place that enable you to comply with Schrems II both remedy a deficiency domestically or internally within the EU, as well as internationally. But this is something big for the Board. It opens up new opportunities for lawful processing, sharing, and combining with as part of an overall Data Protection Impact Assessment can actually mean new business opportunities. So, it's not just compliance. And the reason they're just hearing about is because Schrems II is like a big spotlight on the need for at-use controls that previously was not that well known.

So, I want to announce and you probably already know this, there's no such thing as a silver bullet for Schrems II compliance. There's no golden shield. There's no magic wand. And if anyone acts like there is, run as far and as fast as you can. But Pseudonymisation, we have found in our work with clients, can actually support the vast majority of sophisticated processing requirements. We have here 98%. That may or may not be accurate in your situation, but it's what we've discovered with our clients. And what does that mean? It means that the periphery, the remaining 2%, those can be done by other means whether that's an Article 49(1) derogation, whether it's by having it processed within the EU or by an EEA or equivalency country provider, the reality is if you can show that the majority of your processing is actually being done using technical controls, there are ways that you can handle the exceptions.

 

 

 

 

 

 

And so, what are we talking about here? Fundamentally, Pseudonymisation can convert what would otherwise be unlawful Use Case 6 (cloud) or unlawful Use Case 7 (remote access to data) into lawful processing, and this is where we transition into how can Anonos help you. That's exactly what we do.

The center of this slide is the most important. We have 8 years and tens of thousands of hours in research and development on our software. And it is a GDPR-compliant Pseudonymisation software, and I put GDPR in front of Pseudonymisation because it's a very different animal. And yes, you can in fact have lawful borderless data, meaning you can comply with Schrems and you do that by complying with Pseudonymisation and other requirements. But the real value and what you need to stress to your Board is number two there in the middle - you can have data utility without compromise. In fact, at the end of last year, we were awarded our first EU patent. We have 10 other patents internationally on how you can do this. This is all about maximising utility of data without sacrificing fundamental rights of data subjects. But technology alone can never be a solution to something that's complex. So, in the first column on the left hand side, we provide - and this is available for free on our website - a very detailed Legal Solutions Guidebook that walks through all the different legal provisions with appropriate footnotes, citations, etc, that the technology enforces. But we do more than that. We actually provide templates that you can use to respond to inquiries. So, if an NGO knocks on your door and says: “How do you comply with Schrems II?” You actually give them template one. If a vendor is saying: “You don't have to worry about Schrems II. I'm an in-EU processor.” Give them template four and have them read more into those. So, again, it's tying the technology in the middle column to the law on the left hand side. And very importantly, we stand by our software by providing a guarantee.

We even offer something called a Quick Start Program that gives you an immediate defensible position. How? We immediately start with non-identifying sample data that's reflective of your industry in the cloud to teach you those same three steps - Module 1, 2 and 3. Data Protection by Design and by Default, Pseudonymisation to help with legitimate interest processing, and Schrems II supplementary measures. We then work with you to develop a specific use case so you can test for yourself whether this non-identifying, non-personal pseudonymised data can meet your needs.

And then within two months, you can come to your own conclusion.

So, just a very quick example of what that could look like. Here, transforming an unlawful Use Case 6 into a lawful Use Case 2. You Pseudonymised the data within the EU. The unlinkable but still personal data that's been Pseudonymised is what's transferred into the cloud. As Maggie said, machines can't read English anyways. It's unlinkable and unidentifiable to the naked eye, and it can be proven with statistical and auditable measures that it is so. It's processed in the cloud and the results of the processing - this is very important. Our studies and our clients have proven that without any degradation to precision, utility, and fidelity, those same results now come out still unlinkable and they're only linked back to identity in the EU. And that's how we enable that to happen.

The reality is there are a lot of technologies out there, and they do a good job of de-identifying data. Someone posted the 2016 FPF infographic on de-identification, which to me is one of the most amazing infographics I've ever seen to help compress a very complex issue. But the reality is, that was created before the GDPR. Its treatment of Pseudonymisation is no longer accurate. So, when you look at this, these other approaches do exist and they do help to de-identify data, but they were not architected nor are they able to support these business objectives, nor are they recognised by the EDPB as a solution for Schrems II compliance.

 

 

So, in order so we can get to some questions, I just want to summarise very quickly. One, briefing the Board and C-Suite is not about providing details of Schrems II. You need to talk to them, and we will be providing to all of you through the LinkedIn Group a proposed template of what you could present to the Board, and you want to help them understand how they can avoid disruptions to revenue, share value, while also creating new opportunities. The reason things have changed and the reason there's more attention here is Schrems II has highlighted the need for at-use controls. Policies alone and SCCs alone do not prevent that car from driving off the cliff. You need technical measures. And the reality is, oftentimes what people think of when they think of technical measures encryption is necessary and it's critically important, but it does not protect data at use. So, that is the theme for the Board and we will send you materials that hopefully will be helpful to you in that regard.

Part two is Data Protection by Design and by Default newly defined under the GDPR and Pseudonymisation newly redefined under the GDPR. And part three, our patented GDPR Pseudonymisation technology can help you. We work with your existing advisors and lawyers or we have our own group of partner law firms and advisors that we work with who are very familiar with our system. It does not require you to change your current investment in either cybersecurity or privacy technology because they didn't set out to control data at use.

So, before we go to audience questions, we have a few questions that we'd like to take of the audience for polls. And this is an example of what we do to try to engage with the community. Imagine, today we have 1000 of your peers together, that doesn't happen very often. So, the response we get to these questions enables us to be more reflective and responsive to what you're saying.

So, we have here: “Which of the following steps do you plan on taking to address Schrems II risk exposure?” And so, there are four choices. Pleae pick one that is most important to you: Brief the Executives and the Board, assess technical controls supplementary measures, update SCCs, or conduct a DPIA. So, if you would please do that. I appreciate it.

So far, the winner is Update SCCs and BCRs, which absolutely is necessary and I do not mean to demean the importance of policies in this presentation. But hopefully, what's coming across is that by itself is not enough. And so, now, we have the Board and the Executives coming up as a close second, as well as assess technical controls and conduct DPIA. I want to emphasise, the Data Protection Impact Assessment is still critical, right? This is a holistic analysis of these things.

We also have people who have jumped ahead to the next question, which is: “Please check the following issues which you consider relevant and what might hinder your ability to be successful.” And it looks like Board lacks knowledge on issues is the winner there with unsure of which technology to use. And we'll give a couple of minutes for these responses to come through. And again, we will use this information to impact and influence our follow-on information and interaction with the LinkedIn community.

I appreciate your taking the time and giving this some thought. Again, to have this kind of qualified audience to respond to, it's helpful for everyone because you know where your peers are and what they're doing.

All right, well, so we can continue. Clearly, the Assess Technical Controls and Supplementary Measures is leading. And also, when we get down, Board lacking knowledge on the issues is leading as well. So, again, hopefully both this webinar, the recording we send to you, and the materials we send to you will help you with both of those things. We will keep these polls open while we go to Q&A.

Okay. I believe we had two other questions we are asking before we go to a public Q&A.

Okay. All right. So, we're going to go to Q&A now.

 

 

First question and we get this asked every time: What about homomorphic encryption? And it's interesting that this gets asked so often by lawyers. They've heard of it. We just want to put this out there and you'll be getting this material. Homomorphic encryption is an amazing advancement, but you need to understand where it is in the maturity scale. So, bottomline here is a process that would take one second with an off-the-shelf CPU processing either clear text or Pseudonymisation. That's important. Pseudonymisation does not require additional hardware, horsepower, etc., to process. It's the same processing that is done with clear text and same speed. But a process that would take 1 second with clear text or pseudonymised data would take 3000 years with fully homomorphic encryption. Now, are there certain simple processes that can be done competitively and commercially? Yes. But in our experience, those are not the kind of processes that the companies are looking to accomplish. So, that's just the first question and the first answer.

Let's look at the second question: Would insurance cover for negligent or willful noncompliance? This is interesting. The second part is: Would the answer differ whether or not the company has complied with the requirements for Data Protection by Design and by Default? So, this is something I will give an answer to and then we will look to see whether Maggie or Gabriela has a response to, but we’re actually also conferring with experts in the field and what we send out to you next week will also include their perspective. I actually do think this is a serious question because in fact whether or not you even have to put your carrier on notice, cybersecurity and privacy insurance is typically underfunded, it's hard to get, and it has a lot of exceptions. And typically, one of those biggest exceptions is negligence or willful misconduct. And so, you'd want to address that in here. Maggie or Gabriela, any perspectives or thoughts on this?

I would say, from the European Union legal framework perspective, I'm not sure any insurance would cover the broad private right of action that EU citizens have. So, I have not studied this in detail. But as a general rule, the GDPR offers a very, very broad private right of action, as well as a broad representative action type of possibility for NGOs to actually represent classes of people and go to court, but I have not studied in detail those provisions.

Thank you for that. We will have an answer from insurance experts when we get back.

And we actually have the results so that you know. 44% of you were saying that the highest priority for you is assessing technical controls, and 33% are saying the Board lacks knowledge. So again, hopefully, both this webinar in the materials that we send to you will be helpful.

So, let's go on to the second question here. Maggie, if you could please help us with this one? It's a fascinating question. Many organisations are starting to shift the DPO into more of a risk manager position than actually a compliance function. And again, these questions, we combined several. So, if you see part of your language here, if we had common questions, we combine them. So, Maggie, what's your reaction? What should a DPO’s role be? Should they be playing in what is called here the risk roulette game?

Well, no, I think that DPOs, their position was really explained in Article 38 of the GDPR. They really have to advise and, of course, they also have to advise on the risk assessment at the DPIA but it is with regard to the processing and not so much with regard to the impact or the financial impact and compliance or noncompliance would have to the company. Also, with regards indeed in the DPIA, you also have to of course, now start thinking about transfer and do a sort of data protection transfer assessment. Now, what is also very important that you have to know is if you start delegating to your DPO that he has to do a risk management and that the DPO would say: “Well, the fines are this and that.” And then you as a management would say, “Well, okay, if that is the risk, we're going to neglect doing something.” Please be advised that we have seen in Belgium, that the Supervisory Authority definitely takes in consideration to decide on the amount of the penalty whether you have been acting in bad faith and just doing nothing, or whether you have been acting in good faith but you maybe are not there yet. And so, we see really a difference in a penalty. That is very important. And also and I do not want to scare the DPOs too much, definitely not. But as a DPO, stand your ground, because in a lot of the cases, we have been advocating for our clients, we have also seen that the DPO position is under scrutiny.

Fantastic. So, the next one, this is fascinating. This is a combination of a number of different questions. If you saw the article, the Financial Times have seen an early draft of a European Commission release granting the UK adequacy status. But then you have the European Parliament drafting a draft resolution saying that even if someone has a treaty, if they have surveillance, they couldn't get adequacy. The CJEU made it very clear that fundamental rights are paramount.

There's a lot of confusion here. And so, the question here really is how to resolve these. And what I'd like to answer because we have with us one of the co-authors of the blog is go to the next question, which is Gabriela was a co-author on this blog, which I thought was a great perspective on the fact that Article 49(1) derogations are not dead. And so, Gabriela, if you would give the audience kind of your perspective, what is a data controller to do when there's so many conflicting messages?

Unfortunately, there's no answer to that. This is one of the most complex problems in data protection to solve - the problem with international data transfers. Actually, to go back, I would say, first and foremost, listen to Data Protection Authorities and the European Data Protection Board, read the guidance of the European Data Protection Board because the EDPB is the first one and the DPAs will be the first ones that will apply the law. And then, of course, pay a lot of attention of the Court of Justice and its case law. I would say these are the sources that are extremely irrelevant. Look, the European Commission and the US Government negotiated for Safe Harbor, then Privacy Shield. But ultimately, they are not the ultimately authority on these issues. So, you know, this would be the DPAs, the courts, and in the court system, ultimately, the Court of Justice of the European Union that applies the rules. So, pay attention to those. As for the Article 49 derogations, indeed, we have discovered this incredible intervention of Judge von Danwitz, and I say incredible because he was very generous with his comments as a seating judge in the Court of Justice of the European Union that that's not really happening all the time. It's a rare occurrence. And he participated to an event organised by the Council of Europe where he made a number of comments on the judgment and the fallout of the judgment. One of those comments was related to Article 49 derogations, and he was saying that they have not been sufficiently explored in practice. He was saying that the Court decided to annul Privacy Shield with immediate effect as opposed to giving it a period of grace because there would not be a legal vacuum because there are the Article 49 derogations that could potentially be used. However, we know that the GDPR’s text, the Article 29 Working Party guidance, the EDPB guidance, very recent guidance after Schrems II limit the potential applicability of Article 49 derogations. They are not supposed to become the rule. This is why they're called derogations. They're supposed to be quite strictly narrowly applied. However, the judge-rapporteur in the Schrems II case said that they have not been sufficiently explored and that in certain instances, they are indeed a way to go forward and he was particularly referring to intra-group transfers that are necessary for the purposes of the transfer and that’s all. So, these are comments that he made in his personal capacity at an event organised by the Council of Europe, and that’s actually available online. It’s recorded, and we have summarised the key messages on this blog here.

It's a great blog for those who have not seen it.

Gary, can I just step in for a second? I read the blog, and it was very useful. And I understand that there are derogations. But please be aware because we’ve seen that a lot in practice. It's like the legal grounds. It's not if you can benefit from those derogations that you have to throw or you can throw away the rest of the principles under GDPR and throw away Data Protection by Design and by Default obligations. That's still something that you have to comply with. So, Pseudonymisation and the derogations would definitely go hand in hand together. So, I just want to take that in mind that -

I agree with that. Thank you. That’s a very good point to make. Yes.

There's a point on top of that, that I think a lot of people sometimes miss. The first question dealt specifically with 49(1)(a) consent and 49 (1)(b) and (c), both contract related. The other thing to look at is that the way you have to satisfy the lawful basis of consent or contract, I would think many of those same principles would apply. So, it's not going to be a loose interpretation of consent or a loose interpretation of contract. I would think that there would be strong analogous requirements for how tightly it's tied to contract and/or has there been, you know, open, willing, and voluntary consent. So, I was encouraged actually and I very much enjoyed the blog that there should be derogations available in the earlier slide, right? Where if you could do it with Pseudonymisation and Data Protection by Design and by Default for 98%, there's some where you just have to reach the person, right? If I want to send an email and if I want to tell someone that they just got accepted for a job or to a university or there's an increase or whatever it is, I need to reach the person and not someone like them. And so, I do think reasonable use and allowance for derogations makes sense.

So, the next question is quite interesting. And I must admit and maybe it's just me, I had not been familiar with the idea of a chocolate teapot before. So, I had to look it up. But this is a great question, right? Are companies really counting on this being a chocolate teapot to avoid having to comply? Meaning that enforcement is impractical. If you try to make tea in a chocolate teapot, it melts. And I actually think what's fascinating about Schrems II is the NGOs who, again, I do not believe they are privacy activists. They’re privacy enforcers - the ones that are out there trying to hold companies accountable to the laws that were duly passed. I believe you have to pay attention to them and look at the impact that both Privacy International and NOYB have had. Don't forget that collective actions are coming. And so, I think from the NGOs, as well as shareholder groups, as well as member state laws - all of those are on top of the supervisory authorities and the supervisory authorities are the ones who have the official obligation. And so, I think there's a lot of different directions that it could come from. But I'm curious if either of you have a perspective on this.

Look, if it's a chocolate teapot, this means that the entire EU Data Protection Law system will crumble. So, this would be my answer. I mean, it might sound very impractical but this is how this legal system was built. This is how the fundamental rights for the protection of personal data was built, and it didn't appear overnight. It has a very long history in Europe, starting with the late 60s and the early 70s. In 1970, we already saw the first Data Protection Law adopted in Germany, and then it evolved and it evolved and like a snowball and this is where we are. We have to make it work.

I know it's all about enforcement, but I would really encourage also the audience to not view the GDPR as only a pure compliance exercise because we have seen - and I've seen that in my research - that if you really look at it from on the one hand a trust exercise about your data subjects or about your clients and as a data utility exercise, it makes much more sense and you will see that you will really be able to maximise the data utility because there is not only Schrems II to take into consideration, but there is the GDPR as such. And if you try to think and make that mind switch, I think it's really worth the effort.

Look, I agree with both of you. And the reality is, now that I know what a chocolate teapot is, that's a very high-risk decision not to comply with Schrems II. And if that decision were to be made, it needs to be made at the Board level. That's not something that someone below the board should be deciding because, in fact, the ones most likely to be potentially at risk for personal or even criminal exposure are them. And so, I would hate to think that companies don't look at data protection and other fundamental rights as just a cost of doing business if they violate them. But just from a strict dollars and cents perspective, if someone's going to take that radical and high-risk approach, that should probably be presented to the Board and the reasons for doing it should be well documented since the downside could be catastrophic.

I just wanted to add generally that if you think this is only a problem with Europe, this is not really the case. All of the new data protection laws that I'm seeing or the majority of them have some rules on international data transfers. In Brazil, the LGPD has rules on international data transfers. New Zealand just adopted a new law that includes now a principle dedicated to international data transfers. So, I would say, this is not really just a problem for your European practice if you transfer data around the world.

Cross border data transfers are becoming more and more a part of the business. And so therefore, the requirements and restrictions on those, as you say Gabriela, are more and more relevant.

I do want to say we have scheduled this for another 18 minutes. I don't know if both the speakers can stay that long. So, if either or both of them have to leave, I understand that because we had talked to you both for about one hour, but we still have some questions. And so, we will continue to go to the end of the half hour. One of the reasons is so critical, and we'll make this recording available to everyone in the LinkedIn Group is you have to be responsive to and present this to your C- Suite and to your Board and be in a position to do so that puts you in a position of strength, gives you a greater influence, and as we said, hopefully even positions you as a hero within the company.

So, the next one's a tough one, okay? And I'll let people read it, but I'll summarise it as you're reading. A lot of people focus on the cloud providers. The majority of public cloud infrastructure providers are, in fact, US companies. And people rely on them. How do you, therefore, when you can't control what they're doing have it so that they comply? And this is critically important and I do want to comment when you join the LinkedIn Group, please go down and read prior posts. There are also prior webinars. There are prior FAQs. It's very feature-rich. Because this is a question that actually had a lot of attention in a prior webinar, but I think it would be good to get the reaction of today's panelists on this. And then, I'll obviously jump in as well. But, Gabriela, do you have any particular thoughts?

Oh, no, I'm so sorry. I was just replying to someone about the new SCCs. And then, I have to apologise. I really need to go.

Gabriela, thank you so much for coming. I do understand. And I ask everyone to give applause but no one will hear. So, thank you Gabriela for coming. And if Maggie can stay for a while, we will do so. And look, the new SCCs are very critical. But bear in mind, just like the car driving over the cliff, they by themselves are not enough. You need to pair those with technical controls. Thank you, Gabriela. Thank you very much.

Thank you very much, Gary and Maggie. It was a pleasure being here today with you. And thank you to all of the attendees for their attention.

Thank you, Gabriela.

Thank you.

So, Maggie, do you have any particular perspective on this?

Because I was also reading the question, I think that goes back to also the trust there and it goes back to your chocolate teapot there, which I didn't know what it meant either. It’s the fact that you will now also see in contracts in, for example, governmental projects, that they will really require you to comply and we already had supervisory authorities - the Flemish one saying that if you use US cloud that you can't use it without the supplementary measures and that they want to see it. And so, of course, the government is looking at now their providers to make sure that they also comply. So, I think, at a certain point, and we have also seen that with GDPR and it took a little bit a while, but it became really something in the negotiation and the sales process. So, if you really think that it's only a chocolate teapot, I really disagree because I think it will affect the business as it will become really obligations that you have to meet or otherwise will face liability towards that. And on the other hand, we see that more and more like the ISO 27700 certification is really also looking to GDPR compliancy. We once had a project in that and it was also asked: “What are your Schrems II compliance and additional safeguards?” And if you then have that certification, it really helps. So, I really think that it's a process that people have to grasp what Schrems II is. That ball is rolling. We had snow in Belgium, which is very particular. But that snowball is rolling and it's coming and I think it will have its triple effect to all the subprocesses and the processes.

And so, specifically on this, one of the visuals I used previously was actually the example of how this could be resolved. You can pseudonymise data using heightened requirements for GDPR Pseudonymisation, submit the Pseudonymised data for the advanced processing, AI, ML, etc., in the cloud, get the results back but actually do the relinking to identity in the EU or by an equivalency country or an EEA country. So, there are ways to do this. But if you think of it, there's a shared responsibility model with cloud providers, and all the cloud providers are saying: “We have SCCs. We have new SCCs.” And it's true. But you have always been responsible for the lawfulness of the data that you submit to the cloud. And so, in essence, it's your responsibility and you can do something about it by Pseudonymising the data that is sent. And if you remember the diamond, we in our experience, 98% of the processing can be handled with pseudonymised data. So, then you have just the edge cases, the 2%, which the derogations may well be able to support. So, that would be my recommendation as you look at GDPR Pseudonymisation within the cloud because then you're not dependent on the cloud providers, you have put the protections in place, and you know you're in compliance.

Let's move on to the next question, and this is a great question as well. What is the practicality of requiring data controllers to assess the detailed elements of what different countries do? And I'm going to jump in here and then have Maggie jump in if she has one. This is why we think Pseudonymisation makes sense because this standard in requirement is almost impossible, except for the largest of large companies to do. But if you know that the form of data that you are transferring, that you are putting into the cloud, that is available for access from outside of the EU is protected - if you go back to the visual that Maggie had with the different faucets - and you know that the data that they're accessing, while still of high value and utility is not identifying, you actually don't have to worry as much about the law in the given country because you've technologically enforced it. You have guardrails, not just signposts. Maggie, anything to add on this one?

No, I think you said it. With Pseudonymisation, it really helps. And on the other hand and I really want to stress that you still have also the opportunity to go back to your data subjects. And if you didn't look at, for example, the GDPR because it's also very understated and I call it the hidden articles of the GDPR, if you would look up what the benefits are of Pseudonymisation under the GDPR, you would definitely see that also you would come out there are a couple of articles, which are very good because of the fact that it is Data Protection by Design and by Default. And if you then take also the reasoning because that is sometimes also forgotten around these data protection laws and definitely with regard to the GDPR, if you can apply that and knowing now that, for example, even into decisions and the precedents that are being created with the supervisory authorities or the courts, that it will defer whether you have taken actions and you're doing the right thing versus you are considering it as a chocolate teapot that will also -

We have a new term now, right?

We have a new term. Yeah, definitely. That will definitely also differ in the risks and the height of the penalties. And therefore, I think it will be definitely a difficult risk to encounter. So, I think that I wanted to add to what you have been saying, Gary.

Thank you. So, moving on to the next one. All right. So, this is in some ways a restatement of the prior question, but this is tied much more to a knowledge of the EDPB guidelines. So, scenario six, which surprised many people was held to be unlawful is the processing of data in the clear, whether that's in the cloud or other means of facilities. And seven is when there's remote access to EU data from anywhere outside of the EU. Now, something to bear in mind in our legal solutions guidelines template four that we suggest people use with their vendors, even if someone has an EU service, oftentimes, they're using US cloud in any effect. The question is: Is there a point in time when data is accessible in the clear? And even if you have customer managed encryption keys, when the data is processed in memory, it's in the clear. And so, it's very important for you to ask tough questions of your vendor partners as to whether or not what they have actually enables them to comply.

I actually hadn't seen the second part of that. I'm going to take that as a compliment. We actually are not familiar with another vendor who provides GDPR Pseudonymisation technology. If you are talking to a vendor and when you do evaluate vendors, and they're talking about GDPR Pseudonymisation, one of the things that you'll see in the materials that will be included in the follow-on with the recording, the longer director's cut of this is going to be ENISA Guidelines. So, the European cybersecurity agency has come out with three different reports, one in 2018, one 2019, and the third one, I believe, is in 2021. Wasn't it, Maggie? ENISA is very specific on the requirements for GDPR-compliant Pseudonymisation. And so, you don't want to kind of do Pseudonymisation. You need to have compliant Pseudonymisation. And if you look at the EDPB recommendations and you look at Use Case Two, which is the processing of pseudonymised data, which is paragraph 80. And then you look at that in combination with footnote 69, which is the definition of Pseudonymisation, which means you have to do GDPR heightened Pseudonymisation. And then you add to that paragraph 135, which is where the ENISA recommendations and other types of sources are viewed as if you're complying with that it's helpful. So, in fact, there are ways to comply with Use Cases 6 and 7, and that is to convert it into Use Case 2 with pseudonymised data.

This is a great question. What counts as international data transfer? And I'll let you take a first shot at this, Maggie, and I think this surprises some people. What is international data transfer?

Of course, it's about processing data that leaves the EU to other non-EU or countries of the European Economic Area. But what I think is very important that you understand under data transfer because we also look at processing, it also almost seems like processing requires an active handling. But that's not the case. If you just think about the fact that you store data, the mere storage of data is also seen as the processing of data now within international data transfer and it has been reconfirmed by the EDPB that the mere access to data is also considered as an international data transfer. And that is why, for example, the Flemish Supervisory Authority held that even if the servers are located in the EU, that you still can have international data transfer because the US cloud providers, although their servers are in the EU, they have access or potential access to those servers, which then includes or is considered as an international data transfer. So, you see, if you want to interpret GDPR, always take that in mind, the spirit of the GDPR is to take as many personal data under as many processing actions as possible under the GDPR in order to fall within the scope.

And I think Maggie touched upon this. This is what surprises some people. If I am processing EU data in a US cloud - AWS, Azure, Google - even if the servers are in the US, those servers are potentially in fact, if not likely, are subject to both FISA and CLOUD Act of 2018 reached. And therefore, the fact that you're processing data in an EU server of the US cloud provider does not take you out of Schrems. It is still international data transfer. We have a lot of people here from India. If one of the services that a company is availing itself of is the advanced analytics capabilities of an Indian partner, whether that's actually a corporate sister company or an outside party, if the Indian analytics experts are accessing the EU data and it's in the EU, that's a transfer. So, it's a very broad perspective, as Maggie said. The GDPR is intended to be very inclusive. And so, it is not just sending data across the Atlantic.

This is a great question. I've touched upon this earlier, but I think this is really important. What groups should address? Technologists alone and lawyers alone, I think, are a bad approach to Schrems II. If you ask most practicing privacy lawyers how to protect data under the GDPR, their answer will be to anonymise it. Because once anonymised, it's outside of the GDPR. That is an accurate statement and good advice. But if you don't have the data user at the table who can say: “Well, wait a minute, I need to re-link it.” And once it's re-linkable, it's not anonymous, you haven't really solved the problem. Conversely, if you have a technologist at the table and you say: “You know, it looks like the answer here is GDPR Pseudonymisation.” “Oh, we do that.” I know this for a fact, Maggie does a lot of work with companies who think they're Pseudonymising and they're not. It is not failed anonymisation. It is not tokenisation. It is not key coding. It has new requirements. And so, it is very important that that, in fact, is handled in the appropriate way so that it is compliant. Anything you’d like to add there, Maggie?

Yeah. Because I like to see it as going further because, for example, also, marketing is of great importance and in research and development teams because they are the ones that are going to define your secondary processing. They need the data for their purposes. And so, you need to have them around the table in order to set your data protection plan in order to have Data Protection by Design, because otherwise, you fail. And if you only get the lawyers or you only get the technical people or you only get the combination of both, which is already very good and don't get me wrong, but then they will only see what they are having in mind of data utility and not what the others have in mind. And once again, for marketing and even for R&D, it is not that GDPR or even Schrems II is saying “no, you can't.” It is saying: “Yes, you can. But there are some rules to follow.” Not so complicated, I would say. So, for me, it's very, very important to actually have it as a company-wide exercise, once again, to work towards data utility, maximising data utility and creating trust, rather than having it as a compliance exercise. But of course, if you do it as the first, you will have the check the compliance without a doubt.

Absolutely. So, it's growth, utility, maximising on the data value, which are all positive things to address the Board with, with controls. So, compliance by itself is not a winner with the Board, showing that it's not going to or that the right technical controls can avoid negative impacts to revenues, market price, share price while opening up these new opportunities, that's the way to get a very positive reaction from the Board.

Maggie, I'll let you take this one. What's the grace period? How quickly do people have to comply?

Now. Yesterday. Well, the 17th of July, I would say. There is no grace period. Personally, I think it comes from the fact and it's like the German judge and professor already said it is because the GDPR actually already holds the answer in itself in Article 25 and in a couple of other articles like also Article 49. It is just because we have not been reading them correctly or interpreting them always correctly that we have not found the solution as such. But actually, that's why I always say the writing was on the wall or there was not so much new. And in a way, I get a lot of reactions to that. But I think it's because it's in the GDPR and they had that in mind.

I agree. I think Schrems II literally cast a big spotlight on obligations that already existed that weren't where companies were focused.

I'll take this one. This is actually why Anonos created the Quick Start Program. In working with customers, they wanted something that enabled them to show immediate efforts and steps to comply without requiring a long-term commitment and enabling them to learn, just as Maggie just said, how these same technical and organisational measures can advance their business goals. And so, from our perspective, we can have a client and present them with an immediate defensible position within hours. Again, we put up non-personal sample data that's representative of their industry. We walk them through how the software works to learn Data Protection by Design and by Default, to learn Pseudonymisation for many reasons, not the least of which is to support further processing beyond what contract and consent can support. And then, we move to Schrems II compliance. We then work with the client to figure out a use case where they can test and validate how valuable the resulting data will be and they get that back. Within two months, they have the completed Quick Start Program. They can extend it if they like. And if they choose to go to an enterprise relationship, we're happy to have that. But we don't require that as an upfront commitment. But most importantly, we think the second the software is running with that sample data, if someone comes knocking on your door, you have an immediately defensible position.

Okay. So, we have your practical solutions for the common situation. So, here this is fascinating, right? First off, much of what we've said today with respect to SCCs (Standard Contractual Clauses) would also work in the case of BCRs (Binding Corporate Resolutions). And so, they're both contracts. One is internal within an organisation through its affiliates. The other is between unrelated parties. Centralised HR is a great example, and Maggie touched upon this. If you want to do talent analytics that actually could be sent outside of the EU, but when it comes back to re linking to people's identity that you could do within the EU. Maggie, your perspective on this?

Well, yes, I think I already said it with the talent analytics is I think a very good example. Secondly, you also really have to check. And today, I think we are using a little bit too much data, which we don't need for the exact purposes. So, it really also helps to make that consideration. And on the other hand, you also have to think of, which is I think the benefits we have not touched upon, data security. First of all, it's all about data governance because you can't, I think, do Data Protection by Design and Pseudonymisation if you have no idea what your data is and how you're going to protect it. Now, by applying that by really, first of all, having a good overview of where your data is, what you want to do with that data, and then for those use cases and have those technical controls additional safeguards in place that will also protect you and protect your data, and knowing that cybercrime is on the rise, I think this is also really worthwhile taking that up to your Board because I think it's worldwide, but we have seen in Belgium disastrous effects of ransomware of company having hacking incidents and if you can imagine a hospital having a hacking incident and things like that. So, really, with regard to that it is also worth the while of having that data governance, having Data Protection by Design and by Default, and knowing that if you really share that data, that you have Pseudonymisation within your company as also outside the company.

One of the interesting points that people don't realise, Article 32 when it talks about security following up on Maggie's point, the only two technologies that are cited are encryption and Pseudonymisation. In fact, Pseudonymisation appears 15 times in the GDPR. Whereas encryption only appears three times and anonymisation only appears twice. So, as Maggie said, she called them the almost secret sections. It's not that anyone's keeping them secret. It's that people have been focused on the fact that there's a lot of statistically proven statutorily granted benefits. These are not workarounds, they're not loopholes.

We are getting a great number of questions, but we're gonna cap it at two more. I appreciate everyone's time, but we will get you out shortly.

Okay. So, the next one is a very specific use case. Okay, this is assuming there's no adequacy. All right. So, this is an opinion. I'll give my opinion. And Maggie, I'd love to hear yours. I do not believe that any standard contractual clause with risk assessment will be sufficient. Nor do I think saying that you're fulfilling a contractual term, so a 49 (1)(b) or (c) derogation. My own interpretation of the Schrems II ruling is, in essence, you already have an obligation to practice Data Protection by Design and by Default, put technical controls in place to reduce the risk to data subjects. Also rely on SCCs. Also rely on 49 (1) derogations. But you can't proceed without technical controls. It's my own interpretation. Maggie, is that similar to what you might say?

Yeah. Exactly. And be very aware. If the contract is between you and the other party or binding corporate rules, it is a contract within indeed the company. Now FISA and the CLOUD Act and even the GDPR stands outside that. And if you agree to something, but there are binding legal obligations that trumps like surveillance laws, those contractual terms, they don't mean anything, you can have the nicest contractual terms. But if you have binding law, that is one of the biggest rules in law, yet they’re just going to override it, and they're going to prevail, and you're left in the dark.

I think it's pretty explicit in the Schrems II ruling, foreign governments are not parties to a contract. So, if they have the lawful and technical means to access the data, the contract provides no protection to data subjects. And I'll go back again to the visual of the car driving down the road. You need guardrails. You need technical controls.

So, last question here. This is a great question. What does it mean to be GDPR compliant? And I'll just speak quickly, and then let Maggie close up for us. You can be GDPR compliant if you're sitting on your data. But the second you go to use your data, are you now compliant? One of the things that people run into is without international data transfers, repurposing data, further processing, you can be GDPR compliant, as long as you just use the data for which it was originally collected. But the second you go to make further processing and further uses, if you're dealing with consent or contract, that will not support that processing, you will need technical and organisational measures to support legitimate interest processing. And legitimate interest is not a results based test. It is not: “I have a legitimate interest in the outcome.” It's: “I have the technical and organisational measures in place to ensure that the process ensures the rights of the data subjects in order to claim legitimate interest as a lawful basis.” When you go to international data transfer, the same thing occurs. The fact that you're GDPR compliant, if you're doing X, when you go to do Y whether it's further processing or international data transfer, there are new requirements. And the new requirements, there are exactly what we've been talking about, which is technical and organisational measures to ensure that your processing of the data does not violate the fundamental rights of data subjects. Maggie?

Yeah. It’s how to become GDPR compliant is knowing and doing and making sure that the legal and ethical principles are also translated into technical and organisational controls. And with keeping in mind that indeed definitely with international transfer, there are prevailing binding laws. And do you still protect or provide an equal level of protection to your data subjects? And if you can answer those questions, with a yes. And yes, we do that. Then, I think you can be GDPR compliant. It’s just not having a register or having the contracts or legal but it is, like you said, the work of different teams altogether sitting around the table and making sure that you have that data governance plan.

Well, again, Maggie, thank you and thank you to Gabriela who had to leave earlier. Just to summarise here, everyone that joins or is already a member of the LinkedIn Group, the Schrems II Group, we will be providing by Wednesday of next week, a copy of the webinar as you saw it, plus expanded information and coverage of technical controls. We will also be providing a template that we hope you could use in your briefing to the board. And part of that is going to be questions that our clients have been asked and answers to those to help prepare you for that. Also, you will be receiving the Eight Most Common Misconceptions about Schrems II. And lastly, a legal memorandum on D&O coverage and insurance and liability. The very last thing I want to say. It was in response to client demand that we created this concept of a Quick Start. Why? Because if someone comes knocking on your door, whether it's a shareholder, whether it's a supervisory authority, whether it's an NGO, we believe companies who in good faith have taken that first step to comply are in a very good position that they will walk to the next door. But it has to be good faith, and it has to show that you're moving forward. That's why without requiring any security review, without any prolonged negotiation, with just a two-month relationship, you can test the software in the cloud with representative data that is not personal, you can allow people from around the globe to participate to decide as for what you need, but what you got was immediate defensible position in case anyone is concerned. And that's what we at Anonos are about. It's meeting the needs of our customers, data controllers, who want to process data, they want to generate data value, and they want to do it in a way that is sustainable, much as with the environment, processing data in a way that is both lawful and respectful of the individual data subject rights makes it sustainable. And I want to echo something Maggie said several times, the GDPR actually provides the means and the mechanism to do that in a more powerful, more effective way. You may have to do things a little differently. We happen to think GDPR Pseudonymisation is a big part of that solution. But so are you. So, please be a proactive member of this community as we move forward together to continue to achieve our business goals in a way that is sustainable. Thank you very much. We appreciate your time. Thank you.

Thank you.