To encrypt, or not to encrypt, that is the question
To encrypt, or not to encrypt, that is the question: whether ’tis nobler in the mind from the risk of security and privacy breaches to suffer
The slings and arrows of outrageous fortune, or to take arms against a sea of security and privacy concerns.
And by opposing end them. To encrypt — to rest assured,
No more; and by encrypt to say we end
The heart-ache of having to notify the thousands of data subjects
The dread required by law: ’tis consummation
Devoutly to be wish’d. To encrypt, to rest assured;
To rest assured, perchance to think of improving latency and performance — ay there’s the rub…
So what to do?
Should we encrypt the data and suffer the performance and latency penalty, but still rest assured, knowing that our data subjects private data is secured, or should we just do the bare minimum required of us by law and regulation?
To answer that question we need to first know what the law really says concerning privacy and the use of encryption. Keep in mind that I will leave out the NIS Directive, for now, and only describe what is said from the perspective of GDPR.
The regulation doesn’t specifically say that you have to use encryption, it only suggests it as one of several “appropriate safeguard”. art. 6, clause 4 e
DPIAs are used to identify specific risks to personal data as a result of processing activities. As part of the DPIA, “the controller or processor should evaluate the risks inherent in the processing and implement measures to mitigate those risks, such as encryption”. recital 83
But the regulation doesn’t specify how, where and when encryption is an appropriate safeguard.
But the regulation also requires you to notify data subject if “the personal data breach is likely to result in a high risk to the rights and freedoms of natural persons” (article 34, clause 1) If you want to know what constitutes “high-risk”, you should read my article on “The legal obligations of the data controller”.
The exceptions to the requirement for notifying data subjects of breach are art. 34, clause 3:
- If the controller has implemented measures, such as encryption, that means the data cannot be read by unauthorised persons.
- If the controller has taken steps to ensure the high risk is no longer likely to materialise.
- If notifying the affected persons would involve disproportionate effort. In this instance, the data controller will need to make a public communication to inform the data subjects in an “equally effective manner”.
So by using encryption, you can avoid the task of notifying the data subjects in the event of a breach even if you are doing processing of personal data that constitute a “high-risk” to the rights and freedoms of natural persons.
That is a really important point.
Imagine that you are a data processor that is processing personal identifiable data, that constitutes a “high risk”, for millions of people.
Data processors must assist data controllers in meeting the breach notification requirements, as noted in article 28.
Imagine having to notify millions of data subjects. You would have to go public and publish a press release in all relevant national news agencies saying that you lost sensitive data, oh and by the way, the privacy breach will cause harm to the rights and freedoms of millions of people.
Your reputation will be damaged and your customers are very likely to flee. Especially the ones that need to do processing that may constitute a “high-risk” to the data subject.
How will you ever be able to do business normally again?
If this is your situation you should definitely encrypt all your data both in transit and at rest.
If however, you are processing personal data that doesn’t constitute a high-risk or are doing high-risk processing for a small number of people, perhaps even on a closed network, then you can allow yourself to be more pragmatic and only use encryption where it is absolutely necessary.
There is one more thing you must know. Most solutions for storage and transfers have done pragmatic choices due to operational and performance concerns. This means that they do not necessarily encrypt your data in all cases even if these solutions are meant to encrypt your data. A typical example is application and system logs. It’s very important to be aware of this so that you make sure that your data also are encrypted in these cases. You should, therefore, in cases where you are doing large scale high-risk processing, consider using solutions like Hashicorp Vault to make sure you cover all edge cases.
Your performance is very likely to bleed through, but you should never put performance above privacy and security when your livelihood is at stake. Make sure your client understands this since it is most likely his livelihood which is at stake as well.
