Fun with Processor Clauses

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):

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.