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