Companies that fall victim to a cyber attack are not always “at fault”.

The attacker might use a (previously unknown) “zero-day” vulnerability. More commonly, they might attack a company’s IT suppliers to exploit their access to the company’s systems or data.

Despite the huge growth in digital supply chain attacks, there is (within the UK at least) little authority on who is liable in this situation. For example, what obligations might the supplier have breached? What losses has the company suffered and can they be recovered from the supplier?

We consider the lessons to be learnt from the recent claim by a recruitment company (Morgan Hunt) against its IT supplier (Greenham IT) and provide practical tips for managing your supply chain.  

Don’t include credentials in your source code on a public GitHub repository…

The Particulars of Claim state that Morgan Hunt engaged Greenham IT to migrate client and candidate data from its existing CRM to a new Mercury CRM system.

The code for this project was stored on GitHub, a popular cloud-based tool used for software development and version control. The GitHub repository was set up so some of the code was public (i.e. visible to everyone) and some of it was private.

Greenham IT developed new code to transfer data to the new CRM. Unfortunately:

• the code was uploaded to the public part of the repository and so was visible to everyone, and
• the code contained the access credentials to both the old and new CRM. In other words, the code included the “passwords” for the old and new systems to allow the programme to access them to extract data from the former and load it into the latter. 

Morgan Hunt subsequently received emails from a threat actor who claimed to have exfiltrated customer and client data from its systems. Morgan Hunt notified the Information Commissioner and 96,152 affected data subjects. It is not clear if the threat actor asked for, or received, a ransom payment.

Potential breaches

Morgan Hunt alleges Greenham IT is responsible for the security breach and is liable for a mixture of contractual and tortious claims. In summary:

• Confidentiality: Morgan Hunt claims this is a breach of a contractual obligation not to “disclose or communicate” confidential information and to use “best endeavours to prevent the unauthorised publication or misuse of any confidential information” (Clause 6). This claim is interesting as confidentiality breaches typically arise from intentional misuse. They do not generally apply to inadvertent or negligent disclosure (Warren v DSG Retail Ltd [2021] EWHC 2168). The access of personal information by the attacker would ordinarily be unlikely a breach of confidence as a result; the position may be different in relation to the active use by Greenham IT of the login credentials, by placing them in a public GitHub. In any event, there is nothing to stop the parties contractually agreeing broader obligations, as appears to be the case here.
• Contractual obligation to use reasonable skill and care: Greenham IT is also said to be in breach of its contractual obligation to “render the Services to the best of [sic] ability and skill” (Clause 1.1) and the implied obligation to use reasonable skill and care under section 13 of the Supply of Goods and Services Act 1982. Again, this is interesting. There is, so far as we are aware, no decided case on whether the obligation to use reasonable skill and care extends to taking adequate cyber security measures – though it seems highly likely it would.
• Negligence: Finally, there is a claim in tort for negligence. A controller does not normally have a duty of care to data subjects in relation to data protection matters (because the bespoke regime under the UK GDPR displaces any duty in negligence, Warren v DSG Retail Ltd [2021] EWHC 2168). However, the position between controller and processor is undecided. This is likely to be decided using general principles by reference to the exact nature and scope of the duties undertaken by Greenham IT (Robinson v P.E. Jones (Contractors) Limited [2011] EWCA Civ 9).

Whether Greenham is in breach, and whether that breach caused the attack, depends on the facts. The summary set out above is taken from Morgan Hunt’s Particulars of Claim. Greenham IT may strongly contest them in its Defence.

However, it’s clearly bad practice to hard code unprotected access credentials into source code (assuming that is what happened here) and the post-incident report created by Greenham IT reportedly admits it was an error to make the code publicly accessible on GitHub. The report is said to conclude it was “overwhelmingly likely” exposing these credentials led to the cyber attack.

Heads of loss

The Particulars of Claim list five heads of loss:

• Investigation costs: This includes both internal staff and management time, as well as the cost of external consultants.
• ICO engagement costs: This includes both internal staff and management time, as well as external legal fees to deal with the notification to, and engagement with, the Information Commissioner.
• Notification of data subjects: This includes the costs of a PR consultant, legal fees and the provision of credit monitoring services, as well as internal staff and management time. It does not include the logistical costs of the notification, though if this was done by email those costs might be minimal.
• ICO fines: No fine appears to have been issued as yet, but this potential liability forms part of the claim.
• Civil claims: In relation to any civil claims from data subjects, the claim covers legal fees, internal staff and management and any final settlement.

No figure is given for the total exposure and, reflecting the fact these liabilities are likely to change over time, Morgan Hunt simply seeks declaration that Greenham IT is obliged to reimburse it for these heads of loss.

However, they are likely to be substantial and the bulk of the claim is likely to be “ancillary” costs, i.e. investigation costs and professional fees. (For the reasons set out below, fines and civil claims are likely to be limited.) This is relevant when drafting data protection and security clauses.

Finally, there is no claim for a ransom payment. Possibly no ransom was asked for, or no ransom was paid, or no one wants to admit making a payment. However, a ransom payment would, arguably, be recoverable either as a direct consequence of the breach or, more likely, as mitigation costs, subject to any public policy limitations (Patel v Mirza [2016] UKSC 42). This will have to wait for a future case.

GDPR fines – A “selection and supervision” duty?

As set out above, it is unlikely that Morgan Hunt will be subject to a significant fine under the UK GDPR and, even if it was, those fines could be recovered from Greenham IT. Why is that?

• “Selection and supervision duty”: The starting point is the security duties placed on controllers and processors* are likely to be quite different. The processor is directly responsible for implementing appropriate technical and organisational measures to protect personal data (Article 32, UK GDPR). However, the duty on a controller is likely to instead be to select a processor that can guarantee compliance with the GDPR, ensure appropriate processing clauses are in place and to supervise the processor’s performance (Article 28, UK GDPR). So long as the controller discharges this “selection and supervision duty” it should not be liable if the processor has, in fact, failed to use appropriate technical and organisational measures (see Scottish Borders Council v Information Commissioner [2013] UKFTT EA_2012_0212)
• Direct enforcement: The Information Commissioner can just fine Greenham IT directly as, under the UK GDPR, processors have directly regulatory liability for a failure to use appropriate security measures. If, as alleged in the Particulars of Claim, this is all Greenham IT’s “fault”, the Information Commissioner can go straight to the source of the problem. (For completeness, the position is more complex where a processor is outside the UK.)
• Actual risk of enforcement: Finally, regardless of “fault”, the risk of a fine is not great. Around 12,000 personal data breaches are notified to the Information Commissioner each year and only a handful result in formal enforcement action. Added to that, the Information Commissioner is increasingly using reprimands (which involves no financial penalty) as a sanction. For example, another (unnamed) recruitment company recently only received a reprimand for exposing the details of 12,000 data subjects in an open bucket (here).

Putting this together, even if a fine were imposed on Morgan Hunt, it would likely be for either wrongly selecting Greenham IT or not properly supervising them – neither is caused by the actual breach and so recoverable from Greenham IT.

(* This assumes that there is a controller/processor relationship between Morgan Hunt and Greenham IT. In practice, their contract does not explicitly state this is a controller/processor relationship, nor does it contain the processing clauses required under Article 28, UK GDPR. If the parties are joint controllers the analysis is different but may well end up at the same place.)

Civil claims – Direct flow down?

The prospect of significant liability for civil claims also seems unlikely. Data subjects cannot claim merely because there has been a breach of the UK GDPR or a “loss of control” of their personal data. Instead, they need to demonstrate they have suffered actual distress or monetary loss and that crosses a minimum threshold of seriousness (see here).

The extent to which any of this is possible will depend on the facts, including the actual data lost, the subsequent actual (or potential) use of that data and the impact on data subjects. None of this is clear on the facts but if the information is limited to high-level “CV” information this is unlikely to trigger anything worse than some speculative actions in the Small Claims Court. An exception might be data subjects whose DBS (criminal record) details were disclosed as this could be sensitive in some cases.

Even if those claims were made, they could be directly against Greenham IT (given the uncertainty as to whether Morgan Hunt is even in breach of the UK GDPR) or Greenham IT could be joined as a party to that action to allow the liability to flow down directly to them.

Post-incident reports

The contents of Greenham IT’s post-incident report is also worth noting. Where a supplier suffers a cyber incident, customers sometimes ask for a report as to what happened.

However, these reports are typically closely reviewed to make sure they properly reflect the facts and are prepared so they benefit from privilege and only the final draft is disclosable. They normally avoid explicit admissions of fault (such as it being an “error” to upload the software to the public repository) or unnecessary speculation (such as it being “overwhelmingly likely” the exposure of credentials caused the cyber attack), unless these conclusions are unavoidable.

Practical tips to manage your supply chain

The claim highlights a number of points to consider when managing your supply chain:

• Impose detailed security measures: Publishing source code on GitHub with unprotected access credentials is an obvious security breach. However, in other cases, the question of whether a supplier is in breach might be more technical and nuanced. This means you should impose detailed security obligations on the supplier to clearly set out what measures they must take to ensure adequate security (e.g. encryption, patching, EDR, IDS etc). This also helps discharge your obligations under Article 28, UK GDPR.

It is not always easy to persuade suppliers to agree to overly prescriptive security obligations and preparing contract-by-security security obligations is burdensome. Accordingly, we recommend that customers have a set of generally applicable, industry-standard, baseline security principles that can be applied to all suppliers.

• Costs and expenses are just as important as fines and civil claims: The costs and expenses of dealing with a security breach are often just as significant as any potential fines or civil claims (within the UK at least). It is important your contract allows you to recover them.

One way to do this is through an indemnity. Getting indemnity protection is always good (like free drinks) and can allow recovery of losses that are not the result of a breach of contract. However, it is not clear this is strictly necessary in all cases. These losses may be equally recoverable in a straight contract claim as a direct consequence of the breach or mitigation cost.

If data protection/information security claims are capped, the costs and expenses arising out of a breach should be considered when setting that cap.

• Selection and supervision: Finally, you should have robust measures to only select suppliers with adequate security measures and to ensure those security measures are properly applied throughout the life of the contract. This should be based on a suitable prioritisation matrix so that high risk suppliers are subject to detailed review (with less risky suppliers subject to proportionately less detailed review). Importantly, these measures should be properly implemented and clearly documented

A robust selection and supervision regime should help you avoid liability if your supplier suffers a security breach or, better, ensure you only use suppliers that are less likely to suffer a breach in the first place.

The Particulars of Claim are here.

For more on managing cyber security risks see our Cyber Security Handbook - The Essential Handbook for In-house Counsel.