Everyone knows that the new GDPR legislation will enter into force on 25 May, so everybody is scrambling to find out what they need to do to comply with the new rules. We’ve been getting lots of questions on the subject, the commonest of which is definitely, “Does the GDPR require us to encrypt all our data?” We answer this question here, and at the same time expose five myths about GDPR and encryption.
1. Does the GDPR legislation require encryption?
A simple enough question, because we can look up the answer in the GDPR legislation itself. The word encryption occurs only four times in the 88 pages of the GDPR:
- 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. (page 16)
- the existence of appropriate safeguards, which may include encryption or pseudonymisation. (page 37)
- measures to ensure a level of security appropriate to the risk, including inter alia as appropriate: the pseudonymisation and encryption of personal data;
a) the pseudonymisation and encryption of personal data;
- making personal data incomprehensible to unauthorised persons, such as encryption (page 53)
The terms “such as”, “including” and “may include” clearly show that nowhere does the GDPR legislation require encryption, but only views it as an option. However, it does indicate that encryption is a good option, and therefore worth considering.
That is what GDPR legislation requires: you must think carefully about how you handle data. You have to assess every solution against its technical and economic feasibility.
Turn the situation around: imagine you suffer a data breach, and someone asks you, “Why didn’t you use encryption?” If you have an acceptable answer, you’ve done nothing wrong according to the legislation.
2. Does encryption mean I don’t have to report data breaches?
This question is slightly more complicated. It’s not mentioned literally anywhere in the legislation. What the regulation does state is that you have to inform the data subject, the person whose data is retained, if there is a real danger that his or her data has leaked, and there is a chance that the data can be traced back to him or her. If the data is encrypted or pseudonymised, this is not necessary.
Before you start getting too relaxed, remember that you are still obliged to report the breach to the Data Protection Authority (GBA, at the moment still the Privacy Commission). Another aspect you should consider is possible reputational damage if the data breach becomes public and it turns out that you haven’t reported it.
Encryption puts you in a stronger position: “Yes, there was a data breach, but the data is useless,” is the best thing you can say at such a moment.
3. What encryption techniques in the GDPR should I use?
Again, no recommendations in the GDPR legislation itself. Concepts such as encryption in rest, encryption in transit, Triple-DES, AES, etc are nowhere to be found. The GDPR only requires you to include security by design and privacy by default.
It’s not enough to dress your general project up with some security when it’s finished, you have to take security into account right from the drawing board. For us security experts, this is nothing new, as we’ve been advising clients for many years to incorporate various layers of protection. Imagine it as a castle: is a moat surrounding it enough, or do you also need strong walls, a portcullis, iron fencing and guards on duty 24/7?
It all depends on the data you work with. The fact that you provide as much protection as possible for sensitive data is obvious, but not quite as obvious for less sensitive data.
Bear in mind that the sensitivity of data can sometimes increase, not because of the nature of the data itself, but because of the amount of data you collect. Knowing that someone has been to an Iron Maiden concert is not sensitive data, but knowing all the concerts that person has been to makes profiling possible. The same data then suddenly becomes sensitive.
4 Is it sufficient to leave encryption to system administrators?
No it isn’t. As in question 3, we refer here to the security by design and privacy by default obligations. You have to consider the security of the data you process at all levels, and this is where DevOps can offer significant help. Developers and system administrators must talk to each other from the outset, and jointly decide what is feasible and necessary, under the direction of someone at ‘chief’ level. CIOs and CEOs must therefore be sufficiently involved, as data security is too important to be left to the IT department.
5. Does disk encryption solve every problem?
Disk encryption is a typical example of a simple solution that often scores poorly. Disk encryption is “encryption in rest”: it’s a good solution when the disk is lost or stolen, so useful for laptops or external hard drives.
HHowever, it’s not a solution for servers, because they run almost 100% of the time, and the drive is accessible when the server is running. That means a hacker who penetrates a server can still read the data on an encrypted disk.
You will therefore also need to look at other techniques that require programming changes, such as database encryption or data pseudonymisation. You can also make things simpler, and simply ask yourself if you really want or need to retain the data concerned.
What can Nucleus do to help you?
We at Nucleus have a wealth of experience with DevOps, and we are ideally placed to work alongside you to see which steps are desirable or necessary to better protect your data. This process is always tackled in phases: we first look at which measures can be put into place quickly and easily. then we identify measures that require more time and energy, and which can be addressed in a subsequent phase.
If you have any questions or comments, or want to find out more, please use the comments section at the bottom of this blog, or send us a message using the contact form.