The debates on the General Data Protection Regulation (GDPR) and encryption are not over yet. Although encryption only gets a few lines in the GDPR, is recommended and offers benefits in particular cases (if you follow the text that is) there is also the reality of GDPR compliance and encryption in a broader perspective and context that most don’t know.
Encryption is a broadly used process whereby data gets turned into an encoded and unintelligible version, using encryption algorithms and an encryption key, and whereby a decryption key (which in some forms of encryption is the same as the encryption key) or code enables others to decode it again.
Encryption is a form of cryptography and comes in many shapes and types, with various solutions and applications, including plenty of Internet and data transmissions and operations we often don’t “see” or know about. Encryption and cryptography are also key in the transaction update data model of blockchain.
There is obviously far more to say about it but in the scope of this article where we look at encryption under the GDPR, for now let’s say that data encryption is an increasingly used data protection method. Why ‘for now’? Because, as we’ll see, the context and scope in which specific forms of encryption and other security measures are used will have an impact on how personal data breaches and individual cases of clear non-compliance will be looked upon, even if the GDPR and related texts don’t expand upon that. But there is a lot to learn from the past. Yet, that’s for later.
Data encryption is also, and certainly, increasingly important with regards to personal data of course and so it is in ‘more recent technologies’ (and in using more recent technologies) as well. An example of a more or less ‘somewhat newer’ technology where data encryption is increasingly used is cloud computing. According to a January 2018 report by Gemalto and Ponemon Institute, encryption is increasingly deemed important in a context of cloud data security and cloud data protection, for instance.
In the GDPR encryption is explicitly mentioned as one of the security and personal data protection measures in a few Articles. Although under the GDPR encryption is not mandatory, it is certainly important to see where and why encryption is advised. And it’s certainly important to also look a bit further than the text.
[toc]GDPR encryption: the what you should know part
Before doing so let’s be clear: GDPR compliance, as we wrote before is a business strategy challenge and encrypting personal data STRICTLY SPEAKING is not mandatory.
Encryption is important, valuable and in many modern information and data systems present. The GDPR, however, says what it says and it certainly doesn’t say anything about compliance and encryption, let alone about what level and standard of encryption, where to use encryption, for which types of personal data (as in data at rest, data in use and data in transit or as in personal data overall or sensitive data), for which types of personal data processing and so on. Yet, in previous data protection laws and, especially in jurisprudence, the presence of encryption has been used as an argument in specific types of breaches and specific types of encryption and, as far as we’re concerned we see no reason why data protection authorities would not do so in the future as well, on the contrary: if encryption is mentioned, even as ‘an example’ in most cases, it is for a reason, not for fun.
There are also no guidelines from the WP29 (European Data Protection Board) on how to see encryption in the scope of the GDPR, which really is a pity given existing confusions. However, there are some guidelines mentioning encryption you must know about.
In other words: although the GDPR obviously requires that organizations take the appropriate technical and organizational measures regarding the protection and security of personal data, whereby pseudonymization and encryption of personal data are recommended, the GDPR strictly speaking does not say you must use encryption as some claim since the GDPR says what it says and only jurisprudence and instances such as supervisory authorities and the proper EU authorities have the power of interpreting and/or ammending it (and common sense dictates that in specific circumstances encryption is important when considering context and risks). National supervisory authorities can also follow guidelines on implementation and take some decisions to tell you, or at the very least, recommend you what to do. In case of personal data breaches it’s more tell you than recommend you, an important GDPR encryption aspect that comes back later.
Companies that say GDPR encryption is a must, for example stating you can’t afford not to use it because the GDPR comes with high administrative fines, stating those high maximum fines, however, are selling encryption solutions in a misleading way as they do not know how fines in individual cases will be decided, maximum fines before the GDPR have been seldom applied and more.
HOWEVER, despite the fact that the GDPR does not strictly require you to use encryption, only mentions encryption a few times and never made it mandatory, de facto using encryption isn’t just a good idea, in case of a personal data breach and the personal data breach notification duty and other obligations the encryption question typically will pop up and there are some national supervisory authorities (a.k.a. Data Protection Authorities or DPAs) that recommended data controllers in the past (particularly the ICO in the context of the previous laws) to have a policy in place for staff on when to use and when not to use encryption (and it can’t always be used or can be ‘disproportionate’ to use the GDPR language to do so). Then again: the fact that, as we’ll see, encryption is mentioned in the scope of a data breach notification duty, some do overemphasize the importance of that as we’ll also see.
Secondly, it should be taken into account that the GDPR does not and will not stand on its own.
By now everyone should now that there are other rules coming, in line with the GDPR, of which the ePrivacy Regulation no doubt will be the most impactful and already is a topic of emotional discussions and high concern for many and has been approved by the European Parliament (which doesn’t mean it’s finished). And that complement to the GDPR, as you could see it, does mention encryption too as we’ll, indeed, also see.
Thirdly, while the GDPR is clear on encryption, the guidelines for the implementation and enforcement of the GDPR aren’t always that clear when you dive deeper, the position of supervisory authorities can be different per country and the impact of the ePrivacy Regulation and how it will be in correlation with the GDPR have caused us a serious headache.
Yet, we’ve added relevant texts and notes about them at the bottom so you can see for yourself that 1) it’s confusing and 2) it might be a good idea to look beyond the GDPR text alone.
If you ask us if encryption is a must under the GDPR we say no as the texts are clear (we’ll look at them right after this). If you ask us if encryption under the GDPR is abused by some companies selling solutions we say yes. If you ask us if encryption will turn out to be important in the scope of the further evolutions of data protection regulations in the EU and the application of the GDPR, as well as decisions with regards to breaches and non-compliance in various SPECIFIC circumstances it’s a definite yes and we see little reason not to follow the mentioned advice.
What the GDPR says about encryption: from appropriate safeguards and change of purpose to the data subject notification duty in case of a breach
But, please do check out those texts we mention at the bottom of this overview. Yet, first: what does the GDPR itself say about encryption (freely translated)?
We start with the GDPR Recitals. GDPR Recital 83: controllers and processor should make an evaluation of the risks of their various data processing activities (by the way; in case of serious doubts there is always the possibility of a DPIA) and implement measures to mitigate those risks, SUCH as encryption in order to:
- maintain security and
- prevent processing that isn’t compliant with the GDPR.
Moreover, that evaluation should balance the level of risk, the types of personal data involved and the cost to implement such measures. This, in practice will prove to be essential. And, finally, when you assess those security risks, especially take into account risks whereby you and the data subject get in trouble (read: breaches).
Next the GDPR Articles. GDPR Article 6: in the scope of lawful processing and, more specifically, in the PARTICULAR case where:
- processing happens for other purposes than those at the time of collection of the personal data and
- is not happening based on the consent of the data subject and some other specific bases,
then the data controller must ascertain whether the new purpose is compatible with the original one, AMONG OTHERS, taking into account the existence of appropriate safeguards, which MAY include encryption or pseudonymization.
GDPR Article 32: essentially summing up what’s in GDPR Recital 83, Article 32 says to take those APPROPRIATE technical and organizational measures with the APPROPRIATE balance of measure and risk, costs of implementation, nature and context and purpose of the processing and more in mind, whereby, among others AS APPROPRIATE, pseudonimyzation and encryption of personal data could be APPROPRIATE. However, do keep in mind those big risks too. We keep capitalizing the word APPROPRIATE as you can bet that it will play in some cases, that’s our prediction and bet. Context does matter and Lady Justice has a balance for a reason.
GDPR Article 34: in the scope of the personal data breach notification duty of the controller to the data subject, that communication is not needed if, among other conditions, you, as a controller did implement APPROPRIATE measures, these measures were applied to the affected data and in particular in the context of what we cover here, those measures resulted in the fact that the personal data are unintelligible to anyone who isn’t authorized to access them, whereby encryption is an example of such a measure.
So, yes, encryption MIGHT just set you free of the duty to inform people whose personal data were stolen or whatever. However, if there is a high likeliness that the personal data breach results in a high risk for the data subject (the GDPR thinks from the perspective of the data subject, his/her data subject rights and risks, always) and the supervisory authority who will anyway fine you sees that your encryption, if used, in potential combination with other measures, wasn’t really enough you need to do it anyway. Moreover, keeping in mind Lady Justice’s balance and the fact that appropriate measures are to be seen CASE BY CASE once more we emphasize the role of jurisprudence and importance to learn from the past.
Who decides? Not you. As an example of a case where it could be decided that your encryption measures as such weren’t good enough, just think back about that survey on cloud data security and protection: if found that, although, on average for now only 40% of data stored in the cloud is secured with encryption and key management solutions and they do make mistakes such as not centrally securing and storing their encryption keys, in some countries the percentage is much higher and they do far better. Moreover 91% of respondents said the ability to encrypt data will become more important in the next two years.
Great. Yet, you need to centrally secure and control those encryption keys or your encryption could be deemed not appropriate and sufficient.
That’s what the GDPR says about encryption.
GDPR encryption: reading the guidelines and checking the ePrivacy Regulation text
Now comes the funny part, such as the guidelines from the WP29 and that other, complementary, piece of legislation, the ePrivacy Regulation that probably will confuse you but also makes a case for encryption anyway. The choice is yours.
In an Opinion, going back to July 2016, the Article 29 Data Protection Working Party (European Data Protection Board), which provides opinions, guidelines and so forth that are not legally binding but serve as important recommendations and, for those who need to ensure the application of both the GDPR and the (coming) ePrivacy Regulation, as implementation and enforcement guidelines “invited the European Commission to consider protecting the rights of users to use encryption to protect their electronic communications. Such a rule might also include the development of technical standards on encryption, also in support of the revised security requirements in the GDPR”.
Let’s repeat that last part: revised security requirements.
Encryption and the ePrivacy Regulation
The text of the ePrivacy Regulation as it has been approved by the European Parliament in plenary session in October 2017, a.k.a. the Lauristin Report, has an amendment that says: “In order to safeguard the security and integrity of networks and services, the use of end-to-end encryption should be promoted and, where necessary, be mandatory in accordance with the principles of security and privacy by design. Member States should not impose any obligation on encryption providers, on providers of electronic communications services or on any other organisations (at any level of the supply chain) that would result in the weakening of the security of their networks and services, such as the creation or facilitation of “backdoors”.”
Other amendments and passages from that text pertaining to encryption in the scope of that ePrivacy Regulation text (which, again hasn’t gone through all stages yet):
- In the scope of electronic communications service providers: “Service providers who offer electronic communications services should process electronic communications data in such a way as to prevent unauthorised processing, including access, or alteration. They should ensure that such unauthorised access or alteration can be detected, and also ensure that electronic communications data are protected by using state-of the art software and cryptographic methods including encryption technologies. Service providers should also inform users of measures they can take to protect the security of their communications for instance by using specific types of software or encryption technologies.”
- In that same scope: “Providers of electronic communications services shall ensure that there is sufficient protection in place against unauthorised access or alterations to the electronic communications data, and that the confidentiality and integrity of the communication in transmission or stored are also guaranteed by technical measures according to the state of the art, such as cryptographic methods including end-to-end encryption of the electronic communications data. When encryption of electronic communications data is used, decryption by anybody else than the user shall be prohibited. Notwithstanding Articles 11a and 11b of this Regulation, member States shall not impose any obligations on electronic communications service providers or software manufacturers that would result in the weakening of the confidentiality and integrity of their networks and services or the terminal equipment, including the encryption methods used”.
- In the scope of services that are provided to users engaged in purely personal or household activities (e.g. text to voice service, mailbox organization or SPAM filter service): “Where communications data are stored by a third party, this third party should ensure that any information whose processing is not necessary to provide the service requested by the end-user is protected with state of the art security measures applied from end to end, including cryptographic methods such as encryption.”
GDPR encryption in the WP29 guidelines on breach notification and on administrative fines
Next, in its latest guidelines on the personal data breach notification duty under the GDPR, the WP29 writes:
“In its Opinion 03/2014 on breach notification, WP29 explained that a confidentiality breach of personal data that were encrypted with a state of the art algorithm is still a personal data breach, and has to be notified. However, if the confidentiality of the key is intact – i.e., the key was not compromised in any security breach, and was generated so that it cannot be ascertained by available technical means by any person who is not authorised to access it – then the data are in principle unintelligible. Thus, the breach is unlikely to adversely affect individuals and therefore would not require communication to those individuals. However, even where data is encrypted, a loss or alteration can have negative consequences for data subjects where the controller has no adequate backups. In that instance communication to data subjects would be required, even if the data itself was subject to adequate encryption measures. WP29 also explained this would similarly be the case if personal data, such as passwords, were securely hashed and salted, the hashed value was calculated with a state of the art cryptographic keyed hash function, the key used to hash the data was not compromised in any breach, and the key used to hash the data has been generated in a way that it cannot be ascertained by available technological means by any person who is not authorised to access it”.
“Consequently, if personal data have been made essentially unintelligible to unauthorised parties and where the data are a copy or a backup exists, a confidentiality breach involving properly encrypted personal data may not need to be notified to the supervisory authority. This is because such a breach is unlikely to pose a risk to individuals’ rights and freedoms. This of course means that the individual would not need to be informed either as there is likely no high risk. However, it should be borne in mind that while notification may initially not be required if there is no likely risk to the rights and freedoms of individuals, this may change over time and the risk would have to be re-evaluated. For example, if the key is subsequently found to be compromised, or a vulnerability in the encryption software is exposed, then notification may still be required.”
Have you read it? Let’s summarize what we think matters here most: the keys are key and if you, as a controller have picked the wrong software you need to communicate anyway. Oh, and it doesn’t matter when they key turns out to be compromised or there seems to have been a vulnerability in the software.
The thing is: just as data breaches happen a lot and attempts keep increasing and when it boils down to security sometimes the question is rather a when, vulnerabilities in software are, well, pretty ubiquitous too. That’s why patches exist.
Oh, and it’s not done yet. Another piece: “Furthermore, it should be noted that if there is a breach where there are no backups of the encrypted personal data then there will have been an availability breach, which could pose risks to individuals and therefore may require notification. Similarly, where a breach occurs involving the loss of encrypted data, even if a backup of the personal data exists this may still be a reportable breach, depending on the length of time taken to restore the data from that backup and the effect that lack of availability has on individuals.”
There is more in those guidelines which you can check out here (PDF downloads).
It should be noted that, although not binding, the guidelines of the WP29 matter and that there are more WP29 guidelines where details on encryption within the context of the GDPR Articles where it matters are provided.
You might especially be interested in GDPR encryption and GDPR guidelines on administrative fines which we tackled earlier where, with regards to the assessment criteria of GDPR Article 83 which, quote, “supervisory authorities are expected to use in the assessment both of whether a fine should be imposed and of the amount of the fine” the guidelines explicitly state that within the scope of the categories of the personal data affected by the infringement as being one of those assessment criteria the WP29 provides some examples of “key questions that the supervisory authority may find necessary to answer, if appropriate to the case”.
One of these EXAMPLES of questions that supervisory authorities MIGHT ask in that PARTICULAR context includes the question “Is the data directly available without technical protections, or is it encrypted?” with a footnote stating that “It shouldn’t always be considered ‘a bonus’ mitigating factor that the breach only concerns indirectly identifiable or even pseudonymous/encrypted data. For those breaches, an overall assessment of the other criteria might give a moderate or strong indication that a fine should be imposed”.
Last but not least: it is possible, although we haven’t checked if there are any to make sure, that in the scope of codes of conduct, binding corporate rules and the various mechanisms in the GDPR to demonstrate compliance, have sector agreements, transfer personal data and whatnot there could be stipulations regarding the usage of encryption. Check to make sure.
That’s it. And there certainly is or will be more.
Top image: Shutterstock – Copyright: jijomathaidesigners – All other images are the property of their respective mentioned owners. Although the content of this article is thoroughly checked we are not liable for potential mistakes and advice you to seek assistance in preparing for EU GDPR compliance.
