On 1 August we reported on the launch of the International Regulatory Strategy Group’s “Article 28 GDPR ready contractual terms” for use between controllers and processors. The ICO has now launched its draft guidance on this subject. The purpose of the ICO guidance is to explain, in an accessible fashion, the core requirements that all contracts will need to have in place by 25 May 2018. The guidance consists of the relevant provisions of the Regulation, together with a commentary setting out the rationale for these and how they apply in practice. The guidance does not set out to address every issue that will arise in drafting GDPR ready provisions in a contract. Nonetheless, having the ICO’s position set out in one simple explanatory document, with a checklist, will undoubtedly prove useful to those negotiating commercial contracts.

Points to note
We have set out below the more interesting points the guidance makes, and our comments on these (in italics):

• Whether the need to comply with Article 28 amounts to a “big change” will depend on how any business’s contracts currently deal with data protection. This is of course correct, although in our view almost all contracts will need to incorporate new data protection provisions. For many organisations this is a significant task, compounded by the fact that with the increased risk of fines and sanctions customers and vendors are applying much greater scrutiny to processor terms and the allocation of liability.

• Whilst the GDPR allows for standard contractual clauses to be drafted by EU Commission or a supervisory authority (i.e. the ICO) to be used in contracts to meet the relevant GDPR processor terms requirements, none have been drafted so far. There is no certainty when these example clauses will be published and in the meantime organisations will need to develop their own processor terms. The IRSG example terms will be a useful reference point given the current vacuum of guidance.

• Controllers and processors are free to introduce other terms over and above the minimum set out in Article 28. In practice, it is these additional terms that will be the main focal point of contract negotiations. Common “gold plating” in processor terms include adding compliance with laws obligations; restrictions on the ability to audit; procedures for objections to new sub-processors; specific security controls and, of course, liability and indemnity discussions.

• When documenting in the contract the scope and extent of permitted processing, the guidance states that the parties cannot use “very general or ‘catch-all’ contract terms”. The question of how granular processing descriptions have to be is a common area of uncertainty for organisations working on re-papering exercises. The draft ICO guidance is not particularly illuminating on this point and it is hoped that this is an area which could be clarified further in the final guidance. Given the practical challenges (and limited obvious benefits) in agreeing detailed contract descriptions for arrangements involving routine processing of data on a routine / low risk basis.

• Controllers may only use processors providing “sufficient guarantees” to implement technical and organisational measures so that the requirements of GDPR will be met and the rights of data subjects will be protected. The guidance does not provide any further commentary on what (if anything) might be expected to be contained in a contract on this point, beyond stating that future codes of conduct or certification schemes may evolve, adherence to which would help satisfy this requirement.

• The obligation on a processor to assist a controller to meet its obligations to data subjects under Chapter III of the GDPR by having in place appropriate technical and organisational measures reflect the realities that processor’s “co-operation in helping data subjects to exercise their rights will be essential”. It should be noted that the technical and organisational measures designed with Chapter III in mind will likely be different to those designed to meet the security requirements of Article 32, and the contract may benefit from specifically dealing with this distinction.

• The requirement on the processor to notify the controller where it believes a controller has issued an instruction which infringes GDPR is implied by the guidance to be a general one, rather than being linked specifically to the information and audit provisions referenced in Article 28(3)(h). This is a point which is unclear in the Regulations, and we look forward to this point being further clarified in the final guidance.

• While only the processor obligations referred to in Article 28(3) require to be expressly set out in the contract, it is good practice to ensure the processor understands that it has a number of other direct obligations, and this may be done by including them in the contract. This guidance may prompt a greater number of contracts to spell out the processor’s obligations in full for reasons of certainty and clarity.

• The processor will only be liable under GDPR (as opposed to any contractual liability) where it has itself been in breach of its specific obligations under the Regulations or acted outside the lawful instructions of the controller. At present many processors are concerned they will have direct obligations from breaches of fair processing by the controller, and so this clarification is a helpful reminder of the true position.

• The controller is fully liable for non-compliant processing unless they were “not in any way responsible for the event giving rise to the damage” – although the controller may be able to claim back all or part of the damages or compensation paid from the processor. This reflects, in part, Article 82, but leaves open the question of whether contractual limits of liability and indemnities which the parties may negotiate to allocate cost and risks arising from a breach of processor terms will be enforceable, particularly where administrative fines have been imposed. The answer will vary depending on the applicable law of the contract and is not always clear cut.

• Any sub-processor contract “should impose on the sub-processor the same legal obligations the processor itself owes to the controller”. There is ambiguity around the phrase “same data protection obligations”, which could mean incorporating the requirements set out in Article 28(3)(a) to (h) inclusive, however as the guidance does not specifically mention Article 28(4), it could in fact go even further and require processors to flow down gold plating obligations that have been agreed in the principal agreement. Although this is consistent with a literal reading of Article 28(4) it is likely to be impractical for organisations with complicated extended supply chains, particularly where for example the “prime” processor terms are negotiated slightly differently by a vendor with each customer. A risk based approach – requiring sub-processor terms to offer “at least the same level of protection” or similar would ensure protection for data subjects on the one hand and allow for a more flexible approach with sub-contractors on the other. It would be helpful if the final guidance allowed some flexibility here.

• Further guidance will be issued shortly on matters covered by Articles 30(2) (Records of processing Activities), 32 (Security of Processing), 33 (Notification of a personal data breach), 34 (Communication of a personal data breach), 35 (Data Protection Impact Assessment), 36 (Prior consultation), 37 (Designation of the data protection officer) and 82 (Right to compensation and liability). These will all provide further detail to supplement the information in this current guidance.