Townsend Security Data Privacy Blog

As the date for the formal implementation of the EU General Data Protection Regulation draws near, many of our customers are struggling with the question of whether or not they have to encrypt sensitive data. Because the fines for violating the GDPR can be quite high, this question is taking on a growing urgency. So, let’s take a look at this question in more detail by looking at the actual GDPR source documents.

The most relevant part of the GDPR regulation related to encryption is Article 32 - “Security of Processing”. The actual text of the article is very readable and you can find a link in the Resources section below. Here is an extract from Article 32 (emphasis added):

“Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate:

1. the pseudonymisation and encryption of personal data;
2. the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services;
3. the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident;
4. a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.”

Well, it looks like we don’t really have to encrypt the sensitive data because we get to take into account the costs of the implementation and the nature, scope, context and purpose for processing. Along with some other potentially mitigating factors. If you read no further you might draw the conclusion that encryption is a recommendation, but it is not a requirements. Question answered, right?

Not so fast. Let’s dig deeper. The next point in Article 32 shines a brighter light on this question:

“2. In assessing the appropriate level of security account shall be taken in particular of the risks that are presented by processing, in particular from accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data transmitted, stored or otherwise processed.”

In effect the GDPR is saying that your security controls must account for the risk of accidental, unlawful, or unauthorized disclosure or loss of personal data. That is a very broad category of potential violations of the protection of an individual’s data. Have you ever lost a backup cartridge? Do you really think your systems are secure enough to prevent access by sophisticated cyber criminals?

While on first look it seems that we have some leeway related to the deployment of encryption, GDPR quickly raises the bar on this question. Given the current state of security of data processing systems, no security professional should be absolutely comfortable with the security of their systems.

If you are still thinking you can avoid encrypting sensitive data, be sure to take a read of Recital 78, “Appropriate technical and organisational measures”.

It should be clear by now that if you decide NOT to encrypt sensitive data you should definitely document all of the reasons it is not feasible or practical to do so, and all of the measures you are actually taking to protect that data. Put this in writing and get senior management sign-off on your conclusions.

But there is more.

If you are wondering how serious GDPR is about encryption, be sure to read Recital 83 “Security of processing”. Here is an extract with emphasis added:

“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. 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. In assessing data security risk, consideration should be given to the risks that are presented by personal data processing, such as accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed which may in particular lead to physical, material or non-material damage.”

If you are getting the notion that the authors of the GDPR really want you to encrypt sensitive data, you would be right.

Where else does encryption come into play?

There are safe-harbors in GDPR around data breach notification IF you are encrypting sensitive data. The avoidance of notification is not absolute, but here is one relevant section of Article 34, “Communication of a personal data breach to the data subject” (emphasis added):

The communication to the data subject referred to in paragraph 1 shall not be required if any of the following conditions are met:

1. 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;

If the sensitive data of a data subject is lost and not encrypted, it will be difficult to argue that the information is inaccessible. The loss of unencrypted data will certainly require notification to the supervisory authority and the data subject.

There is one more aspect to the discussion of encryption and that relates to the management of encryption keys. Your encryption strategy is only as good as your ability to protect your encryption keys. This is reflected in Recital 85 “Notification obligation of breaches to the supervisory authority” (emphasis added):

“A personal data breach may, if not addressed in an appropriate and timely manner, result in physical, material or non-material damage to natural persons such as loss of control over their personal data or limitation of their rights, discrimination, identity theft or fraud, financial loss, unauthorised reversal of pseudonymisation, damage to reputation, loss of confidentiality of personal data protected by professional secrecy or any other significant economic or social disadvantage to the natural person concerned. Therefore, as soon as the controller becomes aware that a personal data breach has occurred, the controller should notify the personal data breach to the supervisory authority without undue delay and, where feasible, not later than 72 hours after having become aware of it, unless the controller is able to demonstrate, in accordance with the accountability principle, that the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons. Where such notification cannot be achieved within 72 hours, the reasons for the delay should accompany the notification and information may be provided in phases without undue further delay.”

If you are not properly protecting the encryption key used for encryption, it must be assumed that the encryption can be reversed. Don’t use weak encryption keys such as passwords, don’t store encryption keys in files or in application code. Instead, use a professional key management solution to protect the keys.

Returning to our original question about the need for encryption of sensitive data, I hope you have arrived at Yes as the most responsible answer. The loss of unencrypted sensitive data will definitely trigger the need for data breach notification. And the improper protection of encryption keys will also trigger the need for breach notification. You are at more risk of financial penalties if you are not properly protecting that sensitive information with encryption.

The GDPR is complex and some parts are subject to interpretation. But if you control or process sensitive data you should not underestimate the serious intent of the GDPR to enforce protections for individuals. GDPR is revolutionary and disruptive - it is dangerous to ignore it.

Patrick

Resources
The General Data Protection Regulation (GDPR)
The GDPR Recitals
GDPR Article 32 “Security of Processing"
Recital 78, “Appropriate technical and organisational measures”
Recital 83, “Security of processing”
GDPR Article 34, “Communication of a personal data breach to the data subject”
Recital 85 “Notification obligation of breaches to the supervisory authority”

The European General Data Protection Regulation (GDPR) is a radical and transforming event in the information technology space. Due to go into full effect on May 25, 2018, it will require major changes to IT systems and they way organizations relate to their customers, employees, and external partners. It is hard to overstate the the impact of the regulation. Organizations of all sizes and types, and cloud service providers small and large, must adjust to the notion that people now fully own information about themselves - and companies outside of the EU zone are impacted, too.

Article 17 of the GDPR focuses on the “Right of erasure”, also known as the “Right to be forgotten”. Here is a link to that section.

Let’s talk about how we can use encryption and key management to help meet the requirements of the legislation. Since deploying encryption will also help meet the privacy requirements of GDPR, the same technology can be used to implement Right of Erasure.

First, let’s look at the technology landscape related to encryption:

Encryption is one of the most well understood mechanisms for data privacy. There are well-established, mature standards for encryption and the related key management technologies. Most companies will use encryption to meet GDPR privacy requirements, and will be deploying encryption key management to protect the keys. There are mature encryption technology solutions available on all major enterprise operating systems and on all major cloud platforms. Protecting encryption keys is also well understood. Many organizations have already deployed encryption in some parts of their organizations, and GDPR will speed this process and extend protections across all parts of the data landscape.

The hardest part of getting encryption right has to do with creating, protecting, and deploying encryption keys. It is probably the hardest part of getting an encryption strategy right - and there are a lot of ways to get key management wrong:

• Storing the unprotected encryption key with the protected data
• Using weak protection methods to secure encryption keys
• Storing the encryption key directly in application code
• Using a weak encryption key - a password is an example of a weak key
• Not using strong, industry standard methods of generating an encryption key
• Not providing separation of duties and dual control around key management

There are lots of ways to get encryption key management wrong - and bad key management practices will result in GDPR compliance failures.

Fortunately, it is fairly easy to deploy good encryption key management that is affordable, easy to install and configure, and easy to integrate with your encryption strategy. A number of professional key management solutions are available to serve every enterprise operating environment. We have one (Alliance Key Manager), and others are available.

Now that we have a good encryption and key management strategy in place, let’s use it to meet the GDPR Right to Erasure.

Under GDPR Article 17 a need to erase personal information can be triggered by a number of events:

• A Data Subject (usually a person) can request erasure of personal information
• The personal information is no longer relevant from a business perspective
• A Data Subject withdraws consent and there is no overriding need or requirement to retain the data
• A Data Subject withdraws consent for processing their information
• Personal data has been unlawfully obtained or processed

That covers a lot of ground! It is not as simple as just responding to a request for erasure, we have to be aware of our actual need for information. And erasure triggers some secondary requirements:

• The Data Controller must attempt to remove data that has been made publicly available
• The Data Controller must inform third party Data Processors of the need to erase data

We have a lot of responsibilities under GDPR Article 17. How can we use encryption and key management to meet this requirement?

A key management approach:

Imagine that you assign a unique encryption key to each Data Subject (employee, customer, and so forth) and that you encrypt that person’s personal data in your databases with that unique and specific key. The time comes when must meet your obligations under Right of Erasure. Rather than go through every database table and storage server to delete the data, you could just delete the encryption key. Assuming you have strong encryption keys and industry standard key deletion processes, the deletion of the key is an effective way to zero the protected data without actually modifying the database. Data that is encrypted is unrecoverable if the key is no longer available.

There is one more added benefit to this approach - it effectively erases all of the data on your backups! Managing compliance with GDPR is especially difficult when it comes to off site backups of sensitive data. The ability to effectively erase data by erasing the encryption key without having to pull those backups out of storage is a huge cost and administrative saving!

The strategy described above is only defensible if you are encrypting the Data Subject’s information, if you are assigning them a unique encryption key, and if you are using an encryption key management solution that provably meets industry standards for key zeroization. Our key management solution does and you can get more information here.

We’ve touched just one aspect of GDPR. We will be talking more about GDPR in the days ahead.

Patrick