This article aims to consider the implications of this decision, for both processors and controllers of personal data, and considers whether this decision marks the start of a shift in the enforcement landscape for processors or whether it should be viewed in a narrower context.

The Advanced fine

Advanced provides IT and software services to organisations on a national scale, including various NHS Trusts and other healthcare providers. In August 2022 Advanced was hit by a ransomware attack, which impacted the personal information of 82,946 people and resulted in disruption to critical services, such as NHS 111.

Following investigation, the ICO issued a Notice of Intent confirming Advanced's breach of Article 32 of the UK GDPR for failing to implement appropriate technical and organisational measures to ensure the security of personal data. This is an overarching obligation which requires the processor to assess and mitigate risks, which according to the ICO includes regularly checking for vulnerabilities, implementing multi-factor authentication and keeping systems up to date with the latest security patches. The absence of multi-factor authentication in particular on a customer account is alleged to have led to the attack and the resulting data breach on Advanced's systems.

We must note that following the issue of the Notice of Intent, which gives details of the provisional findings and reasons, Advanced has the opportunity to submit representations to the ICO. These representations are taken into account before deciding whether to issue the organisation with a final monetary penalty notice or enforcement notice. A period of six months from the NOI being issued to the final decision being made is permitted.

A processor's obligations under data protection law and scope for fines and other penalties

Under the UK GDPR a controller determines how and why the data is used by a processor, whilst a processor is required to act only under the controller's instructions. However, data processors have their own obligations under the Act, which include that they should:

• Only process personal data under a binding contract and in accordance with a controller's instructions, unless otherwise required by law.
• Implement appropriate technical and organisational measures to ensure the security of personal data, including protecting against accidental or unlawful destruction or loss, alteration, unauthorised disclosure or access.
• Undertake appropriate due diligence in respect of any sub-processor that you permit to process the personal data, and only allow such processing with the controller’s prior specific or general written authorisation. Any appointment of a sub-processor must be in the form of a contract that offers an equivalent level of protection for the data as that provided for in the contract between the controller and processor.
• Notify the controller of a personal data breach and assist the controller to comply with its obligations to report and notify the ICO/affected data subjects following a breach.

When the UK GDPR was first introduced into UK law, there was concern among many processors, such as software vendors, about the sudden imposition of direct statutory obligations on processors, something which had not been present under the Data Protection Act1998. This concern seemingly reduced somewhat when it became increasingly apparent after May 2018, that the initial GDPR breach-related fines, in the UK at least, [i] were in practice, directed at controllers rather than processors following data breaches. This was despite such data breaches seemingly being caused by the controllers' third party software vendors i.e. their processors, and was presumably down to the ICO holding the affected controllers ultimately responsible for the acts and omissions of their processors. This trend persisted in the years following May 2018 and influenced the position adopted in many negotiations between controllers and processors regarding liability for data breaches. However, despite this seeming reluctance to fine processors, the ICO never formally waived its powers to investigate and issue corrective fines and other penalties to processors, nor did it declare them effectively off the hook. Therefore, the Advanced decision is notable as a first of its kind, and raises various questions.

Does this mean a change in the enforcement landscape for processors?

The short answer is …maybe – but it is just too early to be sure and we will need to see if this is the first of many such decisions. Again, further representations will be taken into account before a final monetary penalty notice is issued. Ultimately this provisional decision throws up more questions than it answers. One of these questions is whether this decision is symptomatic of the ICO's explicit reluctance to issue fines to public bodies (see our previous article here). Or whether, given the specific nature of Advanced's failure to implement appropriate technical and organisational measures, is it simply that this was in reality a breach which was sufficiently outside the control of the affected controller, and something that they could not have realistically prevented, despite conducting thorough due diligence and oversight on their processor (if so, this would definitely mark a change in the ICO's approach, since they have historically held the controller ultimately accountable for the security failures of their processors)?

To answer this question fully we will need to see and analyse further examples of targeted processor fines by the ICO and read accompanying commentary from the regulator, explaining the rationale behind any shift. What would be particularly interesting is if the next fine we see is in the context of a private sector controller and private sector processor, or if not, an express acknowledgement by the ICO that it is taking a harsher line on processors who deliver software and services to the public sector only.

So what are the implications of this decision - if any?

Given that the ICO decision does not deliver a distinct precedent, due to the reasons given above, it is not clear where this leaves those acting in their respective roles as controllers and processors of personal data. However, it has undoubtedly created a renewed focus and raised potential concerns for processors, reminding them of the importance of things like multi factor authentication.

If we are going to start seeing processor fines on a regular basis, potentially tipping over into the private sector sphere too, we can expect to see ripples of change in the ways that controllers and processors approach contract negotiations over data protection related liability, potentially involving increasingly nuanced liability and indemnity drafting, which address breaches caused by both parties' acts or omissions. We'd also expect to see a shift in how processors look to document their own compliance with the UK GDPR, including a change in the level of due diligence required by a processor before they decide to appoint (and consequently accept liability for) the sub-processors in their supply chain.

Equally however, if the ICO doesn’t follow up this decision with further processor fines, then processors (at any rate those that do not provide services to public bodies) may consider this decision as a one-off, triggered by the specific nature of the breach and something therefore that does not present as a risk in practice. For processors delivering IT systems to the NHS, this is something of a worrying wake-up call, requiring them to revisit their standard negotiating position around contractual liability.

What there is no doubt about is that institutional data processors who process large volumes of sensitive client data will be watching this space very carefully over the next few months and years. We look forward to seeing what the ICO does next and will be issuing further articles on this topic as soon as further developments occur.

[i] There are several examples of EU regulators, including the CNIL and Cypriot data protection regulator, using their powers under the GDPR to pursue both controllers and processors in connection with the same data breach.