Far from the heady statements made at the time that the draft GDPR was first proposed, that we would soon usher in a new era of data protection uniformity, certainty and reduced red tape (a kind of data protection utopia, if you will), it is increasingly apparent as we canter towards 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.
I’m sure everyone has their own personal list of these issues, but to identify the “top 5” that keep hitting my 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. We can hope they’ll survive all these challenges, but crossing your fingers isn’t much use (remember Safe Harbor?)
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.
It feels a little like the data protection equivalent of the story of the Greek prophet Cassandra - who could see tragedy approaching, but whose warnings fell on deaf ears. And don’t get me started on the UK’s adequacy post-Brexit!
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 subprocessors 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.” Well, good luck with that.
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, or
- all of the above?
Yes, there may be data processing relationships where onsite audits are entirely appropriate and warranted - but we need to be a little more sophisticated than that and recognise that, in many relationships, reliance on third party audit certifications (or other pseudo-audit mechanisms - written responses to questions or supplying evidence of data protection policies in place, for example) is often good enough.
Quit your jibber-jabber, fool.
The above might seem like a bit of a gripe, and I suppose it probably is. But it’s a gripe with a purpose. These are areas where we sorely lack real regulatory clarity about how to apply data protection rules on a practical, workable basis, and yet they come up all the time.
That brings me to my point: 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.