Last week we went over the GDPR A Deeper Dive – 2changes that set GDPR apart from other mandates and data privacy legislation. One aspect of GDPR that has received a lot of attention is the ‘Right to be Forgotten’ which is outlined in Article 17 entitled “Right to Erasure (’right to be forgotten’)”. It states:
“The data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay and the controller shall have the obligation to erase personal data without undue delay where one of the following grounds applies:
(a) the personal data are no longer necessary in relation to the purposes for which they were collected or otherwise processed;
(b) the data subject withdraws consent on which the processing is based according to point (a) of Article 6(1), or point (a) of Article 9(2), and where there is no other legal ground for the processing;
(c) the data subject objects to the processing pursuant to Article 21(1) and there are no overriding legitimate grounds for the processing, or the data subject objects to the processing pursuant to Article 21(2);
(d) the personal data have been unlawfully processed;
(e) the personal data have to be erased for compliance with a legal obligation in Union or Member State law to which the controller is subject;
(f) the personal data have been collected in relation to the offer of information society services referred to in Article 8(1).”
In plain English this means that organisations need to fully erase a subject’s data from all repositories when that person revokes their consent; when the purpose for which the data was collected is complete; or when compelled by the law.
It is worth noting that this is not an absolute requirement and subjects do not have an unconditional right to be ‘forgotten’. If there are other legitimate, legal reasons – as outlined in the regulation – for the organisation to retain and process data, subjects are not entitled to be forgotten. However, exceptions are few compared to the multitude of data uses common in our daily lives.
So, in the spirit of GDPR, how do organisations ensure that data is deleted from all of the places that it is stored or processed? Full data erasure isn’t a straight forward proposition. Using a standard delete function doesn’t always fully remove data. While it may not appear in file registries or indexes, deleted data is often still recoverable. In these instances, despite best efforts, simply hitting ‘delete’ doesn’t achieve GDPR compliance. To complicate the issue, in 21st century business data is shared constantly between suppliers, partners, resellers and customers. When consent is revoked or a contract comes to term, how does an organisation guarantee that data is adequately deleted by all of these different players?
Encryption is one way to fully ensure that data is unusable per GDPR’s erasure obligation. Encryption alters data by using a specific secret – or key defined by an algorithm – to render data unreadable. The only way to return encrypted data into a readable state is by providing the corresponding key that was used to alter the data in the first place. If that key were to be deleted, it would be impossible to convert or decrypt that data back into a readable format. When it comes to GDPR’s ‘right to be forgotten’ encrypting data and deleting the key (also known as cryptographically erasing the data) is both an effective and convenient solution.
Such an approach gives organisations quite a bit of flexibility in deciding how to meet this obligation. Encryption is the kind of tool that organisations can apply at different levels of the data’s flow from creation to rest. If it were as simple as deleting a file, an organisation could use a file system-level solution to encrypt the file and delete the key. On a larger scale, say at the end of a project, an organisation could encrypt an entire database column – say of social security numbers, usernames, or family names – and delete the key. More advanced developers could even incorporate encryption into their applications and then delete the keys that the application uses. In any scenario, policy-based access controls allow organisations to finely tune their approach to data deletion for greater confidence in their approach to GDPR compliance. The permutations are many, but the fundamentals are the same.
As organisations consider their GDPR needs, they should place them in the context of their larger security needs. Adopting one-off encryption solutions to address discrete challenges is the quickest way to end up with a collection of burdensome security silos that complicate on-going management. Encryption is the tool that works on the data, but an organisation’s key management apparatus will eventually be the key (pun fully intended) to future security and compliance success. In choosing an encryption and key management vendor, organisations should consider the solutions currently in place in their data centre, their existing needs, and their future needs in order to find a solution set that will grow with them.
The ‘right to be forgotten’ isn’t as daunting a requirement as it may seem at first glance. A thoughtful use of encryption can help organisations respect data subjects’ wishes and preserve privacy in any scenario. Next week we’ll return to the pages of this blog to take a look at GDPR’s data control and integrity requirements. Stay tuned!
For additional information on GDPR, check out The General Data Protection Regulation ebook.