The ICO’s Draft Guidance Leaves Unanswered Questions on Processor Obligation to Notify Infringing Instructions

Posted

Those of us who have been grappling with how best to approach GDPR compliance in outsourcing and other commercial contracts will be all too familiar with Article 28 of the GDPR. Article 28.3 builds on the limited obligations that existed under the existing regime but also include some significant enhancements to the minimum processor obligations to be addressed head on in the contract.

Processor’s obligation to notify infringing instructions

One requirement of Article 28.3 in particular, has provided clients and counsel alike with a degree of angst since the final draft of the GDPR was published in May 2016, and further back still for those of us who had followed the negotiations and multiple redrafts of the GDPR prior to its final publication.

The offending paragraph ‘floats’ at the end of Article 28.3’s list of contract requirements and reads:

With 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.

We say ‘floats’ because the paragraph does not appear within the Article 28.3 list and from a formatting perspective, sits in line with (but between) Article 28.3 and the following Article 28.4.

GDPR-snip

Either way, the obligation throws up a host of questions that commercial and data protection professionals (especially those acting for processors and sub-processors) will now need to consider each time they negotiate an agreement under which personal data are to be processed and also as they design and implement new service offerings.

For example:

  1. What constitutes an instruction?

a.  What level of involvement must a processor have in the processing activities and the wider service provision to be deemed to have had knowledge of the customer’s instructions?

b.  For example, in a SaaS scenario, does the obligation apply where the supplier’s systems enable certain types of processing but the customer remains in control of configuring the system?

     2.  When, and to what extent will processors be expected to have or form an opinion?

a.  To what extent will a processor be expected to interrogate and assess the basis on which the data controller customer has the right to use the personal data in question in the manner specified under the contract? Will this now form a standard part of the Supplier’s initial contractual due diligence stage?

b.  Will processors be expected to build and maintain an internal compliance and legal capability to enable it to comply with this obligation (or even outsource these capabilities to external counsel or consultancies)?

c.  If so, will this result in processors who wish to be fully compliant with Article 28 being forced to raise their prices; potentially becoming uncompetitive when compared with their less compliant peers?

d.  Even where such compliance teams are established or enhanced, how will processor organisations ‘operationalise’ these teams so that they are sufficiently integrated into the sales and delivery cycle that infringements are identified and notified?

e.  To what extent will ignorance of what is undoubtedly an expansive and complex law be a defence?

     3.  To what extent can the data processor seek to limit or exclude contractual liability for this obligation?

a.  Will separate liability caps be required? Will suppliers seek to carve out this obligation from indemnity provisions?

b.  Will additional provisions be required to enable counter-claims by a supplier? For example will it become custom and practice for suppliers to insist on specific representations and warranties and, in the context of outsourcing arrangements, specific ‘customer dependencies’, that all instructions given by the customer are themselves lawful and compliant with the GDPR?

     4.  Finally, to what extent is this obligation an insurable business risk?

Is this a contractual obligation, statutory obligation or both?

In addition to the issues outlined above, the placement of the obligation within Article 28.3 and the reference to sub-paragraph (h) is also problematic. From a plain reading of Article 28.3, it is unclear whether the paragraph is intended to exist as a stand-alone statutory obligation on the data processor or as an additional contractual obligation to be included within the data processing contract, or indeed both.

Given the placement of the paragraph and the fact that the list of contractual obligations clearly ends at sub-paragraph (h) with a full stop, it is arguable that the correct interpretation is that the paragraph was intended as a stand-alone statutory obligation and not something that had to be included in the contract (although from a controller’s perspective it would clearly be desirable to do in any event).

In other words, if the draftspersons had intended for the clause to form part of sub-paragraph (h), why wouldn’t they have simply put it there?

Finally, it is also unclear what the qualification “With regard to point (h)” means in practice.  Sub-paragraph (h) requires processors to make information necessary to demonstrate compliance with the obligations set out in Article 28 and to allow for, and contribute to, audits. It is not clear what the link is between information and audit obligations on the one hand, and instructions of the controller on the other. Does the reference to sub-paragraph (h) mean, for example, that the obligation to notify the controller of infringing instructions relates only to information requests and audits?

ICO’s draft guidance

To date, there has been little guidance on the above, with businesses left to speculate as they prepare for 25th May 2018.

However, the UK’s data protection regulator, the Information Commissioner’s Office (ICO) issued draft guidance on contracts and liabilities between controllers and processors for consultation on 13 September 2017 (the “Draft Guidance”).  The Draft Guidance sets out how the ICO interprets the GDPR, and its “general recommended approach to compliance and good practice”.

The Draft Guidance seems to have been prepared almost entirely from the point of view of data controllers (perhaps a hang-over from the necessary approach under the existing controller-specific regime) and so provides little additional guidance (at least in its draft form) from the perspective of data processors. This lack of guidance extends to addressing how processors might go about complying with the obligation to inform of infringing instructions whilst taking into account some of the issues identified above.

However, on the question of whether the obligation to inform must be addressed in the contract and on whether it is somehow limited by reference to sub-paragraph (h), the Draft Guidance does state clearly that:

Under Article 28.3(h), your contract must provide that…your processor must tell you immediately if it thinks it has been given an instruction which doesn’t comply with the GDPR, or related data protection law”.

So despite the questions of interpretation raised above, for now at least, the ICO’s position on this point seems clear: the obligation to inform is a contractual obligation and it is not limited to information and audit requests of the type referred to in sub-paragraph (h).

Hopefully, additional clarification will be forthcoming as the guidance is developed further by the ICO, or alternatively from the ICO’s EU counterparts.

Given the UK’s involvement in negotiating the GDPR throughout its draft iterations and the fact that the GDPR will effectively be adopted into UK law through the Data Protection Bill, the ICO’s guidance is undoubtedly persuasive and will likely remain so post Brexit. The ICO has stated that its guidance will need to evolve to take account of future guidelines issued by relevant European authorities, as well as its experience of applying the law in practice from May 2018 and that it intends to keep the guidance under review and update it in light of relevant developments and stakeholders’ feedback.

In the meantime, controllers and processors alike will need to consider how to address this obligation in their processing agreements. Controllers will no doubt seek to include this obligation on a near word for word basis. However, processors should consider carefully what additional contractual and (just as importantly) procedural protections they need in order to mitigate the potential impacts. For example, as a minimum, processors will need to implement governance frameworks and clear reporting lines to assess communications with their controllers and have a clear policy in place to guide those individuals concerned on how to handle instructions from the controller they deem to be infringing.

Final guidance

The ICO’s consultation ended on 10th October and it has previously stated its aim is to publish the much anticipated finalised guidance before the end of the year.  We will continue to monitor developments in relation to this short but important paragraph.