Table of Contents

•DPD 2.0

•GDPR Vocabulary

•Articulating the Articles

•More Articles: The New Stuff

•Focus Your GDPR Compliance

Note: This post now reflects the final version of the EU GDPR.

Overview

It’s been a long time coming, but the new EU data security and privacy law, known as the General Data Protection Regulation (GDPR), is close to being finalized. We’ve been tracking the GDPR through all its ups and downs over the last two years, as it progressed through the EU legislative process.

The negotiating parties — the EU Council, Parliament, and Commission — finalized the GDPR text in December 2015, and officially approved the law in April 2016.

That means the GDPR will go into effect in May 2018.

Keep calm, there’s nothing to panic over just yet.

The new GDPR can be seen as an evolution of the EU’s existing data rules, the Data Protection Directive (DPD). If your company is new to the EU market, then the GDPR might be a challenge. However, any company that follows IT best practices or industry standards (PCI DSS, SANS Top 20, ISO 27001, etc.) shouldn’t find the GDPR too burdensome.

One way to describe the GDPR is that it simply legislates a lot of common sense data security ideas, especially from the Privacy by Design school of thought: minimize collection of personal data, delete personal data that’s no longer necessary, restrict access, and secure data through its entire lifecycle.

DPD 2.0

The current EU Data Protection Directive has been around since 1995, but as technology marched on some of its shortcomings became more apparent. The Internet, the cloud, and big data were just a few of the factors that forced the EU to reconsider its existing approach to its data security law.

One of the main problems with the Directive is that allowed member countries to write their own legislation using the Directive as a template —“transposing” in EU bureaucrat-ese — and then enforce the rules separately. With the aforementioned technology disruptions, member countries had different interpretations as to what constitutes personal identifiers (MAC addresses? biometric?) or who’s responsible when data is the cloud (the company or the service provider).

Realizing the old data security law had to be revamped, the EU Commission in 2012 started the process of creating new legislation. Their primary goal was a single law — “harmonization”, as it’s called — covering all EU countries and a “one-stop” shop approach to enforcement through a single data authority.

The GDPR is not a complete rewrite of the DPD. Instead it enhances the existing DPD. Interestingly the current DPD also had as its goal back in the 1990s a single law to replace individual national laws.

The GDPR looks like it will finally realize that dream — or come a lot closer.

So it’s probably better to view the new law as DPD 2.0. However, it adds a few important changes. Most significantly, there’s a breach notification requirement that would force companies to notify the data authorities and consumers when there’s been a data exposure. There’s really nothing like that here in the US.

Another change is that the penalties for non-compliance will be significant: either 2% (in the Council’s version) or 5% (in the Parliaments) of global revenue. One could argue that the GPDR is really focusing on multi-nationals, particularly US ones, which earn most of their revenue outside of the EU.

GDPR Vocabulary

The GDPR is a huge document — over 100 PDF pages of legal language. However for IT and security folks who will have to implement some of the rules, the key parts are in just a few of the Regulation’s articles.

But before we dive into the GDPR, let’s get some basic vocabulary out of the way.

In the GDPR, personal data means any information “relating to data subject”. A data subject is “an identified natural person or a natural person who can be identified, directly or indirectly, by means reasonably likely to be used” by someone.

This somewhat convoluted definition is actually the language of the original DPD. As with the old rule, the GDPR encompasses obvious identifiers such as phone numbers, addresses, and account numbers as well as new Internet-era identifiers, such as email, biometric — anything that relates to the person.

The GPDR also accounts for what’s known as quasi-identifiers, which we’ve written about before in this blog. These are multiple data fields — typical geo and date — that through a little bit of processing and external reference sources one can use to indirectly zero in on the individual.

In any case, personal data is what you are supposed to protect! Data that has been anonymized is not covered by the GPDR or for that matter in the current DPD.

The GDPR also continues with the DPD’s terminology of data controller and data processor, which are used throughout the law.

A data controller is anyone who determines the “purposes and means of processing of the personal data.” It’s another way of saying the controller is the company or organization that makes all the decisions about initially accepting data from the data subject.

A data processor is then anyone who processes data for the controller. The GDPR specifically includes storage as a processing function, so that takes into account, say, cloud-based virtual storage.

Putting all this together, the GDPR places rules on protecting personal data as its collected by data controllers and passed to data processors. One shortcoming of the DPD was that it left some loopholes for data processors — i.e., cloud providers — that the GDPR now effectively closes off.

 

Articulating the Articles

Now let’s get into some of GDPR’s legal-ese.

The new law puts in place more specific obligations on data processors and therefore the cloud. This is described in articles 28 (processor) and article 33 (security of processing)—for wonks, this parallels the DPD’s article 17 — and effectively says that the cloud provider must protect the security of data given to it by the data controller.

The GDPR adds the ability for someone to directly sue a processor for damages — in the DPD, it was only the data controller that could be held liable.

Article 5 (principles related to personal data processing) essentially echoes the DPD’s minimization requirements: personal data must be “adequate, relevant, and not excessive in relation to the purposes for which they are processed …” But it also says the data controller is ultimately responsible for the security and processing of the data.

Article 25 (data protection by design and by default) further enshrines Privacy by Design ideas. The article is more explicit about data retention limits and minimization in that you have to set limits on data (duration, access) by default, and it gives the EU Commission the power to lay down more specific technical regulations at a later time.

More Articles: The New Stuff

There are a few new requirements that directly impact IT. Again if you’re following common-sense best practices, none of the following should be too much of a burden. Although the DPIAs (see below) is as an extra bureaucratic layer that will likely cause some head scratching (and cursing) — the details will probably have to be worked out by the regulators.

Article 30 (records of processing activities ) adds new requirements for data controllers and processors to document their operations. There are now rules for categorizing the types of data collected by controllers, recording the recipients for whom the data is disclosed, and specifying an indication of the time limits before the personal data is erased.

Article 35 calls for data protection impact assessments (DPIAs) before the controller initiates new services or products involving the data subject’s health, economic situation, location, and personal preferences — and more specifically data related to race, sex life, and infectious diseases. The DPIAs are meant to protect the data subject’s privacy by, among other restrictions, forcing the controller to describe what security measures will be put in place.

The new breach notification rule probably has received the most attention in the media. Prior to the GDPR, only telecom and ISP service providers had to report breaches within 24 hours under the e-Privacy Directive.

Modeled on this earlier Directive, the GDPR’s article 33 says that controllers must tell the supervisory authority the nature of the breach, categories of data and number of data subjects affected, and measures taken to mitigate the breach.

Article 34 adds that data subjects must also be told about the breach but only if the breach results in a high risk to their “rights and freedoms”. If a company has encrypted the data or taken some other security measures that render the data unreadable, then they won’t have to inform the subject.

Article 17 (right to erasure and “to be forgotten”) has strengthened the DPD’s existing rules on deletion and then adds the controversial right to be forgotten. There’s now language that would force the controller to take reasonable steps to inform third-parties of a request to have information deleted.

This means that in the case of a social media service that publishes personal data of a subscriber to the Web, they would have to remove not only the initial information, but also contact other web sites that may have copied the information. This would not be an easy process!

Finally, a requirement that has received less attention but has important implications is the new principle of extraterritoriality described in Article 3. It says that even if a company doesn’t have a physical presence in the EU but collects data about EU data subjects—for example, through a web site—then all the requirements of GDPR are in effect.

This is a very controversial idea, especially in terms of how it would be enforced.

Article continues below…

Focus Your GDPR Compliance

Going into the final negotiations that began in 2015, there were still differences between the parties – the EU Council, Parliament, and Commission—on some key issues. These included the GDPR fine structure, data privacy officers (DPO), and breach notification reporting. We’ve already mentioned the breach rules, so let’s cover the other two.

The GDPR has a tiered fine structure. Article 83 (General conditions for imposing administrative fines) says that company can be fined up to 2% of global revenue for not having their records in order (article 30), not notifying the supervising authority and data subject about a breach (articles 33, 34), or not conducting impact assessments (article 35).

More serious infringements merit up to a 4% fine. This includes violation of basic principles related to data security (article 5) and conditions for consumer consent (article 7) — these are essentially violations of the core Privacy by Design concepts of the law.

Since the EU GDPR rules apply to both data controllers and processors, that is “the cloud”, the huge cloud providers are not off the hook when it comes to GDPR fines.

Coming into the negotiations, there were also differences over whether companies had to appoint a data protection officer who would be responsible for advising on and monitoring GDPR compliance, as well as representing the company when contacting the supervising authority. With the final GDPR, many companies will likely need a data protection officer or DPO (article 37).

For companies new to the EU market and any company, but particularly US, caught in the extraterritoriality net, the GDPR will come as something of a shock. This is especially true for web-based services that are not regulated under existing US financial or medical data security laws.

While you now have two years to get into GDPR compliance, we’ve come up with four areas where we think you should begin focusing your attention and resources:

•Data classification – Know where personal data is stored on your system, especially in unstructured formats in documents, presentations, and spreadsheets. This is critical for both protecting the data and also following through on requests to correct and erase personal data.

•Metadata – With its requirements for limiting data retention, you’ll need basic information on when the data was collected, why it was collected, and its purpose. Personal data residing in IT systems should be periodically reviewed to see whether it needs to be saved for the future

•Governance – With data security by design and default the law, companies should focus on data governance basics. For unstructured data, this should include understanding who is accessing personal data in the corporate file system, who should be authorized to access, and limiting file permission based on employees’ actual roles – i.e., role-based access controls.

•Monitoring –The breach notification requirement places a new burden on data controllers. Under the GDPR, the IT security mantra should “always be monitoring”. You’ll need to spot unusual access patterns against files containing personal, and promptly report an exposure to the local data authority. Failure to do so can lead to enormous fines, particularly for multinationals with large global revenues.

Indecium can help! Click here to see how Indecium solutions will keep your unstructured data in compliance with the GDPR.

Wonk Alert: Need more EU Data Protection Regulation knowledge? Our white paper goes into even more detail!