#2.1 Preliminary Remarks
The GDPR provisions refer to only two technical means of personal data protection: encryption and pseudonymisation. It does not necessarily mean that organisations are always forced to encrypt personal data or employ more sophisticated pseudonymisation technics. However, organisations should be able to explain in particular why they are not encrypting or pseudonymising personal data they process (e.g., due to specific risks to availability or integrity of data).
#2.2 Encryption
The GDPR does not define encryption. The word makes us think of powerful encryption algorithms, that is cryptographic algorithms. By powerful algorithms we mean those that at a given moment are considered safe (e.g., due to key length or the strength of the algorithm itself). An encryption algorithm is nothing other than a mathematical function that deforms one item of information (which is public, in what is called open form) into another (non-public, encrypted, in what is called closed form). The reverse process, decryption, requires knowledge of specific, confidential (secret) data – this can be a password, a special key, or biometric data such as a fingerprint, the arrangement of veins in the hand, or the retina of the eye. The purpose of encryption is to protect information from being accessed by unauthorised third persons. It can have the added benefit of control over data quality since damaged encrypted data cannot be properly decrypted. Encryption can also be applied to data in transit, that is when the data are being sent, e.g. over the internet (or in a backpack in which we have a laptop, or a pen drive in an envelope sent by courier, or even in a smartphone), or when they are in what is known as state of rest, that is when they are recorded in files or a database. It does not matter where such a file is located – be it on our computer or somewhere in the cloud. Yet, so far there is no practical method of encrypting data while they are being processed by a computer in a RAM memory (since the file must be open).
The GDPR refers to encryption four times – once in the recitals and three times in the provisions. This explains the ‘popularity’ of encryption, which is often presented as a panaceum for all problems concerning GDPR compliance. But it does not work that way. Encrypting everything everywhere in no way releases an organisation from the obligation to implement other security mechanisms. The basic requirements for GDPR security compliance are set out in Article 32 GDPR. The regulation also applies risk analysis and the principle of adequacy. Further, badly implemented encryption will not necessarily raise the level of security, and an organisation may continue to be exposed to penalties for lack of compliance with the GDPR if there is a breach of personal data security. Encryption increasing confidentiality decreases the availability of data. Associated risks may have technical nature – an accidental corruption of makes them impossible to decrypt (hence not accessible) or organisational nature – leaving users alone with passwords policy puzzle will result in the same – sooner or later inaccessibility of data. Nevertheless, since the GDPR refers directly to encryption, you cannot overlook encryption when assessing the adequacy of the personal data protection measures you have in place.
Risks associated with encryption are manifested well by an add of one of the tech giants promoting their encryption solution. What the add says is encryption can serve as a permanent data deletion measure – simply destroy (or loose) a data decryption key. Consequences are easy to imagine. We do not even need to imagine consequences of a partisan user encryption – probably every reader of this book received once via email an encrypted archive (ZIP, RAR, etc.). Who of us was able to decrypt it again after a certain period of time?
Encryption brings different organisational or technical problems. Let us look at email, while encryption of email in transit becomes standard (Transport Layer Security), as well as encrypting data at rest (e.g., BitLocker native to Windows10) end-to-end or point-to-point encryption (S/MIME, PGP, GnuPG, etc.) is an organisational problem, portal encryption (secure webmail systems) is a UX (user experience) and durable medium problem, and user hand encryption is an organisational nightmare.
#2.3 Pseudonymisation
Pseudonymisation is a process of transforming data such that the data subject cannot be identified by anyone except for those who possess the key (a simplest example of a ‘key’ is a list of names corresponding to unique identifying numbers).
According to Article 4(5) GDPR, pseudonymisation means:
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.
To simplify, pseudonymisation means replacing a given person’s identifiers (such as first and last name, identity number, telephone number, email address) with pseudonyms – unique (unrepeatable) codes, figures, or images (within this scope there is some freedom) that have no real connection with that person. In this way, data that would give away the identity of specific people are changed into meaningless data (pseudonyms, usually numbers, that connect the hidden personal identities with descriptions of those people’s traits).
Pseudonymisation is a reversible process, which means that the body carrying out the pseudonymisation can, in response to certain actions, ascertain that certain data concern, for example, John Smith. The reversibility of the process is crucial and distinguishes pseudonymisation from anonymisation.
The GDPR refers to pseudonymisation as many as fifteen times, including nine times in the recitals and six times in the provisions.
#2.4 Anonymisation
Anonymisation is an irreversible process. Once data have been anonymised they can no longer be used to identify the person they concern. Anonymisation is used in order to prevent the identification of people whose data have been anonymised, and so it is not used when knowledge of identity is required.
The GDPR refers to anonymisation in Recital 26. Anonymisation is considered a method of deleting data. Anonymising records is a technically preferred way of deleting personal data, especially over deleting records, due to a risk of destroying the integrity of databases. Simply said, in case we delete a record (another words a row in a table) the database (a spreadsheet) may collapse and cells may no longer remain in their proper rows (records) making the whole database more or less useless. How at all would it be possible in a modern IT world? Simply it would be possible, and it happens every now and then, as IT is an erroneous technology by its nature. On a practical and technical level, anonymisation may be more or less immune to reidentification. Proper anonymisation should be truly irreversible. However, poorly designed anonymisation may even retain directly identifying fields (cells). Therefore, it is important for a person responsible for data protection in a particular organisation what is understood by ‘anonymisation’ by persons responsible for specific IT systems or analogue data carriers (mostly – paper).
Anyway, anonymisation does not serve to protect personal data but to destroy personal data. Therefore we do not dig into it further.
#2.5 Pseudonymisation or Encryption
A simple comparison of the number of occurrences of the words ‘encryption’ and ‘pseudonymisation’ in the GDPR leads to the conclusion that pseudonymisation is the favourite security technique of the authors of the regulation. In truth, pseudonymisation lends itself well in principle to minimisation, because it can be used to limit the amount of information on natural persons ‘processed’ by an organisation for business and other purposes and is therefore also suitable for limiting authorised access (graded access). Whereas encryption is ‘only’ a means of protecting against unauthorised access (on the principle of ‘all or nothing’).
In reality, both techniques usually serve different purposes. Encryption is more a technical measure of data security, simpler to implement. Pseudonymisation is more a means of minimising data processing (scope of data access) so more a means of privacy by default. While user-level implementation of encryption is not easy, implementing pseudonymisation is even more complicated. Though, we are not saying it is impossible, as, for example, in clinical trials ‘double-blind trials’ mechanism is a standard.
#2.5.1 Security
The GDPR rightly recognises that encryption (Recital 83 GDPR) and pseudonymisation (Recital 28 GDPR) are means of minimising the risk of a breach of the rights and freedoms of data subjects.
Pursuant to Article 32(1)(a) GDPR, the following must be implemented:
appropriate technical and organisational measures to ensure a level of security appropriate to the risk [of a breach of the rights and freedoms of natural persons], including inter alia as appropriate … the pseudonymisation and encryption of personal data.
Since the first two examples of data protection measures specified in the GDPR are pseudonymisation and encryption, when actually evaluating the adequacy of and selecting data protection measures, one must not neglect to consider the usefulness of these two methods for a particular data processing operation or activity. This does not necessarily mean that you have to use either of them, but (in accordance with the principle of accountability) you should at least be able to explain why you are not using them.
#2.5.2 Risk Analysis
What specific data security measures are actually used should result from a prior analysis of the risk the data processing poses to the rights and freedoms of the data subjects.
Recital 76 GDPR states:
The likelihood and severity of the risk to the rights and freedoms of the data subject should be determined by reference to the nature, scope, context and purposes of the processing. Risk should be evaluated on the basis of an objective assessment, by which it is established whether data processing operations involve a risk or a high risk.
An indication of how to decide what data protection measures to employ is provided by Recital 83 GDPR, which states:
In order to maintain security and to prevent processing in infringement of this Regulation, the controller or processor should evaluate the risks inherent in the processing and implement measures to mitigate those risks, such as encryption.
Recital 83 also indicates a need to weigh the costs of implementing protective measures against the risk and the nature of the data involved:
Those measures should ensure an appropriate level of security, including confidentiality, taking into account the state of the art and the costs of implementation in relation to the risks and the nature of the personal data to be protected.
Finally, the recital states how risk should be evaluated:
In assessing data security risk, consideration should be given to the risks that are presented by personal data processing, such as the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data transmitted, stored or otherwise processed, which may lead in particular to physical, material or non-material damage.
Risks and threats are described broadly in Recital 75 GDPR, which primarily states when the type of risk is involved:
‘The risk to the rights and freedoms of natural persons, of varying likelihood and severity, may result from personal data processing which could lead to physical, material or non-material damage’, and then lists specific threats:
- ‘where the processing may give rise to [1] discrimination, [2] identity theft or fraud, [3] financial loss, [4] damage to the reputation, [5] loss of confidentiality of personal data protected by professional secrecy, [6] unauthorised reversal of pseudonymisation, or [7] any other significant economic or social disadvantage;
- where data subjects might be [8] deprived of their rights and freedoms or [9] prevented from exercising control over their personal data;
- where personal data are processed which [10 – special category data] reveal racial or ethnic origin, political opinions, religion or philosophical beliefs, trade union membership, and the processing of genetic data, data concerning health or data concerning sex life or criminal convictions and offences or related security measures;
- if [11] personal aspects are evaluated, particularly if analyses or forecasts are made of aspects concerning job performance, economic condition, health, personal preferences or interests, reliability, behaviour, location or travel – in order to create or use personal profiles; or
- where personal data [12] of vulnerable natural persons, in particular [13] of children, are processed;
- where processing involves [14] a large amount of personal data and affects a large number of data subjects’.
Without much hesitation, we can say that wherever a risk exists of serious harm being caused to an individual or a large group of people, specific personal data protection measures should be employed, including encryption or pseudonymisation. However, as mentioned above, at the same time organisations should bear in mind that both encryption and pseudonymisation affect the availability of data.
Mandatory encrypting of all electric bills by an energy company would bring havoc to its customers, especially if strong passwords were required.
#2.5.2.1 Data Protection Impact Assessment
Usually, a risk analysis is also needed to evaluate whether to conduct a more formalised risk analysis, known as a DPIA, as referred to in Article 35 GDPR. Article 35 states that a DPIA or PIA should be conducted where the risk associated with data processing is high. A DPIA is nothing other than a dedicated risk analysis of specific IT systems and data processing processes accompanied by additional verification of legality of processing and processing of data subject requests. Such an assessment should result in a list of threats to the IT system or a process. On that basis, appropriate security measures can be selected. Of course, it can happen that the cost, or technical or organisational limitations, do not permit one or more security measures to be implemented. In such a case, it may be possible to replace these measures with others, or with other control mechanisms. These would then be considered compensatory measures. However, such an approach is not always possible. It may turn out that the cost of implementation exceeds the cost of the loss entailed by the risk, or that the costs cannot be justified economically. This is why an impact assessment is so important. Where security is concerned, there is no upper-cost limit. It is easy then to end up in a situation where security costs are growing exponentially, data are still not safe, and GDPR compliance has not been achieved.
However, as already mentioned, we do not recommend relying directly on cost argumentation when deciding on appropriate technical and organisational measures of data protection.
#2.5.2.2 Method of Risk Analysis
When it comes to running a risk analysis, theoretically there is no need to think up your own method – you can use one of those publicly available, such as from ISO 27005. In the opinion of one of the co-author’s of this text, the ISO 27005 standard is ideal for both small and large organisations and is extraordinarily simple and concise. According to the other co-authors, who are attorneys, a standard that runs sixty-eight pages is not concise and cannot be simple. Therefore hopefully more ready to use methods emerge.
Because there is not always a high risk associated with personal data processing, not all processing systems and operations will require an impact assessment. Paradoxically, though, in order to find out where you stand, you have to first conduct a risk analysis.
Does this mean that in a system that does not generate a high risk of a breach of rights and freedoms you do not have to use pseudonymisation or encryption? Not necessarily. First, you should go by the principle that, when being transmitted through a public or third-party accessible network such as the internet, personal data should be encrypted. Second, if you grant anyone access to your personal data processing system, then, in accordance with the need-to-know principle, you may need to protect data and restrict access, e.g. through pseudonymisation. Pseudonymisation can also be an ideal solution if you process data for strictly statistical purposes, e.g. how many people in a given age bracket bought a certain product.
Remember, encryption and pseudonymisation have one common goal – to protect data from access by unauthorised third persons. Both processes are reversible, meaning that an authorised person should be able to recover the data (in the case of encryption) or identify the data subject (in the case of pseudonymisation). This property is extremely important and often misunderstood.
It is easier to discuss by way of example. Let us start with encryption: the personal data kept in the database are in encrypted form. If an unauthorised third person gains access to the database, they would not be able to retrieve them because they exist in closed form (encrypted). Only a decryption operation will render them open. This means that, in order to be processed, at some point, the data must be transformed from closed to open form. This makes the moment of transformation critical with respect to data protection.
In the case of pseudonymisation, however, we should imagine a system with two tiers: production and testing. Assuming that in the testing environment only test data, and not real data, are used, there is no problem if those data are accessed by an external entity providing system support services (e.g., by the producer of the system). But when there is a need to fix an error at the production level where real personal data are stored, outside people cannot be granted access without additional formalities. This issue can be resolved by creating a three-tier system that contains data subjected to pseudonymisation. Pseudonymised data do not disclose information on the data subjects, thereby permitting an entity providing support services to fix the error. Afterwards, the process of pseudonymisation is reversed and the solution transferred from the third tier to the production tier. For example, there could be a problem with a person having ID 179923. The external entity cannot ascribe that ID to a specific person, but, thanks to the reversibility of the process, the system owner knows that the person in question in John Smith and can make changes in the relevant record in the production tier. Most important here is that, in terms of the GDPR, a proper pseudonymisation process is one that can be reversed only by the party authorised to do so.
#2.6 Privacy by Design
Article 25(1) GDPR, which sets out the principle of data protection by design, refers to pseudonymisation. This is certainly because, up to now, pseudonymisation has been rarely used, even though it is a good method for implementing the basic principle of minimising data access. The authors of the GDPR recognised the value of including the use of pseudonymisation in new drafts that are to affect privacy in general.
#2.7 Notification of Breaches of Data Protection
Article 34 GDPR releases a controller from the obligation to notify a data subject about a breach of data protection if ‘the controller has implemented appropriate technical and organisational protection measures, and those measures were applied to the personal data affected by the personal data breach, in particular those that render the personal data unintelligible to any person who is not authorised to access it, such as encryption’. You should keep in mind just how troublesome it can be on various levels to inform data subjects that there has been a leak of their data. Securing data by encryption during transmission or transport offers protection against the awkward, burdensome, and often costly obligation to notify data subjects of a breach.
#2.8 Use of Business Pseudonymisation
Pseudonymisation is a good way to limit the impact of profiling on privacy. People are predictable, and with today’s access to information we are able to create very detailed profiles for predicting or analysing behaviour based on our knowledge of the behaviour of people who are tracked (on the net, in ATMs, in places where they pay by card, using geolocation based on Wi-Fi, by means of monitoring, facial recognition, licence number plates, etc.). For privacy, it would be an unthinkable disaster (for now) if every business (and especially sellers) had access to a specific individual’s full profile based on the work of a data analysis unit. How, then, can we avoid a situation where someone can establish on the basis of data that Smith is a drunk who beats his children? Profile building, whether for predictive or correlative purposes, should be undertaken without knowledge of the identity of particular persons – based on pseudonymised data. But that is not all. Profiles should certainly not be made available in their entirety to marketers. Rather, marketers should provide already-built marketing campaigns (where our Smith may find himself in an ad campaign for beer and separately in a campaign for books on self-help and anger management). Pseudonymisation relates somewhat to the problem of margin of error, that is improper profiling. Anyone who is not a terrorist or drug courier but has been chosen for an SSSS (secondary security screening selection) during a security check at the airport knows about this; so does anyone who has had their money frozen on their account under an anti-money laundering procedure even though the money was there legally.
Pseudonymisation is also used in ‘trivial’ cases, such as when data on remuneration are provided to trade unions or courts for the purpose of evaluating possible discrimination.
Double pseudonymisation (a double-blind sample) is standardly applied in clinical trials (where reversibility is obviously necessary, but for this two organisations must cooperate). Similarly, it is also applied in other studies where knowledge is required on various life circumstances of the people involved, but knowledge of their identity is not.
#2.9 Summary
A data risk analysis should be conducted regardless of whether the process/system concerned is covered by an impact assessment pursuant to Article 35 GDPR. Based on the results of the risk analysis or DPIA, a decision should be made on whether to apply encryption, pseudonymisation, or other data protection methods.
An evaluation should be made of the justifiability of pseudonymisation in procedures for initiating and running new projects, new investments, and organisational changes (privacy by design).
Encryption during data transmission or when data are transported on physical media is recommended.
We recommend you specify encryption and pseudonymisation when describing the organisational and technical data protection measures in the RDPA.