Data Protection: Controllers, Processors, Contracts, Liability – the ICO Draft Guidance

Those struggling with controller-processor contracts in the
run-up to 25 May 2018 will be familiar with Articles 28 and 82 of the GDPR –
what some might call another kind of PETs, the ‘palindromic evil twins’ of
GDPR.

The GDPR fundamentally changes the balance of obligations
and liabilities between controllers and processors. As data protection
practitioners know, Article 28 sets out mandatory minimum terms that must be
included in contracts between controllers and their processors, and
requirements regarding processors’ use of sub-processors (termed ‘another
processor’). Article 82 entitles ‘any person’ to compensation from the
controller or processor for damage suffered by the person as a result of a GDPR
infringement, with exculpatory provisions on, effectively, proving non-responsibility.
And of course, for the first time, processors will have direct statutory
obligations for certain data protection matters.

All this means that contracts are of huge practical
importance, particularly as the GDPR won’t ‘grandfather in’ pre-existing
contracts: strictly, all
controller-processor contracts, even pre-existing ones, must be brought into compliance
by 25 May 2018. Yet, inexplicably, controller-processor contracts and
liabilities don’t seem destined for any guidance from EU regulators the Article
29 Working Party (WP29), at least according to WP29’s published work programs/roadmaps
to date. However, some national regulators have picked up the baton. On 13
September 2017 the UK’s ICO issued draft guidance, ‘Contracts
and liabilities between controllers and processors‘, for a brief consultation
closing on 10 October 2017. On 29
September, France’s CNIL also issued a guide, ‘Guide
du Sous-traitant’ (many thanks to
Nathalie Lanaret for pointing this out). This article covers only the former,
and aims to highlight some of the many remaining uncertainties that the ICO
draft has not addressed.

The ICO has produced some excellent guidance in the past.
But here, overall, the ICO’s draft guidance seems redolent of a 20th-century
controller world, giving not even one online/Internet example. The ICO’s
guidance addresses controllers (‘you’) almost entirely throughout, with only a
short section for processors (contrast the CNIL’s guide, which is aimed at
processors). The draft guidance also contains some errors and omissions. Most
disappointingly, it ‘copies out’ the GDPR’s text without providing real
guidance on the difficult uncertainties that practitioners face in real life,
particularly in relation to commoditised IaaS and PaaS cloud computing services
(see my previous SCL article
on GDPR and cloud). This approach will not be of assistance to SME readers
either, who are presumably the main target audience for the guidance. Let me
give some examples.

General

Is the requirement to enter into an Article 28-compliant
contract, on pain of a potential 2%/€10m fine under Article 83(4), applicable
to both controllers and processors, ie could a processor be fined if it doesn’t
have compliant contracts with all its controllers in place by 25 May 2018? Or is
only the controller at risk here? The ICO draft says nothing on this.

The GDPR tempers two mandatory contractual terms, obliging processors
to give controllers certain assistance, by requiring the nature of the
processing to be taken into account (Article 28(3)(e)-(f)). Indeed, processors
must take measures to help controllers meet data subjects’ requests regarding
their rights only ‘insofar as this is
possible’ (Article 28(3)(e)). However, the ICO draft omits this important
qualification. It also fails to mention the equally-important ‘nature of the
processing and information available to the processor’ qualification in Article
28(3)(f), in the context of processors helping controllers to comply with controllers’
obligations regarding security, personal data breach notification, DPIAs and
prior consultation with supervisory authorities.

Furthermore, commoditised infrastructure cloud services in
fact exemplify the situation where the nature of the processing means that it
would be impossible for service providers (processors) to give controllers ‘assistance’
with data subjects’ requests – beyond implementing measures to give controllers
the technical ability to find, retrieve, edit and delete the personal data they
process in-cloud using a provider’s service, so that controllers can meet data
subjects’ requests directly
themselves. This technical ability is commonly provided with cloud (eg
automatic indexing for searching), which is self-service in nature, and it
would have been helpful had the draft noted this explicitly. Indeed, controllers
normally do not want processors who are approached by data subjects to respond
to individuals, but want (and often contractually require) the processor to
pass on all requests to the controller to deal with.

Similarly, with commodity IaaS the nature of the processing
and information available to the processor are such that IaaS/PaaS providers
should not be expected to do more than provide reasonably adequate information
about their services and security etc. This could include information about any
security codes/certifications and any DPIA undertaken by the provider regarding
its own systems/processes, so that a controller can take those into account in
assessing whether a cloud service meets the controller’s own security and risk
requirements and (where necessary) in conducting its own DPIA. It would be
impossible for providers of standardised, commoditised cloud services to tailor
their security measures to the individual requirements of every single one of
its thousands, even millions, of controller customers, and data protection
authorities, eg Scandinavian cloud decisions have recognised that
industry-standard security certifications can credibly assist compliance and
verification of compliance.[1]

Also, there is nothing in the GDPR that prohibits processors
from charging reasonable fees for their extra work in providing any required
assistance or information (or for undergoing customer audits), and this point should
be made explicit. If processors are not allowed to charge for the extra assistance
etc, they are likely to raise their prices, perhaps even generally for all
customers, so being permitted to levy fees for any extra ‘assistance’ work etc seems
the fairest approach.

Processors and sub-processors
– role and use

Article 28(2) requires processors to inform the controller
of intended changes in sub-processors, ‘thereby giving the controller the
opportunity to object to such changes’. It must be right that giving the
controller a contractual right to terminate if it objects to a change should be
sufficient for compliance here, particularly with hyperscale commoditised
services like cloud, where surely one single customer should not be able to
dictate the cloud provider’s business operations. If the GDPR intended that a
controller could block a change, surely it would have said so explicitly.

Article 28 refers to a sub-processor as ‘another processor’.
A processor can use many subcontractors when providing its processing service. I’ve
argued in my recent book
and web
update (regarding the Bavarian
DPA’s approach) that a subcontractor should not be considered a sub-processor
of personal data, ie ‘another processor’, unless it actually has access to
personal data and intends to access personal data. Not all subcontractors have
logical access to intelligible data. Logical access is what should matter. It
needs to be clarified that a subcontractor should not be considered ‘another
processor’ under Article 28 unless it has access to intelligible personal data,
and more than just incidental access for maintenance purposes (as per Bavaria).
Indeed, arguably even a service provider should not be considered a ‘processor’
if it has no logical access to intelligible personal data.

There’s another issue regarding sub-processors. The phrase ‘another
processor’ suggests that a sub-processor of the processor could be regarded as
a ‘processor’ in its own right. In a throwaway sentence under the heading ‘Who
is liable if a sub-processor is used?’ (p. 24), the draft ICO guidance blithely
states: ‘The sub-processor has the same direct responsibilities and liabilities
under the GDPR as the original processor has’. Let’s read that again. The same direct responsibilities under the GDPR?!
Take head out of hands and think for a moment. If a sub-processor truly was directly responsible as a processor
under the GDPR, wouldn’t that include obligations under Article 28 itself,
meaning that a controller would have to enter into a direct Article 28-compliant contract with every single one of its
processor’s sub-processors, and each sub-processor would be directly exposed to
fines for infringement etc? That can’t be right. If it were then the ‘flowdown’
to sub-processors of the mandatory controller-processor contractual terms required
by Article 28(4) would be unnecessary, because sub-processors would be directly
liable to controllers under their direct contracts. So I hope the red pencil will
be wielded there, or at least that the ICO clarifies what it meant by that
sentence.

Further on flowdown, several key questions were left
unanswered by the ICO’s draft guidance. First, when must obligations be flowed
down to sub-processors? Article 28(4) requires flowdown when a processor ‘engages
another processor for carrying out specific processing activities on behalf of
the controller’. What are ‘specific processing activities’ in this context –
bespoke processing tailored for the controller along the lines of traditional
outsourcing, so that the flowdown obligation doesn’t apply to commoditised
infrastructure cloud? Second, exactly what obligations must flow down? Must all
sub-processors assume direct obligations to the controller as third-party
beneficiary, or is it enough that they assume contractual obligations to their
immediate higher-level processor, which will enable the controller’s contractual
rights to flow down the chain? First, how far down the chain must the flowdown go
(assuming, which isn’t guaranteed to be the case, that the following qualify as
‘another processor’)? Third-party datacentre operator? Network/communications provider?
Payment services sub-provider? Again, surely the contractual obligations should
need to flow down only to sub-contractors who have access to intelligible
personal data, and should relate only to the personal data to which they have
access? For example, a payment services provider may have access to payment
data, but not necessarily other personal data, while a datacentre operator may
have no access to the personal data stored using its facilities, while datacentre
operators and indeed network connectivity providers may argue that they are not
even ‘processors’.

Some sub-processors are individuals, eg for support
services. Do all the Article 28 contractual obligations have to be imposed on
them too? Again, they may not have intelligible access to all or even some of
the controller’s personal data.

Liability and compensation

Article 82(1) states that ‘any person’ who has suffered
material or non-material damage can sue for compensation. So does Recital 146.
Clearly, the legislative objective is to ensure data subjects will receive ‘full
and effective’ compensation from whatever source. But the wording refers to ‘any
person’, not ‘data subjects’. Does this mean that a processor could sue the
controller or sub-processor, and similarly that a sub-processor could sue the
controller or processor, under Article 82(1) if it has suffered damage (eg
compensation claim, reputational damage) due to an infringement by the
controller or another processor?

Similarly, it seems that data subjects can choose to sue
anyone in the supply chain that they wish, including ‘another processor’, ie
even a sub-processor far down the chain (Article 82, particularly 82(4) and
given Article 28’s reference to ‘another processor’, suggests this). Many are
proceeding on the assumption that this is a real risk. Again, the ICO could
clarify its view on this issue.

Article 29 says the ‘processor and any person acting under
the authority of the controller or of the processor, who has access to personal
data, shall not process those data except on instructions from the controller,
unless required to do so by Union or Member State law’. It is broad and seems
to extend to ‘any person… who has access to personal data’. However, Article 83(4)(a)
refers only to the obligations of ‘the controller and the processor’. Surely
Article 29 should not expose any persons other than controllers and processors
to administrative fines under Article 83(4)? (And presumably there is no
particular reason why Article 29 is almost identical to Article 32(4) on
security?)

Miscellaneous

The ICO draft guidance says nothing about joint controllers (covered
under Article 26). Like its predecessor, the Data Protection Directive, the
GDPR does not cover ‘controllers in common’, which is a concept
under current UK law. Will this concept continue in the UK, or not? If so,
how should controllers in common comply with Article 26? Do they have to be
treated as joint controllers for Article 26 purposes, can one controller in common
be sued for compensation under Article 82 for another controller in common’s
actions, etc? The draft guidance is silent here.

Other uncertainties

There are many other uncertainties regarding controllers,
processors and liability.[2]
For example, Article 28(3) requires that ‘[p]rocessing by a processor shall be
governed by a contract or other legal act under Union or Member State law…’. I admit
to having thought initially that ‘other’, in ‘other legal act’, suggested that ‘Union
or Member State law’ must apply to ‘a contract’ as well as to a ‘legal act’. That
phrasing is clearly ambiguous on its face. If it applies to contracts also,
that would be very impracticable, but when did that ever stop the GDPR? I spent
a morning recently going through the travaux preparatoires and concluded that ‘Union
or Member State law’ applies only to the ‘legal act’ – so the contract itself may
be under any applicable law. I won’t inflict
the full sequence of events and changes on readers here, but the ‘under Union
or Member State law’ wording was introduced by the Greek Presidency in June
2014 (10615/2014), and does seem to
relate only to ‘legal act’, not contract (12267/14).

There are also inconsistencies. Article 82(3) exempts a
controller or processor from liability on proving ‘it is not in any way
responsible for the event giving rise to the damage’. But Recital 146 refers to
proving that ‘it is not in any way responsible for the damage’. Responsibility
for an event, causally, and responsibility for the damage, are strictly quite different things. A processor may have
some ‘responsibility’ for the event if its service/system was used by the
controller, but it may not be responsible for damage caused by the controller’s
misuse or erroneous/misconceived use of the service/system (especially in
cloud). Article 82 would override the Recital 146, but this example illustrates
the uncertainties in the GDPR.

Last but not least, a separate second subparagraph of Article
28(3) provides that ‘[w]ith regard to point (h) of the first subparagraph, the
processor shall immediately inform the controller if, in its opinion, an
instruction infringes this Regulation or other Union or Member State data
protection provisions’.
The first phrase (‘[w]ith regard to point (h) of the first subparagraph’) seems
to be a mistake, possibly arising from a formatting confusion (see below). The
draft ICO guidance (p 16, footnote 1) assumes that there was a typographical
error and that it should state ‘[w]ith regard to point (h) of the third
subparagraph’ – ie Article 28.3(h). However, ‘the first subparagraph’ is
correct, in that Article 28(3) has two subparagraphs, the first ending with
(h), and the second starting ‘[w]ith regard to point (h)…’, so that, as a
cross-reference the GDPR’s wording, is correct.

But, as something that makes sense, that wording is not
necessarily correct, as another fun morning spent with the travaux
preparatoires showed. Attention to indentation matters![3] 

The result of a sequence of changes (and
indenting/outdenting), in the course of the passage of the GDPR, is that it is unclear
whether the obligation to ‘immediately inform’ is a statutory obligation on the
processor (rather than just one of the many contractual obligations that must
be included in the processor agreement). However, one positive clarification
here is that the ICO’s draft guidance seems to have come down on the side of
the ‘inform the controller’ obligation having to be a contractual term as part
of point (h), rather than a separate statutory obligation (p 16).

Nevertheless, the fact remains that this subparagraph makes
little sense in the context of (h) (cf. 9788/15,
where it was a clear separate stand-alone obligation, which I had previously criticised
as such). Point (h) is about the processor providing information. It is not
about the controller’s instructions to the processor (unless the instruction is
to provide information?). Also surely this obligation should not require
processors to incur costs in taking legal advice on data protection laws in the
EU and all Member States where the controller and/or processor operates
whenever the controller gives the processor any ‘instructions’, ie effectively
require processors to provide legal advice to their controllers? If so, why
can’t they charge controllers for such legal costs incurred? Surely it should
be for the controller to consider the legality of their ‘instructions’ to
processors? Can a processor decide to form no opinion on such instructions? Can
it contractually require its controllers to promise only to give it lawful
instructions?

Conclusion

In summary, the draft does not provide much guidance on most
of the practical difficulties with Articles 28 and 82, and I hope the
final guidance will at least deal with some of the issues which I raised
above. 

 This article is written by Dr W Kuan Hon (a Director at Fieldfisher)  in a purely personal capacity and does not
necessarily represent the views of any organisastion with whom she may be associated. Licensed under CC BY 2.0 UK.