Kuan Hon offers a careful analysis and critique of the ICO draft guidance on contracts between controllers and processors
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.
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.
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?)
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.
There are many other uncertainties regarding controllers, processors and liability. 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
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!
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?
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.
 By way of minor example of another uncertainty, Article 28(6) states that the controller-processor contract standard contractual clauses adopted by the Commission or a supervisory authority may in turn be ‘part of a certification granted to the controller or processor pursuant to Articles 42 and 43’. The draft ICO guidance simply repeats this without explaining how exactly standard clauses can be ‘part of’ a certification. For example, does this provision mean that an organisation, in order to be certified, must commit to using those standard clauses?
 This wording was introduced in April 2016 after political agreement was reached on the GDPR, as a result of jurists'/linguists' review of the GDPR's text (5419/16). In June 2015, that subparagraph simply read, without referring to point (h), "The processor shall immediately inform the controller if, in his opinion, an instruction breaches this Regulation or Union or Member State data protection provisions" (9788/15). The current uncertainty seems to have started with another document of the same date (9565/15), where that subparagraph was indented further (cf. 9788/15), to the same level as point (h). Therefore, those viewing the draft text, without considering the substance fully, might be forgiven for thinking that this subparagraph related only to (h). This further indenting was preserved in later Council documents (10391/15). However, that subparagraph was then tacked on to the end of point (h), to become part of point (h) (12966/15, 14481/15, 14902/15 and 5455/16). Therefore, those reviewing the draft only minimally for the final "tidying up" version might well think that this wording related only to (h), and so added the words (which they must have thought were clarifying) "With regard to point (h) of the first subparagraph", when they split the sentence out to a different, outdented, subparagraph in 5419/16.