Pseudonymisation: do it yourself or outsource it?

Pseudonymisation: do it yourself or outsource it? - Viacryp

By now, everyone’s aware of it: the General Data Protection Regulation (GDPR) took effect on 25 May 2018. In my work as a privacy consultant, I’m seeing many organisations struggling to take the right measures. Besides that, one of their major challenges appears to be this: how do you ensure that everyone in the organisation adheres to the measures and—above all—continues to do so? The vast majority of employees have enough on their hands just staying on top of their own tasks and processes. As a result, there isn’t enough time and attention left for taking every privacy rule into account.

Protect your employees against themselves

You can’t expect your employees to take privacy considerations into account appropriately each and every day. That’s why I see it as the organisation’s responsibility to protect them as much as possible, in order to prevent things from going wrong. The most obvious solution is to make it crystal clear to everyone that data containing personal information cannot be used for certain purposes. What you also see is that organisations are encrypting certain data by pseudonymising personal data themselves, for example by using data-masking software.
And every seasoned privacy specialist knows… this is where the shoe starts to pinch. Over time, there will always be someone who has a particular query or needs to solve a particular problem, someone who says: ‘Hey, I’m not getting these data linked, but I know there’s still a table somewhere that contains the information I need for this.’ And then, often a long time later, you discover that the data turns out to be linked anyway.

If data can be used, it will be used

My argument is this: if data can be used, it will be used. Of course, employees do not do so with the intention of breaking the law, but you can’t expect them to question whether they are complying with every privacy provision and relevant law for every data-related action they take. Unfortunately, privacy compliance cannot be achieved solely by means of security, rights and access control. According to privacy legislation, what you intend to do with personal data in particular is what determines whether you may combine and use it. If you want to prevent the unauthorised use of the data within your own infrastructure, you have to set up numerous management and control processes. It’s not cheap and it’s quite complicated. And still: when things will go wrong you never know, but that they will go wrong is almost inevitable.

But my pseudonymised data is safe, isn’t it?

Actually, it’s not. Even when you’ve pseudonymised your data, if it has been done within your own organisation, you first have to deal with the challenge that that entire process is taking place within one infrastructure. This means you always run the risk that any and all information, such as encryption keys or translation tables, can be viewed by someone. With this information, it’s possible to reverse the process or trace the pseudonyms by once again pseudonymising known identities. There’s a good reason why the GDPR states that ‘additional data should be kept separate’ and ‘technical and organisational measures be taken.’

Why pseudonymisation is more than just a tool or technical trick

So what are the concrete technical and organisational measures that the law requires be taken in order to properly implement pseudonymisation? First of all, you have to make sure the pseudonymisation process is protected. The process involves an incoming stream with readable personal data, a pseudonymisation process, and then an outgoing stream with pseudonymised data. Organisationally, you must adhere to a four-eyes principle. This means that no single employee may be authorised for more than one of these steps. This leads to the functional and technical segregation of duties, and you also have to take this into account when setting up backups, for example. In order to be able to demonstrate that the work is carried out properly, ISO and/or security measure controls must be defined. These controls have to be checked, validated and recorded; a robust information security process therefore surrounds this entire process.
And then you have to consider data leaks which can occur as a result of unauthorised access to the network. To be able to demonstrate that the encryption keys have not been stolen in such a case, serious infrastructural safeguards are required. If they’re not in place, you have to assume that the encryption keys have also been leaked. In moments like this, it becomes painfully clear that although, technically-speaking, pseudonyms have been created, the net result is that pseudonymisation has not provided any additional protection.

Who says a Trusted Third Party (TTP) can do it better?

Whether a TTP performs its work better than if you, as an organisation, were to pseudonymise your data yourself, is open to discussion. What is clear is that the primary focus of TTP employees is to implement and monitor technical and organisational measures. And that’s exactly what the primary task is not for employees of other organisations. By using a TTP, you’ve automatically arranged the required separation of functions and authorisations, and the demonstrability of this becomes a minor matter. Moreover, the use of a TTP lends credibility because it shows the individuals whose data it concerns that you’re serious about protecting their privacy.

Right, but a TTP can be hacked, too?

Absolutely! But should that happen, you only lose a list of pseudonyms, not the data related to them. A good TTP doesn’t retain the data in question, but only the link between the encryption keys and the pseudonyms. What’s more, a good TTP ensures that no readable data runs through the TTP at all, as this is not at all necessary in such a role. In the event of a hack, the translation (which identity has become which pseudonym) will indeed be leaked, but not the information about the behaviour or the activities of the individual. In that case, the breach is ‘unlikely to result in a risk to the rights and freedoms of natural persons.’

Conclusion

I hope the above has made it clear that if you view pseudonymisation solely as a technical solution, you won’t be complying sufficiently with your legal obligations. In addition, organisations and employees have an unfair sense of protection when pseudonymisation is not properly carried out, and they become less critical of the use and distribution of this data. This means that the end result is exactly the opposite of what you wanted to achieve and that the protection of privacy has not improved, but rather declined.

The definition ‘pseudonymisation’ in the GDPR: the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures to ensure that the personal data are not attributed to an identified or identifiable natural person.

Read also:

Edwin Kusters

About us - Edwin Kusters | Viacryp

In his role as a data and privacy consultant, Edwin has mainly been involved in large BI projects for the past eighteen years. He increasingly noticed that clients had certain customer analysis requirements which were in conflict with the Dutch Data Protection Act (a forerunner to the GDPR). As a result, he went in search of a solution that would still make carrying out such analyses possible. The entire playing field of the definition of the law was the starting point, but he also had to take into account such customer priorities as time-to-market, quality of service and compliance costs. The creation of a specific, separate company, today known as ViaCryp, proved to be the most effective solution for clients when it comes to navigating this complex world. Edwin regularly speaks on privacy matters at seminars and congresses, and is a member of the NEN working group for the development of a pseudonymisation standard.