Far from the heady statements made when 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. 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 here I 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 controller, processor or both? 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 (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 sleeve (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 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 work 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 (eg automated
hiring decisions based on an algorithmic review of a candidate’s CV) will
generally need consent, and rightly so – that’s what Article 22 of the
GDPR requires. But other types of profiling, profiling which doesn’t legally
affect or significantly affect a data subject (eg 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 bugbear 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 (eg 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.
Phil Lee is a Partner in Fieldfisher’s Privacy, Security and Information law group,
based in London team. He holds CIPP/E certification and is a Registered Foreign
Legal Consultant with the State Bar of California.
This article first appeared as a blog post on the Fieldfisher Privacy, Security
and Information blog.
