Fun with Processor Clauses

Ed Boal reflects on his early experiences of negotiating processor clauses in anticipation of the GDPR coming into force.

It is of course far too early to establish ‘standard market practice’ when it comes to processor clauses under Article 28(3) of the GDPR. However, in the rush towards 25 May, the drafting, review and negotiation of such clauses is becoming routine and this article takes a look at some of the early patterns that are beginning to emerge from the author’s experience.

Processors taking the lead

Although Article 28(3) leaves open the question of whether entering into a binding contract as regards the processing of personal data is an obligation on the controller or processor (Article 83(4)(a) suggests it is both), the expectation has been that controllers would ultimately take the lead as part of their compliance initiatives. However, on a simple analysis of the number of enquiries and instructions received from controllers versus processors, it seems that processors are taking the lead.

For some processors, taking the lead enables them to define the allocation of responsibilities and risks and provides an opportunity to establish the most favourable commercial position on the appointment of sub-processors under Article 28(2) (see below) and on some of the areas where Article 28(3) is less prescriptive, for example, regarding the format and timescales for the return of personal data under Article 28(3)(g) and the frequency, notice periods and other conditions for audits and inspections under Article 28(3)(h). For other processors, taking the lead is more about demonstrating that they are a proactive and reliable service provider that is ahead of the game.

Appointment of sub-processors

This is where the real fun starts (if you can call it fun) and where supply chain assurance can start to break down very quickly. Article 28(2) provides two options for the appointment of sub-processors:

  • general written authorisation, subject to an obligation on the processor to inform the controller of any intended changes so that they have an ‘opportunity to object’; or
  • specific authorisation of named sub-processors to undertake discrete processing tasks.

    In practice, it seems that there is little to be gained from favouring one option over the other as the addition or replacement of other processors will invariably require the controller’s consent. However, the general written authorisation option seems to be preferred by processor as:

  • unless the controller makes a specific enquiry, the processor does not need to share a list of its sub-processors at the outset (though in practice many cloud service providers do, as seen from the examples below); and
  • it provides flexibility in the event that a controller objects to any proposed change: either the customer can pay more for the processor to maintain an existing arrangement for that controller’s benefit, or either or both parties may have a right to terminate the agreement before such change is implemented.

In terms of examples ‘in the wild’ (ie data processing clauses that can be found via a Google search - some vendors choose not to publish them):

  • Google takes the specific authorisation approach, with a separate page listing all of the Google and non-Google sub-processors authorised by the controller. Google will give 30 days’ prior notice of any changes, from which point a controller is given 90 days to terminate the agreement immediately on written notice;
  • Salesforce takes a hybrid approach: customers can request a current list of sub-processors at any time and subscribe for notifications of new sub-processors before they are authorised by Salesforce. If a customer wishes to object to any proposed changes, they have 10 business days from the date of Salesforce’s notice to do so and if Salesforce cannot agree a ‘…commercially reasonable change to Customer’s configuration or use of the Services…’, the customer can terminate the affected services (a similar approach is taken by Cloudflare, IBM and Microsoft)
  • Oracle and VMware appear to adopt the general authorisation approach, but without appearing to give controllers a right to object if any changes are proposed.

Of course, Article 28(2) does not require a processor to identify each sub-processor with a specific processing activity (the only provider mentioned above that does is Microsoft). This makes it difficult for controllers to undertake more than a superficial level of due diligence of the processing supply chain at the point of purchase/subscription, though one would expect a processor to explain the purposes of any change and related (sub-)processing activities when giving notice of any proposed changes to its customers.

Sometimes sub-processing clauses will give a controller the right to request copies of the agreements between a processor and its sub-processors, subject to the redaction of any commercially sensitive provisions. However, on one occasion in my experience, the processor refused to provide the same until the customer signed up for the service. Often therefore, the controller will have to rely on the processor’s obligation to ensure that agreements with any sub-processors reflect the GDPR’s requirements and that the processor will remain liable for the performance of its sub-processor’s obligations (Article 28(4)).

Recovery of costs and expenses

There is often negotiation over the extent to which a processor may recover its ‘reasonable costs and expenses’ for fulfilling the requirements set out in sub-paragraphs (e) to (h) (inclusive) of Article 28(3). However, some provisions tend to be more contentious than others, for example:

  • Depending on the nature of the processing, a controller may argue that the processor’s obligation to provide assistance in relation to responding to the requests of data subjects (see sub-paragraph (e)) is an intrinsic part of the service for which they should not have to pay anything further (though it is generally helpful to break down the rights laid down in Chapter III and deal with them individually where possible).
  • There is a careful balance to be struck when it comes to facilitating a controller’s compliance with its obligations under Articles 32, 33 and 34 (see sub-paragraph (f)), where the identification, mitigation and remediation of a personal data breach will require close cooperation between the controller and the processor and where the controller will feel most vulnerable. Controllers appear to be more relaxed when it comes to assistance with data protection impact assessments (Article 35) and prior consultation (Article 36).
  • Sub-paragraph (g) does not adopt the ‘commonly used electronic form’ or ‘commonly used and machine-readable format’ conventions used in relation to data subject rights. Often, controllers will ask for a complete copy of the database (as opposed to export in .csv, .xml or .xls/x formats) to enable them to transition to a replacement processor with as little fuss as possible, while processors are reluctant to provide a copy of the database to protect the database schema (essentially the designs for the database) from being plagiarised by competitors. Processors are generally wiling to achieve a compromise, subject to being able to recover their costs and agreeing a reasonable period for delivery to the controller.
  • The frequency, notice periods, and access restrictions for audits and inspections are generally limited except in specified circumstances. Parties tend to confuse the reference to audits and inspections in sub-paragraph (h) with the powers of supervisory authorities under Article 58(1)(b).

Security of processing

Article 32(1) permits a risk-based approach when it comes to ensuring the security of processing, which goes beyond ensuring that data are secure at rest and in transit to those matters listed in Article 32(1).

Most security provisions within processor clauses tend to give processors considerable latitude when it comes to determining what is ‘appropriate’ in relation to their processing tasks. While some processors (such as Google) go to commendable lengths to describe the extent of the security measures taken by them, others will generally point to some form of marketing document that lacks any real detail and controllers will often insist on minimum security measures being specified (of course where the Standard Contractual Clauses are engaged, this detail must be set out in Appendix 2).

Liability and indemnities

Most processors refer to the limitations of liability set out in their main services agreement/terms in relation to liability under the data protection clauses. Often those limitations are insufficient (limited to fees actually paid in the preceding 12 months) and/or incompatible with the processor’s obligations under the GDPR (in particular, ‘loss of or damage to data’ commonly being excluded). Some limitation clauses bizarrely attempt to apply a singular liability cap to all claims made by a controller and its affiliates in respect of all claims made by them regardless of whether they arise from the same event/personal data breach.

As anticipated, controllers either want an indemnity in respect of non-compliance with the processing clauses or, alternatively, more substantial liability caps which are often linked to the maximum sums assured under relevant insurance policies (controllers are asking more intelligent questions about ‘cyber’ cover as part of their processor due diligence, though larger processors will generally not comply with such requests). Usually the parties reach agreement on a liability cap which is somewhere between £/€/$1-5 million depending on the nature of the processing.

Ed Boal is a Senior Associate and Head of Digital Media & Technology at Gregg Latchams.

Published: 2018-01-10T17:00:00

    1 comments

    • Nice article, Ed, many thanks
      Christopher Mann, 16:21:21 15/01/2018

    This site uses cookies. By using the site you agree to our use of cookies as set out in our Privacy Policy.

    Please wait...