Things will inevitably go wrong at some point, and when they do: cue the buck-passing between counterparties. To justify low liability caps in contractual negotiations with controllers, processors are often quick to point out that they have their own independent GDPR obligations – including on security. They reason: “if it’s our bad, then we’ll get fined – not you”.  That reasoning, however, glosses over the fact that processors aren’t just required to ensure their own security – they have to assist controllers with theirs too.  But to date, data breach fines coming through from the UK and Ireland have only targeted and sanctioned data controllers, even where their vendors allegedly shared some of the blame.  Those fines remind us that the controller’s head is always on the regulatory block. A recent CNIL fine is something of an outlier because this time its processor’s was too.

The CNIL fined both a controller and its processor €150,000 and €75,000 respectively for failing to put in place appropriate measures to prevent credential stuffing attacks on the controller’s website.  Credential stuffing involves attackers exploiting people’s tendency to reuse username and password combinations by fraudulently obtaining valid combinations for one site and then using them across other sites to attempt access to accounts.

The investigation was prompted by the CNIL’s receipt of dozens of ‘data breach notifications’ related to an unidentified online retailer from which several million customers regularly make purchases.  It’s not clear whether these were formal notifications by the controller under Article 33 GDPR, or affected data subjects ‘notifying’ by submitting complaints. This lack of clarity is because the CNIL’s formal decision was not publicised – instead only a summary was released (and needed translating).  

It’s also worth noting that unlike in the UK where the ICO will name and shame recipients of fines (thereby causing them reputational damage), many EU regulators such as the CNIL adopt an arguably more proportionate approach and may elect not to identify them – this being one such case. The CNIL was clear that the fines were publicised solely to raise awareness of credential stuffing.

The CNIL discovered that the website in question had suffered numerous waves of credential stuffing attacks resulting in attackers being able to access account information of some 40,000 customers between March 2018 and February 2019. Customer information accessed comprised surname, first name, email address, date of birth, loyalty card number and balance, as well as order information.  

It found that both the controller and its processor breached their security obligations under Article 32 GDPR because they were slow to put in place effective measures to prevent these repeated attacks. Their strategy was to spend a year developing a tool to detect and block them, despite the fact that other measures existed such as rate limiting and using a CAPTCHA which the CNIL opined might have had a more immediate effect.

In support of its decision to impose two separate fines against the controller and processor in relation to their respective liabilities, the CNIL stressed that the controller must decide on the implementation of measures and give documented instructions to its processor, but that the processor must also seek the most appropriate technical and organisational measures to ensure the security of personal data and propose them to the controller. 

The CNIL’s decision that it takes two to tango when it comes to security makes sense: whilst controllers ultimately call the shots, they very often rely on the expertise of their processors.  Indeed, the EDPB’s recent Guidelines 07/2020  acknowledge that controllers may only describe the minimum security objectives to be achieved and ask their processors to propose specific security measures to be implemented.

Either way, unlike compensation claims where liability can be apportioned differently if a controller (or a processor for that matter) can show that they weren’t in any way responsible for the event giving rise to the damage, Article 24 GDPR is clear that the controller is always going to be responsible for matters such as the security of any processing. And whilst Anglophone regulators haven’t so far had the inclination to implicate (let alone sanction) processors for their parts in their controllers’ security failings, these are still relatively early days of the GDPR – the CNIL’s approach is perhaps a sign of things to come by treating controllers and processors like they’re in it together.