GDPR Guidance For May 2018
The EU General Data Protection Regulation (the “Regulation”) coming into effect on 25 May 2018, which replaces the Data Protection Act 1998 largely repeats the security principles set out in the DPA. However, the GDPR enforces a much tougher and stricter regime, with more severe penalties for data breaches.
It is increasingly apparent as we canter towards GDPR (General Data Protection Regulation) May 2018 that several significant areas of data protection uncertainty remain and that these present head-on challenges to business, challenges for which there is little, if any, legislative or regulatory clarity at present.
everyone has their own personal list of these issues, but to identify the “top 5” that keep hitting our desk:
1. Just how is controller and processor liability supposed to work in practice?
As everyone knows by now, the GDPR will introduce direct, statutory liability for data processors. Controllers will no longer be solely on the hook. At the same time, potential fines for data protection breaches will run up to 4% of annual worldwide turnover.
But how will this new liability regime work in practice? And who will shoulder liability in the event of a data protection breach? For example, if one party to the data processing relationship is at fault (let’s say the processor), can data protection authorities pursue the other party (the controller) for the processor’s breach? Or will they pursue the ‘guilty’ party only?
What if both parties are partially at fault? Will data protection authorities go after one, the other, or both parties? At this point, we don’t know, and it’s causing havoc on commercial deal negotiations, controllers are asking their processors for unlimited liability (and their processors are refusing) and processors are asking their controllers for mutual liability in case the controller’s breach causes liability for the processor (and their controllers are refusing), and so on.
Guidance on how data protection authorities will exercise their enhanced enforcement powers against controllers and processors is sorely needed.
2. What’s the future of data exports?
The validity of the Standard Contractual Clauses is the subject of current court proceedings in the EU. For that matter, so is the EU-US Privacy Shield, which will also undergo its first annual review this September.
If either or both fail, we’ll be thrown into further data export chaos. Data will continue to move back and forth in exactly the same way it does today, of course (no one’s going to turn off the Internet overnight), but without the legal protections in place that currently exist.
Keeping that in mind, calling for the abandonment of these mechanisms without at least having a new, improved Plan B up your sleeves (and no, I don’t mean consent) risks being a spectacular own goal. Not to mention that there are far more pressing practical data protection concerns than the often academic debates typically voiced about the effectiveness of each of these regimes.
3. While we’re on exports, what about those onward transfers, eh?
How exactly is a non-EU importer meant to lawfully transfer data it receives onwards to third party recipients? There’s no good answer to this today. Sure, the controller-to-processor model clauses talks about sub processors becoming a party to the model clauses with the original data exporter and all but, y’know, how often have you ever seen that happen in practice? Good luck getting those big cloud infrastructure providers to sign model clauses with all of your customers…
And, as for the Privacy Shield’s Onward Transfer principle, what do you do when your onward recipient says it won’t sign Privacy Shield onward transfer terms with you but will sign model clauses if you countersign as the data exporter, except that you’re not the data exporter, you’re a data importer and so you’re not technically eligible to sign the model clauses!!! Not to mention that the Privacy Shield makes no mention of being able to rely on model clauses for onward transfers made under the Shield anyway.
Of course, you’ll probably still sign the model clauses in that scenario - it’s the pragmatic thing to do, and better to have a story to tell even if it’s not a great story. But, still. We desperately need an effective onward transfer toolkit that can actually works in practice.
4. Not all profiling is created equal.
There’s a perpetuated misconception that all profiling needs consent. It doesn’t, end of.
Sure, profiling resulting in an automated decision that “legally affects” or “significantly affects” a data subject (e.g. automated hiring decisions based on an algorithmic review of a candidate’s CV) will generally need consent, and rightly so - that’s what Art 22 of the GDPR requires. But other types of profiling, profiling which doesn’t legally affect or significantly affect a data subject (e.g. working out what loyalty offers to send a customer based on their purchasing habits) does not.
However, until we get regulatory guidance clearly distinguishing between these two types of profiling, this misconception will persist.
5. When you say “audit”, what exactly do you mean?
Another big bug bear of the GDPR (and the model clauses, for that matter): processors are meant to “allow for and contribute to audits, including inspections, conducted by the controller or another auditor mandated by the controller.”
How often have you tried to get a cloud provider to allow you to conduct onsite audits, only to be told that they can’t agree to it because they have thousands of customers and:
• giving every customer a right to audit them would cause significant business disruption - if not bring the business to a grinding halt - if only a fraction of those customers exercise their audit rights at the same time (e.g. following a security incident),
• allowing you to conduct an onsite audit, particularly in multi-tenanted solutions, presents a security risk to other customers’ data (would you want other customers poking around your data?),
• they have industry-standard third party audit certifications anyway (ISO 27001, SSAE 16/18, PCI-DSS, etc.) conducted by independent auditors who know more about what they’re doing than you do anyway.
What are the GDPR requirements?
The GDPR contains 99 articles that define its requirements and rights granted to EU citizens, GDPR operations and structure, and penalties. The articles that will have the most significant impact on business are:
- Article 5, processing and storing personal data: All personal data must be processed lawfully and transparently, and only for the purpose specified to the individual. That data may be stored “in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed.” All personal data must be processed securely to protect against unlawful access, loss or damage “using appropriate technical or organisational measures.” Those measures are not defined, but presumably if the data is lost or stolen, a company could be considered not in compliance.
- Articles 6, 7 and 8, consent: All processing of personal data must be done lawfully, by which is meant that each individual must give consent to use their personal data. The data collected must also be necessary to complete a task or transaction initiated by the individual, with the exception of public authorities.
- Article 15, right to access: EU citizens have the right to know upon request what personal data a company is using and how it is being used.
- Article 17, right to be forgotten and to data erasure: EU citizens can expect companies to stop processing and to delete their personal data upon request.
- Article 20, right to data portability: EU citizens may transfer their personal data from company to company upon request.
- Articles 25 and 32, data protection: Companies must be able to provide a “reasonable” level of data protection and privacy to EU citizens. It’s not clear what the GDPR governing body will consider reasonable.
- Articles 33 and 34, reporting data breaches: Companies must report data breaches to supervisory authorities and individuals affected by a breach within 72 hours of when the breach was detected.
- Article 35, impact assessments: Companies must conduct data protection impact assessments to identify risks to EU citizens. Those assessments also must describe how the company is addressing those risks.
- Articles 37, 38 and 39, data protection officers: Some companies must appoint a data protection officer (DPO) to oversee data security strategy and GDPR compliance. Companies required to have a DPO process or store large amounts of EU citizen data, process or store special personal data, regularly monitor data subjects, or are a public authority. The International Association for Privacy Professionals (IAPP) estimates that 28,000 DPO roles will need to be filled.
- Article 50, international companies: International companies that collect or process EU citizen data must comply with the GDPR.
- Article 83, penalties: Companies may be fined up to €20 million or 4 percent of global annual turnover, whichever is higher.
It’s only by identifying, cataloguing and communicating challenges like these that we can hope to educate the regulatory audience about the practical EU data protection challenges faced by organisations around the world every day, and, through this education, hope to encourage more, and more practical, regulatory guidance.
You Might Also Read:
