GDPR: CJEU finds that a controller can be liable for its processors' wrongdoing

The judgment was notable for a number of interpretations made under the EU GDPR regarding the relationship between the parties and allocating liability for regulatory breaches, including:

• Establishing the scope of controllership and criteria for joint controllership;
• Confirming that controllers would only be fined where they have committed wrongdoing e.g. intentionally or negligently infringed the GDPR; and
• Establishing that a controller can be liable for its processors' wrongdoing (unless the processor acts outside of its instructions from the controller).

For the purposes of this article we are focusing in particular on the final point, which is likely to be of interest to organisations involved in negotiating data protection clauses (and accompanying liability and indemnity provisions), especially in transactional IT projects featuring contracts between controllers and processors. Whilst it is an EU GDPR based judgement made by a European court, it will nonetheless be relevant to UK based parties as it could be an approach also applied by a UK court when interpreting the same questions under the UK GDPR, notwithstanding the recent changes to the status of EU law in the UK which took effect on 1 January 2024 (through the Retained EU Law (Revocation and Reform) Act 2023 – which we will cover in a subsequent article).

This point around the controller being responsible for the wrongdoing of its processors is something which on the face of it, has the potential to undermine a now often cited feature of the GDPR (compared to the DPA 1998 and EU data protection directive on which it was based) that a processor is directly liable to the regulator and data subjects for breaches which they commit.

In our experience, since the introduction of the GDPR, contract negotiations between controllers and processors regarding liability and indemnity clauses for data protection breaches are typically the subject of intense negotiation and focus.

A processor will often argue that there is no need for such an indemnity, as under the UK GDPR, a processor would be directly liable to the regulator for breaches which they commit, so the controller shouldn’t have to worry about being fined as the ICO should go after the processor directly. Similarly, Article 82(2), which is more about liability for paying compensation to data subjects, confirms that "A processor shall be liable for the damage caused by processing only where it has not complied with obligations of this Regulation specifically directed to processors or where it has acted outside or contrary to lawful instructions of the controller".

However, in practice, we have seen barely any enforcement action taken by UK/EU regulators directly against processors since May 2018, despite for example various high profile IT system related breaches seemingly caused by an IT supplier's security failure – instead the controller is typically held accountable for regulatory breaches which happen on its watch, even if it doesn’t directly commit such a breach (this seems commensurate with recital 74 of the GDPR).

This CJEU decision therefore appears in keeping with how the regulators are taking enforcement action (particularly imposing fines) for breaches, in practice – essentially holding that the controller should be managing its processors sufficiently to prevent such breaches occurring in the first place. This therefore arguably contradicts the frequently cited arguments submitted by processors which we mention above around a controller not needing to be worried about having to recover the cost of regulatory fines which they bear following a breach by the processor. On the contrary, a controller should be very concerned!

Ultimately, our recommendation for controllers appointing processors under a contract, is to:

• Avoid the supplier going rogue in the first place – customers should ensure that proper due diligence is carried out prior to contract signature, regular audits are undertaken to verify annual compliance, coupled with ongoing routine monitoring and reporting.
  
  
• The contract should set out Article 28 compliant clauses – with a very clearly defined scope of processing activities for the processor.
  
  
• Near miss/minor breaches should be flagged to the customer, so lessons can be learned to prevent more serious events happening etc..
  
  
• If there is ultimately a serious breach committed by the supplier, despite the best efforts of the controller, the customer should ensure that the contract features an indemnity from the supplier for any data protection breaches which lead to regulatory fines (as well as wider compensation claims and other losses).
  
  
• Similarly, with liability caps, these should anticipate the controller having to potentially absorb the entire fine imposed by the regulator and needing to recover this from the processor in full – so the cap should be suitably high or even unlimited, rather than just based on a low multiple of contract value (which is what supplier's often offer by default).
  
  
• If a processor essentially goes rogue and acts outside of the controller customer's instructions then this may lead to a different outcome in terms of a regulator taking action directly against them – but in that situation, the processor has arguably at that point shifted to becoming a controller in its own right (see Article 28(10) of the UK GDPR) as it is now itself determining the purposes and means of processing.

For tech and privacy lawyers, this provides plenty of useful ammunition for contract negotiations -although it does beg the question – when would a processor actually be liable for fines to the Regulator for data security breaches (whilst remaining a processor)? Perhaps this would be limited to situations where the supplier was offering commercial off the shelf software on a one size fits all basis, with no ability for the customer to negotiate contract terms or police the supplier's compliance in practice – in that situation, a regulator could sympathise with the lack of ability for the customer to properly oversee its processor's compliance and go after the processor directly.