Series
Blogs
UK – How to sue your IT supplier following a cyber attack
UK – How to sue your IT supplier following a cyber attack
14 September 2023
Series
Blogs
14 September 2023
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.
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:
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.
Morgan Hunt alleges Greenham IT is responsible for the security breach and is liable for a mixture of contractual and tortious claims. In summary:
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.
The Particulars of Claim list five heads of loss:
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.
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?
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.)
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.
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.
The claim highlights a number of points to consider when managing your supply chain:
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.
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.
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.