GDPR ConsentThe EU’s General Data Protection Regulation has been in full force for almost three months as of this writing, but many companies are still struggling with the challenges of attaining and maintaining compliance with its numerous complex requirements.

Last month, in my article titled Think you’re GDPR compliant? Think again, I wrote about how consent can be key to proving that your organization’s collection, storage, and processing of personal data of individuals is lawful under the GDPR.  We discussed the new and strict requirements for consent to be considered valid, which are laid out in Article 7 (Conditions for Consent), and how this impacts “bundled” agreements that many companies have used in the past to obtain consent.

However, no matter how meticulous you are about following all the rules and documenting the process to show that consent was, per Recital 32, “given by a clear affirmative act establishing a freely given, specific, informed and unambiguous indication of the data subject’s agreement to the processing of personal data relating to him or her,” it’s vital to understand that this is only one step of many that must be taken to fully comply with the GDPR.

The next and most obvious requirement is, once that data has been collected, to keep it secure during processing and storage. That will be the focus of this article, which is Part 1 of a multi-part series. In subsequent articles, we’ll address additional requirements that include notification, documentation, and reporting, as well as the appointment and role of a data protection officer.

GDPR data security requirements

You’ll recall that the GDPR differentiates between two entities that are responsible for complying with its mandates regarding personal data: controllers and processors. To some extent, your obligations are dependent on which of these categories you fit.

  • The controller, as the name implies, is ultimately in control – this is the entity that determines the purposes and means of the processing of personal data. Along with this authority comes the responsibility for ensuring that it is done in compliance with the Regulation.
  • The processor is the entity that actually performs the processing of data, and the processing entity is hired or appointed by the controlling entity. The processor has contractual obligations to the controller and also has specific legal obligations under the law.

The responsibility of the controller

Article 24 of the GDPR is devoted to the responsibilities that the law lays on the shoulders of data controllers. It’s short, but its provisions are broad in scope and not very specific. Controllers are required to “implement appropriate technical and organizational [sic] measures to ensure and to be able to demonstrate that processing is performed by this Regulation.”

Unfortunately, the relevant recital (Recital 74) doesn’t really clarify this very much. It simply reiterates that “In particular, the controller should be obliged to implement appropriate and effective measures and be able to demonstrate the compliance of processing activities with this Regulation, including the effectiveness of the measures.”

This means it’s up to the supervisory authorities to judge whether a particular organization’s measures are up to the required standard. However, controllers can glean some information that’s somewhat more specific by taking a look at responsibilities of the processor – since the controller’s responsibility involves making sure the processor falls those guidelines.

Responsibilities of the Processor

You won’t find a GDPR article with this exact title (unlike the above in relation to the controller), because the processor’s responsibilities are broken down into multiple articles. In this article, we will only be dealing with those that address aspects of securing the personal data, but be aware that the processor’s responsibilities extend beyond that.

The most important of these is Article 32, Security of processing. It starts out just as vague as the article on processors’ responsibilities, saying “ … the controller and the processor shall implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk …” but then it gets more specific, with some specific measures that should be taken “as appropriate” (we’ll come back to that wording later): pseudonymization and encryption of personal data.

Pseudonymization and Encryption

Let’s take a look at what each of those mean.

  • Pseudonymisation (or pseudonymization in the U.S.) is a process by which personal data is rendered unidentifiable by using artificial identifiers to replace the information that links the data to a particular individual.  It differs from anonymized data in that it’s possible to restore the original state of pseudonymized data by replacing the artificial identifiers with the original ones. Pseudonymized data cannot be attributed to a specific data subject without additional information, and under the GDPR, that additional information must be stored separately from the pseudonymized data.
  • Encryption is the process of translating data into another form that prevents other people who don’t have access to a “key” or password from being able to read it.  Encrypted data is referred to as ciphertext because a cipher – an encoding method – was used to disguise it.  Encryption is a form of cryptography (from the Greek for “hidden writing”). Modern cryptographic systems are generally divided into two categories: symmetric (private key) and asymmetric (public key).

Whereas pseudonymization can be accomplished by several different methods, including scrambling or blurring, the most common way of pseudonymizing is through masking. Masking techniques involve hiding parts of the data by replacing it with random characters or with other data.  The use of data masking is common in online transactions where, for example, most of your credit card number or email address is replaced by Xs in receipts or stored forms (XXXX XXXX XXXX 1243 or d*@outlook.com.

Data blurring is used to pseudonymize graphic data (drawings, photos, videos and diagrams), such as the blurring out of faces in videos to protect the identities of those captured by the camera, or blurring of the sections of a picture of a social security card where the sensitive information (name, card number) is displayed. This is done by pixelating the portions of the digital image that you want to obscure. Blurring has some serious drawbacks as a means of pseudonymization, in that computer algorithms can be used to easily match pixelated images to their original, unblurred versions.

Encryption is a complex subject, and an in-depth discussion is beyond the scope of this article, but for purposes of GDPR compliance, the stronger the encryption that you use to protect personal data, the better. Personal data should be encrypted both in transit (as it travels over your network or through your systems during processing) and at rest (when it is stored for further processing or future reference).

Requirements or suggestions?

The GDPR uses wording that, at first glance, suggests that the use of pseudonymization and encryption is only a suggestion, not a requirement. It even says (in Article 32) you can take into account “the state of the art, the costs of implementation and the nature, scope, context, and purposes of processing.”

Does that mean if implementing these security measures is costly, you don’t have to do it?  

No such luck. The same paragraph goes on to say that you must also take into account “the risk of varying likelihood and severity for the rights and freedoms of natural persons,” and then expands upon that to make it clear that “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 [sic] disclosure of, or access to personal data transmitted, stored or otherwise processed.”

Now it’s sounding a lot less optional, since the many, many data breaches that occur every week – including breaches at organizations that have extensive and expensive security measures in place – indicate that it’s going to be difficult or impossible to show that the data you collect or process is not at risk of unauthorized disclosure or access.”  And if that unauthorized access does take place, that data had better be encrypted or pseudonymized so that even though attackers can intercept it, they won’t be able to read it.

Summary

Under the GDPR rules, personal data must be obtained lawfully, but once that’s done, it must also be secured to prevent unauthorized disclosure or access. The GDPR doesn’t specify all of the security measures that you should take (or as a controller, make sure the processor is taking) but it does mention two particular techniques right up front: pseudonymization and encryption.

Obviously, these are “last resort” measures to protect the data in case your other security mechanisms – such as secure transfer of data from your website, network perimeter security, system security, vulnerability patching, malware and virus protection, user education, and so forth – fail to prevent unauthorized persons from reaching the data.  Those standard parts of a security strategy are also part of what the GDPR calls “appropriate technical and organizational [sic] measures“ to comply with the security mandate of the Regulation.