The Ransomware Demand
A mid-sized logistics company with £60m turnover buys a cyber policy with a £5m limit, a £50,000 retention, and cover for ransomware, business interruption and incident response. In September attackers encrypt the core warehouse management system. The company's IT provider restores from backups, but the backups are three weeks old because a scheduled job silently failed. The company pays a £700,000 ransom in cryptocurrency after the insurer's panel negotiator advises that restoration from backup is impossible for two systems. The ransom payment is made without the insurer's prior written consent, which the policy requires for ransom payments. Business interruption losses reach £1.4m. The insurer disputes the ransom and questions whether the backups issue is a failure to maintain.
1. Analyse the insurer's position on the ransom payment and the business interruption claim.
Read the worked answer
Ransom. The policy requires prior written consent for ransom payments. The company paid without it. The insurer has two routes: decline the ransom entirely for breach of the consent condition, or argue the payment was unnecessary because the panel negotiator's advice was about two systems only and the company could have restored the rest. The first is stronger on the wording but may be softened by the fact that the insurer's own panel advised that restoration was impossible for two systems - the company may argue the insurer had effectively sanctioned the payment. The outcome turns on what the panel actually said in writing and whether the consent condition is a condition precedent. Under the Insurance Act 2015, the insurer must show the breach was relevant to the loss; a consent condition for ransom is plainly relevant.
Business interruption. The £1.4m BI loss is within the limit and above the retention. The insurer's 'failure to maintain' point is a coverage argument only if the policy contains a maintenance warranty or a failure-to-follow-procedures exclusion. Most cyber policies do not exclude a failed backup job outright, but they may exclude losses attributable to the insured's failure to apply patches or maintain systems. The insurer would need to show the failed backup job was a failure of the insured's own systems rather than an inherent IT failure. Even if it succeeds, the BI loss caused by the encryption itself remains covered; only the additional loss from the three-week gap is at issue.
Conclusion. The ransom is the vulnerable item; the BI claim is largely payable subject to the retention.
2. What governance failures does this incident reveal, and what should the risk manager recommend?
Read the worked answer
The incident exposes several failures:
- Backup assurance. A scheduled job failed silently for three weeks. There was no monitoring, no alerting and no restore testing. A backup that has never been restored is an assumption, not a control.
- Consent process. The policy required prior written consent for ransom. The company paid first and argued later. The incident response plan should embed the insurer's consent step, with named contacts and a pre-agreed authority matrix.
- Panel reliance. The company relied on the panel negotiator's oral advice. It should have obtained written confirmation that restoration was impossible before paying.
- Segmentation and recovery time. Two systems could not be restored from backup at all, which suggests the recovery plan had never been tested against the real environment.
Recommendations: quarterly restore tests with documented evidence; immutable or offline backups; a ransomware playbook with insurer consent built in; a decision log for ransom payments; and a review of the policy's consent condition with the broker so the company knows exactly what it must do and by when. The risk manager should also quantify the BI exposure against the £5m limit, because a longer outage would exhaust it.