Pseudonymisation Podcast
Timely discussions with industry experts about the requirements for and the benefits of Pseudonymisation
Episode No. 3
Top three takeaways from this episode of the Pseudonymisation Webinar
View Transcript
Pseudonymisation Podcast
Episode No. 3: Top three takeaways from this episode of the Pseudonymisation Webinar
Gary LaFever 00:00
Welcome to the third episode of the Pseudonymisation Podcast. My name is Gary LaFever, but I'm here to introduce the two guests we have with us today, Maggie and Steffen. Maggie, please introduce yourself.
Magali Feys 00:14
Thank you, Gary, for having me on this podcast. I’m Magali Feys or Maggie Feys. I am the Founder and Partner of AContrio Law, a boutique law firm specialising in data protection. And from that perspective, we are really working and seeing the benefits from Statutory Pseudonymisation because in COVID times, we led a very pan-European big research project where actually GDPR-compliant Pseudonymisation was applied in order to unlock the data, share the data, and at the same time balance the interest of the patients against the utility of the data. So, that was very interesting to see. From that, I am also taking that in my academic research for the University of Ghent where I’m actually doing a doctoral thesis on the secondary use of medical data for research purposes.
Gary LaFever 01:11
Fantastic. Thank you, Maggie. Steffen, please.
Steffen Weiss 01:15
Thank you, Gary, for inviting me. Hi, my name is Steffen Weiss. I'm from the German Association for Data Protection and Data Security (GDD). We are a nonprofit association, and I'm in charge of international affairs being a member of the board, and we are also very much connected to Pseudonymisation. We are working on a code of conduct on Pseudonymisation together with Bitkom and Germany, and we want this to be a transnational code of conduct applicable in several member states in Europe. So, I’m happy to talk about the topic today about Statutory Pseudonymisation.
Gary LaFever 01:48
Fantastic. And as I said, my name is Gary LaFever. I'm the CEO and General Counsel at Anonos. This Pseudonymisation Podcast is special in that almost a year ago to the day, Steffen and I recorded “The 10 Truths of GDPR Pseudonymisation”. In less than a month after we recorded that, the EDPB came out with their Final Guidance on Schrems II where Pseudonymisation is actually identified as one of the ways to have lawful international transfer and processing of data. And so, much has happened since then, and we will touch upon that during this podcast. So, what we will do here is an informal format but we are going to take turns reading one of the 10 Truths and then just talking about it. So, I’ll kick it off.
Statutory Pseudonymisation, which bears its heritage to Article 4(5) of the GDPR in the definition of Pseudonymisation there, is much more than just a privacy-enhancing technique and we will go into more detail on this. But the important thing to realise is there are significantly different and more stringent requirements than privacy-enhancing techniques in the past that may have been known as pseudonymization. I laughingly say spelled with a Z as opposed to an S or hashing tokenization or key coding. While it may sound familiar, Statutory Pseudonymisation as originally defined under the GDPR has a very different meaning and set of requirements. Any perspectives on that?
Magali Feys 03:21
Gary, if I may because I really appreciated the opportunity to also be in the first podcast where together with other data protection experts, we focused really on that fact because I really believe that a lot of people do not realise with this introduction of this definition and what Statutory Pseudonymisation is under Article 4(5). People don't understand that it is really a heightened standard and that it is a new standard and there's a new kid town and that is indeed not as easy as one can think to say by just applying a sort of privacy-enhancement technique that we fulfill this definition.
Gary LaFever 04:05
Thank you for that. Steffen, any perspective on your part?
Steffen Weiss 04:08
I can reminisce about our old definition of Pseudonymisation in our Federal Data Protection Act, and the definition was different from the one under GDPR now. It was a more easier approach of Pseudonymisation. It was all about replacing identifiers like name and other identifiable information from that person and that was called Pseudonymisation. And now, we dive deeper into the definition under the GDPR. You will see that the definition has many, many aspects which you have to take into account when you want to really pseudonymise personal data. So, we are going to go dive deep into this and have to talk about it.
Gary LaFever 04:45
Fantastic. Maggie, would you like to hit the second truth?
Magali Feys 04:48
Yes. Well, under the GDPR, the requirements of Article 4(5) fundamentally redefines Pseudonymisation. First of all, it dramatically expanded the scope to include all personal data, which is much more comprehensive than only the direct identifiers because I really see that people are really looking at direct identifiers. But along with the definition of personal data, it's a very broad definition. And of course, the definition of Article 4(5) also goes in that same direction. What is, I think, even more important and I really want to emphasise that as a second part is that it dramatically restricts the scope of additional information that is lawfully able to reattribute personal data to individuals because we encounter a lot of confusion there. People do not always realise that you have to be able to prove and even prove in a mathematical way, however, that the data controller’s information is unique and that you can't find it anywhere else.
Gary LaFever 06:12
Interesting. So, Steffen, was this part of what you were getting at before where the prior definition of Pseudonymisation was not as specifically tied to all data types, both direct and indirect, that would otherwise be considered personal data?
Steffen Weiss 06:27
Yes, exactly, Gary. We kind of left out the additional information, which you can use to identify the individual and this is a very interesting aspect of Article 4(5). I mean, with this additional information, you can identify the data subject so you have to essentially protect it. And at the same time, you have to reduce the additional information to a minimum in order to approach a risk-based approach because if you have broad additional information to identify the data subject, there is a risk if someone else has taken this additional information to identify the data subject. So, it needs special effort to protect, but at the same time, you have to reduce the amount of additional information as a security measure at that stage, so it is really changing in view of our own definition of Pseudonymisation in Germany.
Gary LaFever 07:18
Very interesting. So now, Steffen has the most difficult meaning the longest of the 10 Truths. And on the transcript of this podcast, we will have a copy of this for those who want to follow it. But Steffen, if you could, if you could go through number three for us.
Steffen Weiss 07:34
Sure. The definition of Statutory Pseudonymisation under the GDPR Article 4(5) contains two halves, which must be read and construed together. They cannot be read separately from one another. The first half of the Article 4(5) definition by itself means the outcome must be for a dataset and not just a technique applied to individual fields because of the expansive definition of personal data, which is all information it relates to identify an identifiable individual as compared to just direct identifiers. Then, additional information could come from anywhere, except the dataset itself and replacement of direct identifiers with static tokens could suffice, if this was as far as the definition went but the definition does not stop here. It has a second half.
However, when combined with the second half of the definition, the requirements regarding additional information mean that any combination of additional information sufficient to reattribute data to individuals must be under the control of the data controller or an authorised party. To achieve this level of protection, it is necessary to, first of all, protect all indirect identifiers as well as direct identifiers. And secondly, define suitable intervals for changing pseudonym and key combinations based on time with data volume to avoid unauthorised relinking. This is sometimes also referred to as overencryption, which is some sort of technique to insert some dynamism into Pseudonymisation.
Gary LaFever 09:09
Great observation there. And also, in the transcript, we will have a link to some prior work that the GDD has done, not their current activity but prior work on Pseudonymisation that actually included a reference to overencryption, and it may be clear that depending on the time intervals and the volume of the data and the access to additional information, this act of overencrypting as it were may well be necessary. I do think this two-part definition is something that people can gloss over, and you have to read both and understand. The first one is almost a legal requirement. It is a legal requirement that a lawyer, I think, could understand. But the second one almost requires some data science experience to realise what high standard this is that only the data held by the data controller or authorised party should be in a position to re-identify. Maggie, any perspectives on that?
Magali Feys 10:03
In my experience, that second half of the definition, that is really what a lot of people miss because, for example, within hospitals and research around medical data, we see that a lot of static tokens are being used. So, a patient is always, for example, replaced by x1. But then, of course, if you share that data in a couple of research projects with the same other third party, then of course that third party can start relinking those different datasets, and I don't think that people really grasp the fact that that is also part of the definition and that you really have to be able to also comply with that second part of the definition, which indeed is very technical and I think that's also why you need a technical-skilled person next to your side if you're only a lawyer in order to really grasp what it means in a specific use case.
Gary LaFever 10:58
And Steffen, I'm aware of the fact that when you work on these codes of conduct, you engaged with many different stakeholder groups to try to get different perspectives. Is that one of the reasons as well to make sure that you have a reflective body of knowledge, so that these different requirements can be accurately presented?
Steffen Weiss 11:15
Well, yes, we have to gather some expert groups. We needed the lawyers for the first half of the definition. We also needed the informatics for the second half, and it was not quite easy to get these two people together to be honest, but it just reflects the legal requirements we have under the GDPR under Article 4(5). I mean, on the one hand, you have to focus on the transformation process. You generate a pseudonym, and this cannot be attributed to a data subject, and this is where we put most of the efforts into in the past. So, it was all about using tokenisation to generate pseudonyms, which cannot be attributed to the data subject. But then came the second half of the definition. We have this additional information, and you cannot forget, Gary, that this additional information can be direct identifiers and it can be indirect identifiers. So, this is all related to the broad definition of personal data. So, you cannot forget entering the identifiers in your systems. These all need to be protected in case they are being used to re-identify the data subject.
Gary LaFever 12:21
That is certainly what we discovered. People may have it covered for direct identifiers, but it's the indirect identifiers that can just as easily oftentimes be used to re-identify. And so, you're right. The protection has to go throughout the system to apply to all the different elements of personal data.
So, the fourth one actually catches some people by surprise and that's why this is called The 10 Truths of Statutory Pseudonymisation. The term Pseudonymisation as defined - I should actually say redefined under Article 4(5) of the GDPR is picking up momentum around the globe because essentially identical statutory language is now found not only in the EU GDPR, the UK GDPR, but the data protection regulations of Brazil, Japan, South Korea, and five states - California, Virginia, Colorado, Utah, and Connecticut. So, all told there are more than 35 jurisdictions that have the same definition. And in each of those cases, it does provide this means that many people overlook of reconciling conflicts between data use and protection, and other countries and states are looking to adopt this or very similar definitions that incorporate this concept of Statutory Pseudonymisation because of its unique ability to both protect data and enable its use because under controlled authorised conditions, it can be relinked back or reattributed back to individuals. Any perspectives on that?
Magali Feys 13:55
If I may, because indeed I definitely think there's momentum. We also see a lot of new projects. For example, the European Health Data Space and I'm going in a couple of weeks to Helsinki to also discuss about that, and I have seen on the program a lot of speaking about anonymisation. And I think in this momentum it's also going to be very important to really use the terminology given so that we speak about the same thing because in my humble opinion, I think anonymisation today is much too often used as a sort of graduation of obfuscation rather than it is really in line with what is explained in Recital 26 of the GDPR and is definitely not in line with Article 4(5) under GDPR-compliant Pseudonymisation. I've seen that also too much in real life that they are focusing on anonymisation, as Steffen also mentioned, as only using tokenisation or masking of direct identifiers. And I think as the momentum is here, it is the right time but we also have to use the right words or at least be sure that we all agree that we are talking about the same thing given those different legislations and terminology being used.
Gary LaFever 15:19
Steffen, do you have similar encounters with people using words imprecisely?
Steffen Weiss 15:24
I do. I mean, it really depends on the size of the organisation and the background of the staff because you need the staff and the knowledge to be able to really implement Pseudonymisation according to the GDPR, and I did see isolated approaches among organisations using certain techniques, which were not coordinated at all. This is why we do hope that our code of conduct will help to really make this coordination possible. And it hit me quite by surprise, Gary, talking about this momentum that the US is introducing Pseudonymisation in the Federal State Laws. I did not know that, and I was also surprised to see Brazil taking on the momentum and re-introducing Pseudonymisation into their law. I think it was from 2018. And according to the Brazilian legislator, it’s not all about Pseudonymisation as a security measure. This is also part of the momentum we are having at the moment, and it’s about enabling data processing.
So, let's take the example of Brazil. In case you do research with health data for public purposes and you rely on a proper implemented Pseudonymisation, you can process personal data. You have the lawful basis for this, but you do need to properly implement Pseudonymisation. So, Brazil’s take is pretty much not one to one but most of the content of our definition of the GDPR on Pseudonymisation, and they are also keen on the second half of the definition, this additional information that has to be protected and separated.
Magali Feys 16:54
I just wanted to also add because I think also very important is my feeling that everybody is always very lenient towards anonymisation because it gets them outside the GDPR. But first of all, if you are really considering anonymisation, it really means that you can't do, for example, longitudinal studies and we have been drafting a bill for the Flemish government where indeed one of the perspective is to be able to do longitudinal studies to help patients and to help the data subjects. So, you really need that relinkability on the one hand. And on the other hand, I think also that with anonymisation, where you would really cut off the link between the data subject and the data that you're also taking away a couple of standard ethical rights of the data subject, which may not all be included in the GDPR and as the GDPR stated in the first and the fourth recital that it is a fundamental right but not an absolute right. So, I really see the benefits of Pseudonymisation in order to really improve and facilitate data utility, whilst at the same time also be able to balance that against the protection of the data subjects and their rights, which are not only related to data protection.
Gary LaFever 18:22
You know, both of you have touched upon something that I think really goes to the heart of the next five truths. As I mentioned before, less than a month after Steffen and I recorded our prior 10 Truths of GDPR Pseudonymisation, the EDPB came out with the Final Guidance for Schrems II. So, the next five truths each key off of specific paragraphs or footnotes within that EDPB Final Guidance, and the reason that's so relevant and ties into both of what you just said is it's about using Pseudonymisation as a data enabler - innovation, the ability to process, the ability to process data and use cross-atlantic transit kind of capabilities, US-operated cloud, sharing partners, distribution - if you can show that you've satisfied these following five requirements set forth by the EDPB in the Final Schrems II Guidance. Maggie, would you please start with number five?
Magali Feys 19:17
Five says that it's protecting all data elements and I think we already touched upon that but it is really in the first EDPB the requirement for Statutory Pseudonymisation comes from the footnotes 83 and 84 of the EDPB Final Schrems II Guidance. This requirement stipulates that achieving GDPR-compliant Pseudonymisation status must be evaluated for a dataset as a whole and not just particular fields of that dataset. This requires assessing the degree of protection for all the data elements in that dataset going beyond direct identifiers but also to include indirect identifiers and attributes consistent with the expansive definition of personal data under the GDPR of Article 4(1).
Gary LaFever 20:09
And so, again, I know we touched upon this earlier, but what we're really doing here is emphasising these five here that this is what the EDPB sets out in the Final Schrems II Guidance. And so, this is not just mere hearsay or discussions but, rather, you can track this to the EDPB Final Guidance and therefore provide some certainty and predictability as to what's required for Statutory Pseudonymisation, particularly as additional countries and states begin to adopt the same definition. Steffen, do you wanna hit number six?
Steffen Weiss 20:39
Protecting against singling out attacks. The second EDPB requirement for Statutory Pseudonymisation comes from Paragraph 85 of the EDPB Final Schrems II Guidance and mandates protection against singling out of the data subject in the larger group effectively making the use of either K-anonymity or aggregation mandatory.
Gary LaFever 21:00
And what I find interesting about this one, Steffen, is this really does speak to the fact that it has to be at the dataset level, you know? Because I believe with Pseudonymisation, a lot of people used to look at it and say: “Okay. I'll protect this data element in this row.” But the reality is, it may be fine if you only had one row of data, but the way that the data element is protected within all of the rows of the dataset actually becomes identifying, so I do think this prohibition against singling out, the requirement to protect against it, again is almost a data science concept. You have to realise that what might appear to be protected in a single row of data has to be compared against the entirety of the dataset to see if it actually meets that statutory requirement. Any other thoughts or observations on this one?
Steffen Weiss 21:46
I do have to agree, Gary. I mean, you have to take this holistic view of the dataset you are working with. So, you cannot just look at the individual set. You have to take this holistic view, and the EDPB has stressed this in the recommendations on the Schrems II data transfer. So, it’s an important aspect to have an eye on. And if we talk about K-anonymity and singling out, there is a chance of singling out attacks. I mean, if I could generally make this example and I’m just making this up, you have a list of patients. I mean, I don’t want to connect Pseudonymisation with patient data at all times. I mean, it has its benefits in many areas as well, but just let me do this one example.
So, you have your patients list with the name and a certain disease and age. And then you come to the idea: “Okay. We need to really maybe generalise the information or aggregate the information so this person cannot be identified.” So, you strip him maybe of the name and the surname. And then, you still have information on the diseases and the age. And in case you have maybe two or even if you strip certain ages to a certain range of age, there is still a chance of singling out a person. I mean, if two persons have the same attributes and have the same diseases although you do not know their names being their direct identifiers, there is a chance of singling out attacks. So, you have to avoid this at all times and this is a really important requirement and this is a technical aspect of Pseudonymisation, avoiding these singling out attacks.
Gary LaFever 23:12
And that's heightened from what existed in the past, and I think that's what we're talking about. People don't necessarily realise it. Maggie?
Magali Feys 23:17
Steffen, your example is so to the point of what I almost daily see in medical records and where only the direct identifiers are being stored or used tokenisation on them. And the problem is all so that within the research, for example, the mosaic effect from Harvard, it has been proven then that anonymisation does not work but it is because this is not done properly and that has given it its bad name. And so, whenever I even start to speak and say I am going to talk about GDPR-compliant Pseudonymisation, I almost immediately get shut up to say: “Well, we know that doesn’t work. That’s not the answer.” And when you have to go back and say: “Well, no, maybe not what you know, but if we really go and dive into the definition, if we dive into the requirements, and if you can really comply with all that, which I think in a lot of cases is not just something you can do just like that, but you really have to do with with computer forces or with a smart solution, then we are getting somewhere. And it's a pity that because of the past it has given this a bad name, and I think we still have a lot of job to do in order to actually polish the definition of what is or the terminology of what is understood under GDPR-compliant Pseudonymisation.
Gary LaFever 24:48
Well, thank you for that. So, we're going to move on now to what the EDPB lists as the third requirement of Statutory Pseudonymisation, and this is actually covered in five different paragraphs of the Final Schrems II Guidance - paragraphs 79, 85, 86, 87, and 88. And it says that you have to be able to protect against the use of information from other datasets, third-party datasets that are not included within your own to ensure you cannot re-identify the data subjects. And this oftentimes necessitates the use of different replacement tokens at different times for different purposes, what I use the term dynamism to refer to. So, different tokens at different times for different purposes, so you can prevent this re-identification and you're doing that because you make it so that you don't see the correlations between the different datasets unless you have permission to this additional information that the data controller or an authorised party has.
And so, this is something and Maggie referred to it that's often referred to as the Mosaic Effect. There is actually more information on this at www.MosaicEffect.com. And this is also very much the same concept that Steffen spoke to when he talked about overencryption, which is in certain circumstances, depending on the volume of the data and the different use cases, you need to use different tokens, at different times, for different purposes. And all of this is about making it so that if you don’t have access to that additional information, even if it’s coming from an additional external dataset, you cannot re-identify the party. Maggie, would you like to take the next one?
Magali Feys 26:26
Yes. This goes to the fourth EDPB requirement for Statutory Pseudonymisation, which goes about non-algorithmic look up tables and this requirement comes from paragraph 89 of the EDPB Final Schrems II Guidance, which requires taking into account the vulnerability of cryptographic techniques, particularly overtime to brute force attacks and quantum computing risk and necessitates the use of non-algorithmic-derived lookup tables in certain instances, and I think this goes to the fact that cryptography is not only about the fact to never being able to reidentify the data. There are, today, I think mathematical controls that are put in place. But at a certain point, techniques and technology are evolving and I think quantum computing will become bigger, better, and more popular and will enable computation that is so powerful that it will break those mathematical controls. So, the EDPB really also stated that a requirement is also to look at non-cryptographic control that can be broken in order to future-proof the solution.
Gary LaFever 27:50
Steffen, any thoughts or ideas or perspectives on this one?
Steffen Weiss 27:53
Yeah. Just think about the scenario. I mean, you have certain pseudonyms generated and then you lose them. You lose them together with the cryptographic key being used, and you did rely on a certain algorithm. And now, this is where the computing power comes into place. I mean, as Maggie said, the power of quantum computing increases the performance. So, these so-called brute force attacks can be used to really get back to the identifiers used to generate the pseudonyms. In case you have this information, you have the pseudonym, you have the cryptographic key, and the algorithm used. So, you can use that technique, the computing power to really use brute force attacks and re-identify the data subject. This needs to be avoided. So, in some instances, it makes perfect sense to not rely on algorithmic lookup tables because of this power of computing we have at the moment, which is evolving over time.
Gary LaFever 28:48
Absolutely. So, this leads to our ninth truth of Statutory Pseudonymisation, but the fifth and last requirement as we read the EDPB Final Guidance for Statutory Pseudonymisation, which Steffen is going to go over, which I think is absolutely critical - controlled relinkability. Steffen, please?
Steffen Weiss 29:06
The fifth EDPB requirement for Statutory Pseudonymisation comes from combining before proceeding items to meet the requirement of paragraph 85, one of the EDPB Final Schrems II Guidance that GDPR Pseudonymisation is achieved only if a data exporter transfers personal data processed in such a manner that the personal data can no longer be attributed to a specific data subject nor be used to single out the data subject in the larger group without the use of additional information.
Gary LaFever 29:36
And that's at the heart of the EDPB Final Guidance on Schrems. This is where they say if you satisfy the requirements of Statutory Pseudonymisation, then you can in fact transfer data transatlantic or to other non-EEA countries and you can have outsourced capabilities and cloud capabilities. But when you really think about what it's saying, it's saying this controlled relinkability must be so strong that no foreign government, no third party country government can break it and that's a high standard. Any thoughts or perspectives on that?
Magali Feys 30:12
Well, I think this really underscores the second half of the definition of Article (4)(5) that only the data with the data controller should be able to do the relinking, and you have to be able to prove it mathematically. So, I think that is really enforcing that second half of the definition and underlining that.
Gary LaFever 30:37
Steffen?
Steffen Weiss 30:38
Yeah. It just reflects the EDPBs opinion on the assessment of the local provisions granting access to public bodies or authorities. So, in case you want to transfer personal data to a third country and you do the legal assessment and you come to a certain conclusion and in many cases, you don't have this in a nutshell a similar or adequate level of data protection in that third country, so you need additional measures, supplementary measures, and this is where Pseudonymisation comes into play because the EDPB itself is referring to Pseudonymisation and the guidance on Schrems II, but then they are saying and reminding you that you have to implement it properly. So, you have to think of all of the information, the direct identifiers, and indirect identifiers which can be used to really identify the data subject and this is just a reminder for us for the cross border data transfers we have to be aware of.
Gary LaFever 31:31
Well said. For our tenth truth of Statutory Pseudonymisation, we wanted to highlight some of the benefits under the GDPR and these other laws have similar benefits as well. Why go to all this trouble of this heightened obligation, the two-part definition to satisfy the requirements of Statutory Pseudonymisation? It's because there are statutorily granted benefits. Maggie said earlier many people try to use anonymisation to get outside of the law. Stephen re-emphasised that. But the fact of the matter is you get statutorily expanded data use rights, and we are going to touch upon some of those.
So, the first one is that if you have satisfied this heightened standard for Statutory Pseudonymisation you have a better position to argue, to show, to prove that your processing is compatible for new or secondary processes beyond that for which the data was originally collected under GDPR Article 6(4). So, that’s the first one.
Another one, which is a big one, is support for legitimate interest processing under Article 6(1)(f). The reality is a lot of people think legitimate interest processing has been abused in the past, and it has because it has been simply acclaimed to a legitimate interest in the outcome, the output of the processing, when in fact with properly pseudonymised data that meets the requirements of Statutory Pseudonymisation, you are putting the controls into transformed elements so that the data is protected, has reduced the risk of the data subjects, so you can show and prove that you can satisfy the balancing of interest test. So, when we say that it helps to support legitimate interest processing, we mean lawful legitimate interest processing.
Another big one is data sharing and combining within the GDPR itself under Articles 11(2) and 12(2) speak to a processing situation where a processor or a co-controller is not themselves in possession of the keys required to re-identify. And in both of those situations, significant expanded data use rights are granted. So, again, Pseudonymisation when implemented correctly to these heightened standards can enhance and improve and enlarge the lawful right to share and combine data.
And then, Data Minimisation, Purpose Limitation, Data Protection by Design and by Default under Articles 5(1)(b), 5(1)(b)(c), and 25(1) - those are obligatory. They are not optional, but they can all be complied with more effectively using Statutory Pseudonymisation. Maggie, do you want to hit the next one?
Magali Feys 34:10
One of the benefits also includes its support for scientific historical research and statistical processing to enable secondary processing, sharing, and combining of data by expanding purpose limitation, extended permissible storage of data, and processing of sensitive or special categories of personal data under Article 9(2)(j).
Gary LaFever 34:37
And all those are I would think very highly reflective and helpful in healthcare research and processing of data.
Magali Feys 34:44
The fact that we actually use Pseudonymisation in the pan-European research projects, as I mentioned already with the COVID project in order to develop and train an algorithm to diagnose COVID much faster in the early stages, and we needed a lot of data of about 42 European hospitals and through GDPR-compliant Pseudonymisation, we were really able to share that data to actually be able to say we are going to use that data in order to train that algorithm under our research project and really go in so far as really doing AI with all that data, and it was also seen as through the different contracts with the different DPOs as seen as the way forward. The only thing I want to stress there is of course Pseudonymisation is one part of your exercise. It is not going to solve your transparency principles and obligations, but it really helped us and it was the way forward in sharing and using the data.
Magali Feys 35:48
Gary, with regards to Data Protection by Design, I want to really go there with a really practical example we had with one of our clients who developed a crowding measurement at the Belgium coast in COVID times, and they actually had to film the people going to the coast. And so, from a legal point of view, we got stuck because what was our legal grounds to do the processing. And we had, of course, not legitimate interest because it was for the government, so we had the public interest.
Because you're capturing every images, it is really personal data but really also enabling our clients to be innovative and to say: “Well, is there a way in order to GDPR compliantly pseudonymise that data?” They really started thinking about it, and they developed a solution that was not only blurring the people in there, but really working with smart counters. So, they were innovative also in the way they actually protected the data. And what was also good about that is that actually it solves one of their major problems because video images are really a lot of data to store and if they had to send that from the camera to the server, that would have to have them really have a lot of computational power to store that data. And by using Pseudonymisation and keeping the images on the camera on the device and not sending and only sending the smart counters while still having very accurate data to do the measurements, they were able to actually solve all the problems and give us the legal ground actually to do our DPIA and say why this is acceptable and you can go ahead.
And I think what is really nice in this and it can help a lot of people is there was a complaint because on television it was sold as a sort of tracking and tracing mechanism, and there was a complaint before about supervisory authority and the authority really looked at it and said: “Well, this is really because you're using GDPR-compliant Pseudonymisation. This is Data Protection by Design.” And so, this client now has a footfall AI innovative solution, which got a stamp from the supervisory authority stating that it is Data Protection by Design. And for me, it became very apparent that it is the translation of ethical and legal principles into technical safeguards, and I think people should be very aware of that.
Gary LaFever 38:18
Very well said. Steffen, anything you want to add before we go to the last one?
Steffen Weiss 38:21
If you talk about benefits of Statutory Pseudonymisation under the GDPR, you should not forget about the member state laws. I mean, just to give you an example of Germany, we do have some provision in the resource sector allowing the processing of personal data in case you have appropriate safeguards in place, and this is where yet again civilization comes into play. In case you have Pseudonymisation properly implemented according to the GDPR, you can use that member state law provision to process personal data. So, please do not just talk about GDPR. Do not forget member state laws, which can be taken into account if you really want to get a holistic view on Pseudonymisation.
Gary LaFever 39:01
And that raises the additional point which is that Statutory Pseudonymisation continues to gain momentum around the globe. There will be specific country and specific state laws that actually could give you the benefit as well, and that's really why we're here talking about this because the heightened requirements for Statutory Pseudonymisation are well worth the effort because of the benefits, the benefits both under the GDPR, other member state laws, laws of other jurisdictions, and other requirements of vertical industries as well.
Steffen Weiss 39:32
The last benefit we can talk about is about reduced notification obligations and liability. So, you are aware, of course, of data breaches under the GDPR. So, in case you have a breach of security, meaning a breach of confidentiality or integrity or availability of personal data, you might be obliged to notify this breach to the supervisory authority in case there is a risk to the data subject and this is yet again where Pseudonymisation is quite handy. So, in case you have properly implemented Pseudonymisation, you might be exempted from notifying a personal data breach for that pseudonymised data, so just real benefit in case you use Pseudonymisation on personal data. And again, liability is also an issue for many, many organisations and companies.
So, in case you have a breach of security under Article 32, you might be subject to compensation by the data subject. So, what to do? You can use Pseudonymisation to really implement a technical safeguard on the data. So, in case, for breach of security, for example confidentiality, you might be less concerned in case you lose access to pseudonymised data or someone else is getting access to pseudonymised data. But as a reminder, you have to do it properly. If you haven’t done it properly pseudonymising personal data, this access to personal data can be really a risk for the companies and organisations because, as I have mentioned before, you might be obliged to notify and you also might be obliged to compensate the data subject in case the third party has access to the data, which the third party is not allowed to have access to.
Gary LaFever 41:15
Ironically, in one of the rare instances of which I am aware where the US has more stringent requirements even under the EU, in California for every breach that occurs, there are statutory damages, so you don't even have to prove them. Statutory damages of $750 per consumer per incident. And so, if you think of situations and there are many where you have millions of records, every breach could be $750 of statutory damages per consumer per incident. And so, it's not just the GDPR. Both with respect to greater data use and innovation that is enabled by Statutory Pseudonymisation, as well as limitations of liability, reductions of liability, and perhaps even elimination of disclosure obligations. If you can show that it was done properly, Pseudonymisation is something to be considered.
Gary LaFever 42:14
We want to thank everyone for joining us for this third episode of the Pseudonymisation Podcast, and I very much want to thank our special guests, Maggie and Steffen, and we hope you all heard and realise that Pseudonymisation is probably not what you thought, but it's going to be a lot more going forward in the future than it has been in the past because of the balancing between data use and data protection in a way that gives you greater value, statutorily granted expansive rates, reduced liability in such a way that as it travels around the globe as it were not only does it enable lawful international transfers under Schrems II, but it could enable greater data sharing and combining hopefully leading to new innovations, even scientific and medical breakthroughs. So, thank you for joining us today. Have a good day.
Episode No. 3: Top three takeaways from this episode of the Pseudonymisation Webinar
Gary LaFever 00:00
Welcome to the third episode of the Pseudonymisation Podcast. My name is Gary LaFever, but I'm here to introduce the two guests we have with us today, Maggie and Steffen. Maggie, please introduce yourself.
Magali Feys 00:14
Thank you, Gary, for having me on this podcast. I’m Magali Feys or Maggie Feys. I am the Founder and Partner of AContrio Law, a boutique law firm specialising in data protection. And from that perspective, we are really working and seeing the benefits from Statutory Pseudonymisation because in COVID times, we led a very pan-European big research project where actually GDPR-compliant Pseudonymisation was applied in order to unlock the data, share the data, and at the same time balance the interest of the patients against the utility of the data. So, that was very interesting to see. From that, I am also taking that in my academic research for the University of Ghent where I’m actually doing a doctoral thesis on the secondary use of medical data for research purposes.
Gary LaFever 01:11
Fantastic. Thank you, Maggie. Steffen, please.
Steffen Weiss 01:15
Thank you, Gary, for inviting me. Hi, my name is Steffen Weiss. I'm from the German Association for Data Protection and Data Security (GDD). We are a nonprofit association, and I'm in charge of international affairs being a member of the board, and we are also very much connected to Pseudonymisation. We are working on a code of conduct on Pseudonymisation together with Bitkom and Germany, and we want this to be a transnational code of conduct applicable in several member states in Europe. So, I’m happy to talk about the topic today about Statutory Pseudonymisation.
Gary LaFever 01:48
Fantastic. And as I said, my name is Gary LaFever. I'm the CEO and General Counsel at Anonos. This Pseudonymisation Podcast is special in that almost a year ago to the day, Steffen and I recorded “The 10 Truths of GDPR Pseudonymisation”. In less than a month after we recorded that, the EDPB came out with their Final Guidance on Schrems II where Pseudonymisation is actually identified as one of the ways to have lawful international transfer and processing of data. And so, much has happened since then, and we will touch upon that during this podcast. So, what we will do here is an informal format but we are going to take turns reading one of the 10 Truths and then just talking about it. So, I’ll kick it off.
Statutory Pseudonymisation, which bears its heritage to Article 4(5) of the GDPR in the definition of Pseudonymisation there, is much more than just a privacy-enhancing technique and we will go into more detail on this. But the important thing to realise is there are significantly different and more stringent requirements than privacy-enhancing techniques in the past that may have been known as pseudonymization. I laughingly say spelled with a Z as opposed to an S or hashing tokenization or key coding. While it may sound familiar, Statutory Pseudonymisation as originally defined under the GDPR has a very different meaning and set of requirements. Any perspectives on that?
Magali Feys 03:21
Gary, if I may because I really appreciated the opportunity to also be in the first podcast where together with other data protection experts, we focused really on that fact because I really believe that a lot of people do not realise with this introduction of this definition and what Statutory Pseudonymisation is under Article 4(5). People don't understand that it is really a heightened standard and that it is a new standard and there's a new kid town and that is indeed not as easy as one can think to say by just applying a sort of privacy-enhancement technique that we fulfill this definition.
Gary LaFever 04:05
Thank you for that. Steffen, any perspective on your part?
Steffen Weiss 04:08
I can reminisce about our old definition of Pseudonymisation in our Federal Data Protection Act, and the definition was different from the one under GDPR now. It was a more easier approach of Pseudonymisation. It was all about replacing identifiers like name and other identifiable information from that person and that was called Pseudonymisation. And now, we dive deeper into the definition under the GDPR. You will see that the definition has many, many aspects which you have to take into account when you want to really pseudonymise personal data. So, we are going to go dive deep into this and have to talk about it.
Gary LaFever 04:45
Fantastic. Maggie, would you like to hit the second truth?
Magali Feys 04:48
Yes. Well, under the GDPR, the requirements of Article 4(5) fundamentally redefines Pseudonymisation. First of all, it dramatically expanded the scope to include all personal data, which is much more comprehensive than only the direct identifiers because I really see that people are really looking at direct identifiers. But along with the definition of personal data, it's a very broad definition. And of course, the definition of Article 4(5) also goes in that same direction. What is, I think, even more important and I really want to emphasise that as a second part is that it dramatically restricts the scope of additional information that is lawfully able to reattribute personal data to individuals because we encounter a lot of confusion there. People do not always realise that you have to be able to prove and even prove in a mathematical way, however, that the data controller’s information is unique and that you can't find it anywhere else.
Gary LaFever 06:12
Interesting. So, Steffen, was this part of what you were getting at before where the prior definition of Pseudonymisation was not as specifically tied to all data types, both direct and indirect, that would otherwise be considered personal data?
Steffen Weiss 06:27
Yes, exactly, Gary. We kind of left out the additional information, which you can use to identify the individual and this is a very interesting aspect of Article 4(5). I mean, with this additional information, you can identify the data subject so you have to essentially protect it. And at the same time, you have to reduce the additional information to a minimum in order to approach a risk-based approach because if you have broad additional information to identify the data subject, there is a risk if someone else has taken this additional information to identify the data subject. So, it needs special effort to protect, but at the same time, you have to reduce the amount of additional information as a security measure at that stage, so it is really changing in view of our own definition of Pseudonymisation in Germany.
Gary LaFever 07:18
Very interesting. So now, Steffen has the most difficult meaning the longest of the 10 Truths. And on the transcript of this podcast, we will have a copy of this for those who want to follow it. But Steffen, if you could, if you could go through number three for us.
Steffen Weiss 07:34
Sure. The definition of Statutory Pseudonymisation under the GDPR Article 4(5) contains two halves, which must be read and construed together. They cannot be read separately from one another. The first half of the Article 4(5) definition by itself means the outcome must be for a dataset and not just a technique applied to individual fields because of the expansive definition of personal data, which is all information it relates to identify an identifiable individual as compared to just direct identifiers. Then, additional information could come from anywhere, except the dataset itself and replacement of direct identifiers with static tokens could suffice, if this was as far as the definition went but the definition does not stop here. It has a second half.
However, when combined with the second half of the definition, the requirements regarding additional information mean that any combination of additional information sufficient to reattribute data to individuals must be under the control of the data controller or an authorised party. To achieve this level of protection, it is necessary to, first of all, protect all indirect identifiers as well as direct identifiers. And secondly, define suitable intervals for changing pseudonym and key combinations based on time with data volume to avoid unauthorised relinking. This is sometimes also referred to as overencryption, which is some sort of technique to insert some dynamism into Pseudonymisation.
Gary LaFever 09:09
Great observation there. And also, in the transcript, we will have a link to some prior work that the GDD has done, not their current activity but prior work on Pseudonymisation that actually included a reference to overencryption, and it may be clear that depending on the time intervals and the volume of the data and the access to additional information, this act of overencrypting as it were may well be necessary. I do think this two-part definition is something that people can gloss over, and you have to read both and understand. The first one is almost a legal requirement. It is a legal requirement that a lawyer, I think, could understand. But the second one almost requires some data science experience to realise what high standard this is that only the data held by the data controller or authorised party should be in a position to re-identify. Maggie, any perspectives on that?
Magali Feys 10:03
In my experience, that second half of the definition, that is really what a lot of people miss because, for example, within hospitals and research around medical data, we see that a lot of static tokens are being used. So, a patient is always, for example, replaced by x1. But then, of course, if you share that data in a couple of research projects with the same other third party, then of course that third party can start relinking those different datasets, and I don't think that people really grasp the fact that that is also part of the definition and that you really have to be able to also comply with that second part of the definition, which indeed is very technical and I think that's also why you need a technical-skilled person next to your side if you're only a lawyer in order to really grasp what it means in a specific use case.
Gary LaFever 10:58
And Steffen, I'm aware of the fact that when you work on these codes of conduct, you engaged with many different stakeholder groups to try to get different perspectives. Is that one of the reasons as well to make sure that you have a reflective body of knowledge, so that these different requirements can be accurately presented?
Steffen Weiss 11:15
Well, yes, we have to gather some expert groups. We needed the lawyers for the first half of the definition. We also needed the informatics for the second half, and it was not quite easy to get these two people together to be honest, but it just reflects the legal requirements we have under the GDPR under Article 4(5). I mean, on the one hand, you have to focus on the transformation process. You generate a pseudonym, and this cannot be attributed to a data subject, and this is where we put most of the efforts into in the past. So, it was all about using tokenisation to generate pseudonyms, which cannot be attributed to the data subject. But then came the second half of the definition. We have this additional information, and you cannot forget, Gary, that this additional information can be direct identifiers and it can be indirect identifiers. So, this is all related to the broad definition of personal data. So, you cannot forget entering the identifiers in your systems. These all need to be protected in case they are being used to re-identify the data subject.
Gary LaFever 12:21
That is certainly what we discovered. People may have it covered for direct identifiers, but it's the indirect identifiers that can just as easily oftentimes be used to re-identify. And so, you're right. The protection has to go throughout the system to apply to all the different elements of personal data.
So, the fourth one actually catches some people by surprise and that's why this is called The 10 Truths of Statutory Pseudonymisation. The term Pseudonymisation as defined - I should actually say redefined under Article 4(5) of the GDPR is picking up momentum around the globe because essentially identical statutory language is now found not only in the EU GDPR, the UK GDPR, but the data protection regulations of Brazil, Japan, South Korea, and five states - California, Virginia, Colorado, Utah, and Connecticut. So, all told there are more than 35 jurisdictions that have the same definition. And in each of those cases, it does provide this means that many people overlook of reconciling conflicts between data use and protection, and other countries and states are looking to adopt this or very similar definitions that incorporate this concept of Statutory Pseudonymisation because of its unique ability to both protect data and enable its use because under controlled authorised conditions, it can be relinked back or reattributed back to individuals. Any perspectives on that?
Magali Feys 13:55
If I may, because indeed I definitely think there's momentum. We also see a lot of new projects. For example, the European Health Data Space and I'm going in a couple of weeks to Helsinki to also discuss about that, and I have seen on the program a lot of speaking about anonymisation. And I think in this momentum it's also going to be very important to really use the terminology given so that we speak about the same thing because in my humble opinion, I think anonymisation today is much too often used as a sort of graduation of obfuscation rather than it is really in line with what is explained in Recital 26 of the GDPR and is definitely not in line with Article 4(5) under GDPR-compliant Pseudonymisation. I've seen that also too much in real life that they are focusing on anonymisation, as Steffen also mentioned, as only using tokenisation or masking of direct identifiers. And I think as the momentum is here, it is the right time but we also have to use the right words or at least be sure that we all agree that we are talking about the same thing given those different legislations and terminology being used.
Gary LaFever 15:19
Steffen, do you have similar encounters with people using words imprecisely?
Steffen Weiss 15:24
I do. I mean, it really depends on the size of the organisation and the background of the staff because you need the staff and the knowledge to be able to really implement Pseudonymisation according to the GDPR, and I did see isolated approaches among organisations using certain techniques, which were not coordinated at all. This is why we do hope that our code of conduct will help to really make this coordination possible. And it hit me quite by surprise, Gary, talking about this momentum that the US is introducing Pseudonymisation in the Federal State Laws. I did not know that, and I was also surprised to see Brazil taking on the momentum and re-introducing Pseudonymisation into their law. I think it was from 2018. And according to the Brazilian legislator, it’s not all about Pseudonymisation as a security measure. This is also part of the momentum we are having at the moment, and it’s about enabling data processing.
So, let's take the example of Brazil. In case you do research with health data for public purposes and you rely on a proper implemented Pseudonymisation, you can process personal data. You have the lawful basis for this, but you do need to properly implement Pseudonymisation. So, Brazil’s take is pretty much not one to one but most of the content of our definition of the GDPR on Pseudonymisation, and they are also keen on the second half of the definition, this additional information that has to be protected and separated.
Magali Feys 16:54
I just wanted to also add because I think also very important is my feeling that everybody is always very lenient towards anonymisation because it gets them outside the GDPR. But first of all, if you are really considering anonymisation, it really means that you can't do, for example, longitudinal studies and we have been drafting a bill for the Flemish government where indeed one of the perspective is to be able to do longitudinal studies to help patients and to help the data subjects. So, you really need that relinkability on the one hand. And on the other hand, I think also that with anonymisation, where you would really cut off the link between the data subject and the data that you're also taking away a couple of standard ethical rights of the data subject, which may not all be included in the GDPR and as the GDPR stated in the first and the fourth recital that it is a fundamental right but not an absolute right. So, I really see the benefits of Pseudonymisation in order to really improve and facilitate data utility, whilst at the same time also be able to balance that against the protection of the data subjects and their rights, which are not only related to data protection.
Gary LaFever 18:22
You know, both of you have touched upon something that I think really goes to the heart of the next five truths. As I mentioned before, less than a month after Steffen and I recorded our prior 10 Truths of GDPR Pseudonymisation, the EDPB came out with the Final Guidance for Schrems II. So, the next five truths each key off of specific paragraphs or footnotes within that EDPB Final Guidance, and the reason that's so relevant and ties into both of what you just said is it's about using Pseudonymisation as a data enabler - innovation, the ability to process, the ability to process data and use cross-atlantic transit kind of capabilities, US-operated cloud, sharing partners, distribution - if you can show that you've satisfied these following five requirements set forth by the EDPB in the Final Schrems II Guidance. Maggie, would you please start with number five?
Magali Feys 19:17
Five says that it's protecting all data elements and I think we already touched upon that but it is really in the first EDPB the requirement for Statutory Pseudonymisation comes from the footnotes 83 and 84 of the EDPB Final Schrems II Guidance. This requirement stipulates that achieving GDPR-compliant Pseudonymisation status must be evaluated for a dataset as a whole and not just particular fields of that dataset. This requires assessing the degree of protection for all the data elements in that dataset going beyond direct identifiers but also to include indirect identifiers and attributes consistent with the expansive definition of personal data under the GDPR of Article 4(1).
Gary LaFever 20:09
And so, again, I know we touched upon this earlier, but what we're really doing here is emphasising these five here that this is what the EDPB sets out in the Final Schrems II Guidance. And so, this is not just mere hearsay or discussions but, rather, you can track this to the EDPB Final Guidance and therefore provide some certainty and predictability as to what's required for Statutory Pseudonymisation, particularly as additional countries and states begin to adopt the same definition. Steffen, do you wanna hit number six?
Steffen Weiss 20:39
Protecting against singling out attacks. The second EDPB requirement for Statutory Pseudonymisation comes from Paragraph 85 of the EDPB Final Schrems II Guidance and mandates protection against singling out of the data subject in the larger group effectively making the use of either K-anonymity or aggregation mandatory.
Gary LaFever 21:00
And what I find interesting about this one, Steffen, is this really does speak to the fact that it has to be at the dataset level, you know? Because I believe with Pseudonymisation, a lot of people used to look at it and say: “Okay. I'll protect this data element in this row.” But the reality is, it may be fine if you only had one row of data, but the way that the data element is protected within all of the rows of the dataset actually becomes identifying, so I do think this prohibition against singling out, the requirement to protect against it, again is almost a data science concept. You have to realise that what might appear to be protected in a single row of data has to be compared against the entirety of the dataset to see if it actually meets that statutory requirement. Any other thoughts or observations on this one?
Steffen Weiss 21:46
I do have to agree, Gary. I mean, you have to take this holistic view of the dataset you are working with. So, you cannot just look at the individual set. You have to take this holistic view, and the EDPB has stressed this in the recommendations on the Schrems II data transfer. So, it’s an important aspect to have an eye on. And if we talk about K-anonymity and singling out, there is a chance of singling out attacks. I mean, if I could generally make this example and I’m just making this up, you have a list of patients. I mean, I don’t want to connect Pseudonymisation with patient data at all times. I mean, it has its benefits in many areas as well, but just let me do this one example.
So, you have your patients list with the name and a certain disease and age. And then you come to the idea: “Okay. We need to really maybe generalise the information or aggregate the information so this person cannot be identified.” So, you strip him maybe of the name and the surname. And then, you still have information on the diseases and the age. And in case you have maybe two or even if you strip certain ages to a certain range of age, there is still a chance of singling out a person. I mean, if two persons have the same attributes and have the same diseases although you do not know their names being their direct identifiers, there is a chance of singling out attacks. So, you have to avoid this at all times and this is a really important requirement and this is a technical aspect of Pseudonymisation, avoiding these singling out attacks.
Gary LaFever 23:12
And that's heightened from what existed in the past, and I think that's what we're talking about. People don't necessarily realise it. Maggie?
Magali Feys 23:17
Steffen, your example is so to the point of what I almost daily see in medical records and where only the direct identifiers are being stored or used tokenisation on them. And the problem is all so that within the research, for example, the mosaic effect from Harvard, it has been proven then that anonymisation does not work but it is because this is not done properly and that has given it its bad name. And so, whenever I even start to speak and say I am going to talk about GDPR-compliant Pseudonymisation, I almost immediately get shut up to say: “Well, we know that doesn’t work. That’s not the answer.” And when you have to go back and say: “Well, no, maybe not what you know, but if we really go and dive into the definition, if we dive into the requirements, and if you can really comply with all that, which I think in a lot of cases is not just something you can do just like that, but you really have to do with with computer forces or with a smart solution, then we are getting somewhere. And it's a pity that because of the past it has given this a bad name, and I think we still have a lot of job to do in order to actually polish the definition of what is or the terminology of what is understood under GDPR-compliant Pseudonymisation.
Gary LaFever 24:48
Well, thank you for that. So, we're going to move on now to what the EDPB lists as the third requirement of Statutory Pseudonymisation, and this is actually covered in five different paragraphs of the Final Schrems II Guidance - paragraphs 79, 85, 86, 87, and 88. And it says that you have to be able to protect against the use of information from other datasets, third-party datasets that are not included within your own to ensure you cannot re-identify the data subjects. And this oftentimes necessitates the use of different replacement tokens at different times for different purposes, what I use the term dynamism to refer to. So, different tokens at different times for different purposes, so you can prevent this re-identification and you're doing that because you make it so that you don't see the correlations between the different datasets unless you have permission to this additional information that the data controller or an authorised party has.
And so, this is something and Maggie referred to it that's often referred to as the Mosaic Effect. There is actually more information on this at www.MosaicEffect.com. And this is also very much the same concept that Steffen spoke to when he talked about overencryption, which is in certain circumstances, depending on the volume of the data and the different use cases, you need to use different tokens, at different times, for different purposes. And all of this is about making it so that if you don’t have access to that additional information, even if it’s coming from an additional external dataset, you cannot re-identify the party. Maggie, would you like to take the next one?
Magali Feys 26:26
Yes. This goes to the fourth EDPB requirement for Statutory Pseudonymisation, which goes about non-algorithmic look up tables and this requirement comes from paragraph 89 of the EDPB Final Schrems II Guidance, which requires taking into account the vulnerability of cryptographic techniques, particularly overtime to brute force attacks and quantum computing risk and necessitates the use of non-algorithmic-derived lookup tables in certain instances, and I think this goes to the fact that cryptography is not only about the fact to never being able to reidentify the data. There are, today, I think mathematical controls that are put in place. But at a certain point, techniques and technology are evolving and I think quantum computing will become bigger, better, and more popular and will enable computation that is so powerful that it will break those mathematical controls. So, the EDPB really also stated that a requirement is also to look at non-cryptographic control that can be broken in order to future-proof the solution.
Gary LaFever 27:50
Steffen, any thoughts or ideas or perspectives on this one?
Steffen Weiss 27:53
Yeah. Just think about the scenario. I mean, you have certain pseudonyms generated and then you lose them. You lose them together with the cryptographic key being used, and you did rely on a certain algorithm. And now, this is where the computing power comes into place. I mean, as Maggie said, the power of quantum computing increases the performance. So, these so-called brute force attacks can be used to really get back to the identifiers used to generate the pseudonyms. In case you have this information, you have the pseudonym, you have the cryptographic key, and the algorithm used. So, you can use that technique, the computing power to really use brute force attacks and re-identify the data subject. This needs to be avoided. So, in some instances, it makes perfect sense to not rely on algorithmic lookup tables because of this power of computing we have at the moment, which is evolving over time.
Gary LaFever 28:48
Absolutely. So, this leads to our ninth truth of Statutory Pseudonymisation, but the fifth and last requirement as we read the EDPB Final Guidance for Statutory Pseudonymisation, which Steffen is going to go over, which I think is absolutely critical - controlled relinkability. Steffen, please?
Steffen Weiss 29:06
The fifth EDPB requirement for Statutory Pseudonymisation comes from combining before proceeding items to meet the requirement of paragraph 85, one of the EDPB Final Schrems II Guidance that GDPR Pseudonymisation is achieved only if a data exporter transfers personal data processed in such a manner that the personal data can no longer be attributed to a specific data subject nor be used to single out the data subject in the larger group without the use of additional information.
Gary LaFever 29:36
And that's at the heart of the EDPB Final Guidance on Schrems. This is where they say if you satisfy the requirements of Statutory Pseudonymisation, then you can in fact transfer data transatlantic or to other non-EEA countries and you can have outsourced capabilities and cloud capabilities. But when you really think about what it's saying, it's saying this controlled relinkability must be so strong that no foreign government, no third party country government can break it and that's a high standard. Any thoughts or perspectives on that?
Magali Feys 30:12
Well, I think this really underscores the second half of the definition of Article (4)(5) that only the data with the data controller should be able to do the relinking, and you have to be able to prove it mathematically. So, I think that is really enforcing that second half of the definition and underlining that.
Gary LaFever 30:37
Steffen?
Steffen Weiss 30:38
Yeah. It just reflects the EDPBs opinion on the assessment of the local provisions granting access to public bodies or authorities. So, in case you want to transfer personal data to a third country and you do the legal assessment and you come to a certain conclusion and in many cases, you don't have this in a nutshell a similar or adequate level of data protection in that third country, so you need additional measures, supplementary measures, and this is where Pseudonymisation comes into play because the EDPB itself is referring to Pseudonymisation and the guidance on Schrems II, but then they are saying and reminding you that you have to implement it properly. So, you have to think of all of the information, the direct identifiers, and indirect identifiers which can be used to really identify the data subject and this is just a reminder for us for the cross border data transfers we have to be aware of.
Gary LaFever 31:31
Well said. For our tenth truth of Statutory Pseudonymisation, we wanted to highlight some of the benefits under the GDPR and these other laws have similar benefits as well. Why go to all this trouble of this heightened obligation, the two-part definition to satisfy the requirements of Statutory Pseudonymisation? It's because there are statutorily granted benefits. Maggie said earlier many people try to use anonymisation to get outside of the law. Stephen re-emphasised that. But the fact of the matter is you get statutorily expanded data use rights, and we are going to touch upon some of those.
So, the first one is that if you have satisfied this heightened standard for Statutory Pseudonymisation you have a better position to argue, to show, to prove that your processing is compatible for new or secondary processes beyond that for which the data was originally collected under GDPR Article 6(4). So, that’s the first one.
Another one, which is a big one, is support for legitimate interest processing under Article 6(1)(f). The reality is a lot of people think legitimate interest processing has been abused in the past, and it has because it has been simply acclaimed to a legitimate interest in the outcome, the output of the processing, when in fact with properly pseudonymised data that meets the requirements of Statutory Pseudonymisation, you are putting the controls into transformed elements so that the data is protected, has reduced the risk of the data subjects, so you can show and prove that you can satisfy the balancing of interest test. So, when we say that it helps to support legitimate interest processing, we mean lawful legitimate interest processing.
Another big one is data sharing and combining within the GDPR itself under Articles 11(2) and 12(2) speak to a processing situation where a processor or a co-controller is not themselves in possession of the keys required to re-identify. And in both of those situations, significant expanded data use rights are granted. So, again, Pseudonymisation when implemented correctly to these heightened standards can enhance and improve and enlarge the lawful right to share and combine data.
And then, Data Minimisation, Purpose Limitation, Data Protection by Design and by Default under Articles 5(1)(b), 5(1)(b)(c), and 25(1) - those are obligatory. They are not optional, but they can all be complied with more effectively using Statutory Pseudonymisation. Maggie, do you want to hit the next one?
Magali Feys 34:10
One of the benefits also includes its support for scientific historical research and statistical processing to enable secondary processing, sharing, and combining of data by expanding purpose limitation, extended permissible storage of data, and processing of sensitive or special categories of personal data under Article 9(2)(j).
Gary LaFever 34:37
And all those are I would think very highly reflective and helpful in healthcare research and processing of data.
Magali Feys 34:44
The fact that we actually use Pseudonymisation in the pan-European research projects, as I mentioned already with the COVID project in order to develop and train an algorithm to diagnose COVID much faster in the early stages, and we needed a lot of data of about 42 European hospitals and through GDPR-compliant Pseudonymisation, we were really able to share that data to actually be able to say we are going to use that data in order to train that algorithm under our research project and really go in so far as really doing AI with all that data, and it was also seen as through the different contracts with the different DPOs as seen as the way forward. The only thing I want to stress there is of course Pseudonymisation is one part of your exercise. It is not going to solve your transparency principles and obligations, but it really helped us and it was the way forward in sharing and using the data.
Magali Feys 35:48
Gary, with regards to Data Protection by Design, I want to really go there with a really practical example we had with one of our clients who developed a crowding measurement at the Belgium coast in COVID times, and they actually had to film the people going to the coast. And so, from a legal point of view, we got stuck because what was our legal grounds to do the processing. And we had, of course, not legitimate interest because it was for the government, so we had the public interest.
Because you're capturing every images, it is really personal data but really also enabling our clients to be innovative and to say: “Well, is there a way in order to GDPR compliantly pseudonymise that data?” They really started thinking about it, and they developed a solution that was not only blurring the people in there, but really working with smart counters. So, they were innovative also in the way they actually protected the data. And what was also good about that is that actually it solves one of their major problems because video images are really a lot of data to store and if they had to send that from the camera to the server, that would have to have them really have a lot of computational power to store that data. And by using Pseudonymisation and keeping the images on the camera on the device and not sending and only sending the smart counters while still having very accurate data to do the measurements, they were able to actually solve all the problems and give us the legal ground actually to do our DPIA and say why this is acceptable and you can go ahead.
And I think what is really nice in this and it can help a lot of people is there was a complaint because on television it was sold as a sort of tracking and tracing mechanism, and there was a complaint before about supervisory authority and the authority really looked at it and said: “Well, this is really because you're using GDPR-compliant Pseudonymisation. This is Data Protection by Design.” And so, this client now has a footfall AI innovative solution, which got a stamp from the supervisory authority stating that it is Data Protection by Design. And for me, it became very apparent that it is the translation of ethical and legal principles into technical safeguards, and I think people should be very aware of that.
Gary LaFever 38:18
Very well said. Steffen, anything you want to add before we go to the last one?
Steffen Weiss 38:21
If you talk about benefits of Statutory Pseudonymisation under the GDPR, you should not forget about the member state laws. I mean, just to give you an example of Germany, we do have some provision in the resource sector allowing the processing of personal data in case you have appropriate safeguards in place, and this is where yet again civilization comes into play. In case you have Pseudonymisation properly implemented according to the GDPR, you can use that member state law provision to process personal data. So, please do not just talk about GDPR. Do not forget member state laws, which can be taken into account if you really want to get a holistic view on Pseudonymisation.
Gary LaFever 39:01
And that raises the additional point which is that Statutory Pseudonymisation continues to gain momentum around the globe. There will be specific country and specific state laws that actually could give you the benefit as well, and that's really why we're here talking about this because the heightened requirements for Statutory Pseudonymisation are well worth the effort because of the benefits, the benefits both under the GDPR, other member state laws, laws of other jurisdictions, and other requirements of vertical industries as well.
Steffen Weiss 39:32
The last benefit we can talk about is about reduced notification obligations and liability. So, you are aware, of course, of data breaches under the GDPR. So, in case you have a breach of security, meaning a breach of confidentiality or integrity or availability of personal data, you might be obliged to notify this breach to the supervisory authority in case there is a risk to the data subject and this is yet again where Pseudonymisation is quite handy. So, in case you have properly implemented Pseudonymisation, you might be exempted from notifying a personal data breach for that pseudonymised data, so just real benefit in case you use Pseudonymisation on personal data. And again, liability is also an issue for many, many organisations and companies.
So, in case you have a breach of security under Article 32, you might be subject to compensation by the data subject. So, what to do? You can use Pseudonymisation to really implement a technical safeguard on the data. So, in case, for breach of security, for example confidentiality, you might be less concerned in case you lose access to pseudonymised data or someone else is getting access to pseudonymised data. But as a reminder, you have to do it properly. If you haven’t done it properly pseudonymising personal data, this access to personal data can be really a risk for the companies and organisations because, as I have mentioned before, you might be obliged to notify and you also might be obliged to compensate the data subject in case the third party has access to the data, which the third party is not allowed to have access to.
Gary LaFever 41:15
Ironically, in one of the rare instances of which I am aware where the US has more stringent requirements even under the EU, in California for every breach that occurs, there are statutory damages, so you don't even have to prove them. Statutory damages of $750 per consumer per incident. And so, if you think of situations and there are many where you have millions of records, every breach could be $750 of statutory damages per consumer per incident. And so, it's not just the GDPR. Both with respect to greater data use and innovation that is enabled by Statutory Pseudonymisation, as well as limitations of liability, reductions of liability, and perhaps even elimination of disclosure obligations. If you can show that it was done properly, Pseudonymisation is something to be considered.
Gary LaFever 42:14
We want to thank everyone for joining us for this third episode of the Pseudonymisation Podcast, and I very much want to thank our special guests, Maggie and Steffen, and we hope you all heard and realise that Pseudonymisation is probably not what you thought, but it's going to be a lot more going forward in the future than it has been in the past because of the balancing between data use and data protection in a way that gives you greater value, statutorily granted expansive rates, reduced liability in such a way that as it travels around the globe as it were not only does it enable lawful international transfers under Schrems II, but it could enable greater data sharing and combining hopefully leading to new innovations, even scientific and medical breakthroughs. So, thank you for joining us today. Have a good day.
Key Takeaways
When discussing the benefits of statutory pseudonymisation, you need to look beyond the GDPR and consider the benefits under EU member state laws. For example, Germany has provisions allowing personal data processing when appropriate safeguards are in place. This is where statutory pseudonymisation comes into play. If you have implemented pseudonymisation properly, according to heightened GDPR, you can use member state law provisions to process personal data. So please do not just talk about GDPR. Do not forget member state laws, which should be considered for a holistic view of pseudonymisation.
Steffen weiss
the German Association for Data Protection and Data Security (GDD)
the German Association for Data Protection and Data Security (GDD)
- I see definite momentum around the globe in realising the heightened requirements for, and the increased data innovation benefits from, statutory pseudonymisation. We must be careful about the terminology we use. Pseudonymisation is not an effort to get outside of the law via “anonymisation,” which is frowned upon by supervisory authorities. Statutory pseudonymisation, as defined under the GDPR – and increasingly under other jurisdictions’ statutes – enables you to work within the law to improve and facilitate data utility whilst simultaneously balancing that increased utility against the protection of the data subjects and their rights, which involves more than data protection.
Magali Feys
ACONTRARIO
ACONTRARIO
The 10 truths of statutory pseudonymisation “tick and tie” to supervisory authority recommendations and court rulings, providing confidence in the predictability of operations and secure data processing in global supply chains. This includes trans-Atlantic data transfers, US-operated cloud processing, data sharing, and distribution.
Gary LaFever
Anonos
Anonos
Schrems II Knowledge Hub
RESOURCES TO ACHIEVE LAWFUL BORDERLESS DATA:
Top 8 Misconceptions
A number of serious misconceptions about the impact of Schrems II still remain, which makes it hard for organisations to comply.
This PDF download contains an explanation of the Top 8 Misconceptions surrounding Schrems II so that your organisation can eliminate misunderstandings to move forward. Downloadable and web versions are available.
READ MOREThis PDF download contains an explanation of the Top 8 Misconceptions surrounding Schrems II so that your organisation can eliminate misunderstandings to move forward. Downloadable and web versions are available.
Schrems II Legal Solutions Guidebook
The Schrems II Legal Solutions Guidebook is a critical asset for legal and privacy advisors working on GDPR and Schrems II compliance issues.
The Guidebook, which has been downloaded over 2,200 times, covers the key legal aspects and benefits of SCC-based Schrems II compliance, as well as a checklist, templates, and practical steps for organisations to follow.
DownloadThe Guidebook, which has been downloaded over 2,200 times, covers the key legal aspects and benefits of SCC-based Schrems II compliance, as well as a checklist, templates, and practical steps for organisations to follow.
Implementation Workshop
Schrems II workshop covering Implementation Roadmap & Legal Benefits, for organisations to understand how to implement Schrems II Supplementary Measures for SCCs. Over 2000 GCs, CPOs, DPOs, and Outside Legal Counsel participated from over 1700 companies across over 50 countries. To ensure you don't miss out on valuable information, a replay of this workshop is available for you.
Watch ReplayLinkedIn Group
This LinkedIn group focuses on GDPR Pseudonymisation as highlighted by the EDPS and the EDPB as the most promising supplemental measure for Schrems II compliance. Also, visit www.pseudonymisation.com for more information on Pseudonymisation.
JOIN GROUPAnonos Solution Page
Anonos offers a technology solution that provides technical Supplementary Measures for Schrems II compliance. Explore Anonos GDPR-Pseudonymisation technology, so that you can support your organisation or clients towards a compliant solution. Only Anonos delivers three critical requirements for achieving a Defensible Business Position: Schrems II compliant Supplementary Measures and GDPR-compliant Pseudonymisation to future-proof Standard Contractual Clauses (SCCs).
VIEW SOLUTIONIDC Report on Schrems II
This IDC report explains how Anonos’ BigPrivacy software is well placed to satisfy the Schrems II requirements for appropriate safeguards by creating pseudonymised versions of personal data (Variant Twins).
The IDC report covers the development of Anonos BigPrivacy, use cases, an explanation of Anonos' state-of-the-art Pseudonymisation technology, and market applicability of the solution. Read this IDC report to find out how Anonos technology can help you.
READ REPORT The IDC report covers the development of Anonos BigPrivacy, use cases, an explanation of Anonos' state-of-the-art Pseudonymisation technology, and market applicability of the solution. Read this IDC report to find out how Anonos technology can help you.
Pseudonymisation Blog
A timely collection of articles and perspectives that you will not find elsewhere. This content reflects topical issues gleaned from meetings and interactions with companies, regulators, legislators, and non-governmental organisations related to SCC-based compliance with Schrems II requirements.
READ BLOGPseudonymisation.com Resource Page
Pseudonymisation is at the core of the Data Embassy principles, and is newly-redefined in the GDPR. Find out more about the importance of Pseudonymisation, as recommended by the EDPB as a Schrems II solution for protecting data in use, and how its application can help your organisation.
READ MOREExecutive & Board Risk Assessment Framework
This framework covers the crucial issues we address when working with these organisations to evaluate the ability to establish an immediately defensible position in compliance with Schrems II.
READ MORE
New Technology Controls Required
Relying on “Words Alone” by updating contracts and hoping for treaties produces unsustainable operations because no contract or treaty will remove the need for new technology controls to protect data when in use.
This Briefing covers how Anonos technology solves international cross-border legal challenges, enabling the highest data protection levels, accuracy, and utility on a global scale by complying with recommendations by the EDPB for GDPR-compliant Pseudonymisation.
READ MOREThis Briefing covers how Anonos technology solves international cross-border legal challenges, enabling the highest data protection levels, accuracy, and utility on a global scale by complying with recommendations by the EDPB for GDPR-compliant Pseudonymisation.
Webinar: Presenting Risk Exposure to the C-Suite & Board
Schrems II risk mitigation strategies for Boards of Directors and C-Suite, and organisations are critically needed. View this webinar to find out what the risks are, and what steps you need to take next to brief your executive team and board members.
Watch ReplayWebinar: Technical Supplementary Measures
Webinar Replay: Watch the replay of the webinar in which 3,200+ from 2,300+ companies across 50 countries participated. Schrems II Webinar: Technical Supplementary Measures Surviving and Thriving Under Schrems II.
Watch ReplayWebinar: Learn how Pseudonymisation can solve Schrems II challenges
Learn how GDPR Pseudonymisation can help your organisation achieve compliance while reaching business goals and objectives.
WATCH REPLAY
Memorandum to EDPB
Read Pseudonymisation memo submitted to the EDPB in connection with public consultation 05/2021
READ
© 2024 Anonos. All rights reserved. Privacy Policy
Follow us on: 
