ADAPTING DPD
Until recently, data security regulations have been ‘back-page’ news. Certainly, when the DPD was the first introduced in the late 1990s, it was mostly of interest to attorneys, compliance officers and secondarily to IT executives. Enter the Internet, the data storage revolution, and ubiquitous consumer devices.
The result? An exponential year-to-year growth in the amount of information being stored and accessible from consumer devices.
The first problem the DPD structure had in dealing with these changes is that each country had some leeway in interpreting how the core rules would apply.
For example, the Internet era gave birth to a whole new source of electronic identifiers: email and IP addresses, online handles, and biometric data. But are they personal data? In many EU countries, these basic electronic identifiers were protected but some DPAs did not consider them personal data.
Other differences emerged regarding data transfers, making a few countries far more desirable locations for company headquarters and data centers.
Multinationals soon could cherry pick where they located their headquarters, essentially subverting the goal of the DPD to provide a uniform data security law.
With the rise of the cloud and massive amounts of processing and storage available on-demand, questions also came up about its legal status. Recall that the DPD is focused on data controllers.
Is the cloud a data controller or processor?
In 2012, the EU’s Article 29 Working Group, responsible for advising on DPD issues, provided guidance: companies that use the cloud are controllers since they direct how the cloud provider should handle the data. Therefore, the cloud is a processor.
The Working Group added that cloud customers should not accept boilerplate contracts from the cloud provider. Instead, contracts between the parties should have certain minimal DPD data security and a right to access clauses — for example, a request to delete consumer data by the controller had to be honored by the cloud provider.
But again, individual DPAs were free to interpret and come up with their own contract terms.
Further issues involved search engine providers, who as cloud-based data processors, would also be required to delete data on demand — in their case, search results. Only very recently was this resolved after a lengthy court process.
Per the EU Court of Justice, there is effectively a “right to be forgotten” in the current DPD. Interestingly, this right has an extraterritorial nature — personal data of EU citizens can be deleted even when the data processor is not located in an EU country.
Of course, it would have been far more straightforward if the DPD had more explicit language on data processors and erasure rights, and the member countries had less leeway to interpret the rules. This would all soon change.
NEW EU GENERAL DATA PROTECTION REGULATION
Realising the data old 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 covering all EU countries and a “one-stop” shop approach to enforcement through a single data authority. The result is the General Data Protection Regulation, which will go into effect in 2018.
The GDPR is not a complete rewrite of the DPD. Instead, it enhances the existing DPD. However, there are some new requirements, most significantly for breach notification and more extensive documentation.
WHAT TO KEEP?
Let’s first take up what’s been revised and clarified by the GDPR.
First, the GDPR keeps the DPD’s definition of personal data. However, there’s additional language that takes into account what’s known as quasi-identifiers. These are one or more pieces of information — location and online identifiers are specifically mentioned — that with additional external data references can be used to pinpoint a person.
The GDPR puts in place more specific obligations on processors and therefore the cloud and effectively says that the cloud provider must protect the security of data given to it by the controller. The GDPR added the ability of a consumer to directly sue a processor for damages — in the DPD it was only the controller that could be held liable.10
Article 5 (principles related to personal data processing) essentially echoes the DPD’s Article 6’s minimization requirements: personal data must be “adequate, relevant, and not excessive in relation to the purposes for which they are processed”. There’s language that says that personal data can’t be kept longer than is necessary based on the original reason it was collected. Is 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 PbD ideas. The Article is more explicit about data retention limits and minimization in that you must set limits on data (duration, access) by default, and it gives the Commission the power to lay down more specific technical regulations at a later time.