On April 24, 2018 Patrick Townsend, CEO and founder of Townsend Security published a blog considering the relevance of encryption to GDPR compliance.   A year later, we agree that Mr. Townsend’s blog remains a relevant starting point for enterprises on-the-fence about the wisdom of encrypting all data. 

As we hit the 1-year anniversary of the GDPR’s ratification, many of our customers should be asking: Should Linux laptops, desktop, servers and embedded systems with storage (herein referred to as Linux Devices) be encrypted to comply with GDPR?  The short answer to this question is yes. The first wave of GDPR fines have been substantive (€50M is the highest so far) and handed out quickly (many within 4 months of investigation). And it appears regulators are just getting started.

Therefore, it is prudent to consider the question of Linux Devices in light of the actual text of the GDPR.

Spoiler Alert

Here’s the punchline: Strictly speaking, encryption is recommended but not required by the GDPR at this time.  However, encryption is explicitly cited throughout the GDPR (and other laws) as a recommended best practice.  Therefore lawmakers appear to be aligned with many independent technical experts in recommending encryption as one of the most elegant, robust and complete data protection solutions to-date.  Who cares if there is a breach if the data itself was encrypted at the outset? Thus, encrypting all your devices, including Linux Devices, remains a good decision for today’s data controllers. Read on for more substantive GDPR analysis.

The Starting Point: Article 32

The most relevant starting point for GDPR analysis is Article 32 “Security Processing” which states:

“1. 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 organizational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate:

1. the pseudonymization 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 organizational measures for ensuring the security of the processing.”

It would seem from the above that enterprises do not really need to encrypt Linux Devices because one can simply explain-away one’s decision not to do so by citing (1) the cost of implementation, (2) the nature, scope, context and purposes of processing, (3) as well as the risk of varying likelihood and the severity for the rights and freedoms of natural persons to a regulator.

However, Section 2 of Article 32 expands on this seemingly wide loophole with the following:

“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, unauthorized disclosure of, or access to personal data transmitted, stored or otherwise processed.”

Here, the GDPR requires that security controls must account for the risk of accidental, unlawful, or unauthorized disclosure or loss of personal data.  We agree with Patrick Townsend that: “This is a very broad category of potential violations of the protection of an individual’s data.”  Practically speaking, “Have you ever lost a backup cartridge? Do you really think your Linux systems are secure enough to prevent access by sophisticated cyber criminals?”

So, while it may seem like enterprises have the same leeway they have always had to do the bare minimum in their deployment of security solutions the GDPR has significantly raised the bar on the “minimum requirement” making encryption one of the most sensible uniform security solutions available to date.

GDPR and Encryption: Security of Processing

Another place where encryption is explicitly cited is Recital 83 “Security of Processing”:

“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 measure 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, unauthorized 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 starting to get the impression that European lawmakers want data controllers to encrypt all data in their control you would be right.  For even more examples, read on.

GDPR and Encryption: Potential Safe-Harbor from Notification Requirement

Where else can encryption help a CISO?  Let’s take a look at Article 34: “Communication of a Personal Data Breach to the Data Subject”

“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 organizational 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 authorized to access it, such as encryption.”

Practically speaking, the above appears to suggest that if Linux Devices containing sensitive personal data are lost, enterprises who have encrypted these Linux devices could receive leniency from regulators in their required response to that breach.  This makes sense because when a device is encrypted, even if the physical device is lost or stolen and the data breached, without the key, that data is unreadable.  Those choose not to encrypt their Linux Devices however will have a much more difficult time making this argument to a regulator (as frankly, the data could be exposed in plain text form).  As a result they will likely be held to a higher standard in their response to the breach.

But what is the highest standard applicable to data controllers who become aware of a breach? The required actions are set out in Recital 85 “Notification obligation of breaches to the supervisory authority”

“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, unauthorized reversal of pseudonymization, 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.”

In other words, if the device was encrypted, a data controller can more easily demonstrate that the breach is unlikely to result in a risk to the rights and freedoms of the natural persons as the data was encrypted and (in the case of our solutions) the key can be remotely killed, forever locking anyone from the data on the device.

Documenting Your Decision Not to Encrypt: Internal Policies and Measures

Despite the above, if you decide not to encrypt your Linux Devices, you should be aware of Recital 78 “Appropriate technical and organizational measures”:

“The protection of the rights and freedoms of natural persons with regard to the processing of personal data require that appropriate technical and organizational measures be taken to ensure that the requirements of this Regulation are met. In order to be able to demonstrate compliance with this Regulation, the controller should adopt internal policies and implement measures which meet in particular the principles of data protection by design and data protection by default. Such measures could consist, inter alia, of minimizing the processing of personal data, pseudonymizing personal data as soon as possible, transparency with regard to the functions and processing of personal data, enabling the data subject to monitor the data processing, enabling the controller to create and improve security features. When developing, designing, selecting and using applications, services and products that are based on the processing of personal data or process personal data to fulfil their task, producers of the products, services and applications should be encouraged to take into account the right to data protection when developing and designing such products, services and applications and, with due regard to the state of the art, to make sure that controllers and processors are able to fulfil their data protection obligations. The principles of data protection by design and by default should also be taken into consideration in the context of public tenders.”

Recital 78 strongly suggests that if you decide not to encrypt your organization’s Linux Devices the GDPR suggests that you should (1) document all of the reasons you are choosing not to encrypt these devices and (2) all of the alternative measures you are taking to protect the data stored on those devices and (3) these reasons should be set out clearly in writing ideally with senior management sign-off.

Back to the Original Question

So, back to our original question:  Should we encrypt our Linux Devices to ensure our compliance with GDPR? Given the above, we believe the simple answer is, Yes.  While you are not required to encrypt your devices the GDPR makes it abundantly clear that doing so will be viewed favorably by regulators as it easily brings you in line with many of its provisions, which (like most laws) can be ambiguous as they are broadly written.

Your organization risks receiving greater financial penalties if sensitive personal data is not properly protected with encryption. This is because (1) the loss of unencrypted personal data stored on Linux Devices will trigger the need for data breach notification, and (2) the improper protection of encryption keys will also trigger the need for breach notification.

Since its adoption by the EU in 2016, the GDPR has been revolutionary and disruptive. Now that it has come into force, regulators have picked up their new powers of enforcement with vigor. We agree with others in the InfoSec space that enterprises who ignore its impact to their data management practices are taking a serious risk.

The costs or risks associated with encrypting Linux Devices is no longer prohibitive.  Linux has crossed a threshold so that these devices now ought to be encrypted.  Past tools for managing encryption Linux on we’re prohibitively costly, but with solutions now available, it’s much more feasible – and quite frankly, the greater costs to not encrypting your Linux Devices far outweighs the affordable options to do so.