Freely subscribe to our NEWSLETTER

That means the GDPR will likely go into effect sometime in 2017. 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, SAN Top 20, ISO 27001, etc.) shouldn’t find the GDPR to be 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: minimise 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 legislations 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 the1990s 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 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 anonymised is not covered by the GPDR or for that matter 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 organisation 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 26 (processor) and article 30 (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 minimisation 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 23 (data protection by design and default) further enshrines Privacy by Design ideas. The article is more explicit about data retention limits and minimisation 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 28 (documentation) 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 33 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 31 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 32 adds that data subjects must also be told about the breach but only after the supervising authority is informed.

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.

Focus Your GDPR Compliance

Some of the more important differences currently being negotiated between the stakeholders are the time allowed to report a breach (24 hours in Parliament’s GDPR vs. 72 hours in the Council’s), requirement to have a data privacy officer or DPO (mandatory vs. optional), and the maximum fines for non-compliance (5% vs 2% of a controller’s global revenue).

Along the way, the GDPR has fallen from its initial goal of a one-stop shop: a single supervising authority that would handle complaints and enforce the law.

Instead in the Council’s version, companies will deal with a lead DPA in the country where the controller is based. This gets complicated when personal data is transferred to another EU country, and so DPAs in those countries would get involved as well. However, if there’s no agreement among all the DPAs, then the case goes to a super-DPA, the European Data Protection Board, whose decisions would be final.

Bottom Line: companies will likely have to deal with several DPAs.

And before the GDPR is finalized, there will likely be other changes of significance.

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 we’re all waiting for the final draft of the new legislation, here are four areas where you should be 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.