Supply Chain Cyber — Where Multiple Policies Interact

The defining cyber incident pattern of the 2020s is the supply chain breach. SolarWinds, Kaseya, MOVEit, Snowflake, Sisense, Okta, Synnovis, CDK Global — each was a single vendor incident that propagated across hundreds or thousands of downstream customers. For each affected business, the question of which policy responds, against whom recovery may be pursued, and how the loss aggregates across multiple insurer programmes, is materially different from a direct attack.

This spoke walks through the supply-chain cyber analysis with a worked retailer/MSP example, the contingent business interruption and system failure heads in modern cyber policies, the contractual recovery question, and the practical implications for buyers whose business runs through critical third parties.

The scenario

A multi-channel retailer with 38 stores and an e-commerce operation processes payments through a single payment service provider (PSP). The PSP also handles tokenisation, fraud screening, recurring subscription billing for the retailer’s loyalty programme, and provides the in-store EFT terminals. The retailer’s reliance on this single PSP for payment processing is total — there is no commercially viable failover within the time horizons that matter.

On a Wednesday, the PSP is hit by a sophisticated supply-chain compromise: an attacker has previously compromised an open-source code library used by the PSP and inserted a backdoor. The backdoor has been silently exfiltrating customer payment data from the PSP’s tokenisation service for the past six weeks across the PSP’s entire customer base of 1,400 UK merchants. The compromise is detected when one of the PSP’s other customers — a major airline — observes anomalous outbound traffic in their network monitoring.

The PSP takes its tokenisation and fraud-screening services offline at 14:00 Wednesday for forensic investigation. The retailer’s payment processing fails: e-commerce checkout fails, in-store EFT fails, recurring subscription charges fail. Sales drop to near-zero across all channels.

The PSP’s incident response runs across Wednesday and Thursday. The compromise scope is confirmed; the backdoor is removed; services are progressively restored across Friday and Saturday. The retailer’s payment processing is restored progressively over a 64-hour window from 14:00 Wednesday to 06:00 Saturday.

The retailer’s losses: - Direct lost revenue across the 64-hour window: approximately £1.6m (Wednesday afternoon to Saturday morning across stores, e-commerce and subscription billing). - Increased cost of working: temporary cash-handling at stores, increased staff costs, communications to customers. Approximately £180k. - Notification cost for the retailer’s customers whose payment data was processed by the PSP during the 6-week backdoor period: legal review, postal notification, credit monitoring offer. Approximately £620k. - Loyalty programme subscription processing failures triggering 38,000 cancellations and downstream lifetime-value loss estimated at £400k. - PCI assessment from the card schemes — pending; potentially £200k–£800k.

The retailer’s cyber policy is a £10m limit, modern Lloyd’s-form wording with explicit contingent BI and system failure heads.

The legal and regulatory framework

Controller/processor analysis. Under UK GDPR Articles 24 and 28, the retailer is the data controller for its customers’ personal data; the PSP is a processor under a Data Processing Agreement. Both controller and processor are jointly liable to data subjects under Article 82.

Notification obligations. The retailer (as controller) must notify the ICO within 72 hours of awareness of a personal data breach affecting its customers’ data. Awareness commences on confirmation by the PSP — typically within hours of the PSP’s own discovery. The retailer cannot rely on the PSP’s notification; the retailer has its own controller-level notification duty.

Card scheme notification. PCI DSS requires merchant notification of compromised card data through the acquiring bank within defined timelines. Where the merchant did not physically hold the data (the tokenisation service did), the merchant’s PCI exposure depends on the contractual allocation of PCI responsibility between merchant, PSP and acquirer.

Contractual recovery. The retailer has contractual rights against the PSP under the master services agreement (MSA) and the DPA. The MSA typically contains liability caps (often 12 months’ fees, sometimes excluded for data breach), liquidated damages clauses, and service credits. The DPA typically contains a direct indemnity for breach of data protection obligations.

Public-policy considerations. UK courts have generally upheld liability caps in B2B contracts subject to UCTA 1977 reasonableness tests. The Unfair Contract Terms Act 1977 schedule 2 reasonableness test applies. Watford Electronics v Sanderson [2001] EWCA Civ 317 and the line of authority confirm enforceability where the cap is commercially negotiated between sophisticated parties.

The cyber policy response — the contingent BI question

The retailer’s losses break into three categories: first-party loss to the retailer; third-party liability to the retailer’s customers; PCI assessment exposure. The cyber policy’s response to each depends on the wording.

Contingent BI / system failure head. Modern cyber policies include an explicit head responding to BI losses caused by the failure of a third party’s IT system, even where the retailer’s own systems are unaffected. The head typically:

• Triggers on failure of a “critical IT service provider” or “specified vendor” — sometimes pre-scheduled, sometimes broadly defined.
• Has its own waiting period (often longer than the main BI — 8 to 24 hours common).
• Has its own sub-limit (often £500k–£5m, lower than the main BI limit).
• Has its own period of indemnity (often shorter — 30 to 90 days).

The retailer’s £1.6m revenue loss and £180k ICW would respond under contingent BI subject to: - The PSP being a covered third party. Some wordings require pre-scheduling; modern wordings are broader. - The waiting period being met. A 64-hour outage clearly exceeds an 8 or 12-hour waiting period. - The sub-limit being adequate. A £2m sub-limit covers the loss; a £500k sub-limit does not.

First-party costs. Forensic investigation of the retailer’s own systems (to confirm the retailer has not been compromised independently); legal advice on notification; PR. These fall under the standard first-party head and are paid up to the main limit.

Third-party liability — to customers. The retailer’s customers whose data was processed by the PSP during the breach window have potential claims against the retailer (as data controller). The cyber policy’s third-party liability head responds.

PCI assessment. The cyber policy’s PCI head responds subject to its sub-limit.

Recovery against the PSP. The cyber insurer will typically subrogate against the PSP. The retailer’s MSA cap may limit recoverable amount. The cyber insurer takes the subrogation position into account in its claim handling but generally pays the underlying loss first and pursues recovery after.

The PSP’s own cyber response — and why it doesn’t help much

The PSP’s own cyber policy responds to the PSP’s costs and liabilities. The PSP’s customers (the 1,400 merchants including our retailer) are third parties to the PSP’s contract; the PSP’s third-party liability head covers their claims, but only up to the PSP’s limit.

The aggregate problem. If 1,400 merchants each suffer (on average) £400k of loss, the aggregate loss is £560m. The PSP’s cyber limit is typically £50m–£200m for a business of this scale; the per-merchant available recovery is therefore £35k–£140k on a pro-rata basis. Far less than each merchant’s actual loss.

The cap problem. Even if the PSP’s policy responds in full, the contractual cap in the MSA may limit per-merchant recovery to (for example) 12 months’ fees — a few thousand pounds for a small merchant. The cap is enforced regardless of insurance.

The economic reality. The retailer’s primary recovery route is its own cyber policy, not the PSP’s. The contractual cap and the aggregate problem mean the PSP route is a secondary, often nominal, source.

The supply-chain risk register

A practical broker exercise: map your business’s critical IT supply chain.

For each critical third party, document: - Service provided. - Failure consequence (time-to-impact, severity). - Contractual cap and indemnity position. - Provider’s known cyber posture and incident history. - Your cyber policy’s contingent BI treatment of the provider.

Typical critical third parties for a mid-market retailer: - Payment service provider. - E-commerce platform (Shopify Plus, Magento, BigCommerce, etc.). - Cloud infrastructure (AWS, Azure, GCP). - Loyalty / CRM platform. - ERP host. - WMS / inventory provider. - Marketing automation. - Telecoms / SD-WAN provider.

For each, ask: if this provider was down for 72 hours, what happens? If the answer is “operational catastrophe”, the contingent BI head must respond.

The MOVEit / Snowflake pattern — when the vendor’s customer becomes the attack vector

The 2023 MOVEit Transfer compromise and the 2024 Snowflake customer-account compromise illustrate two slightly different supply-chain patterns.

MOVEit pattern. A vulnerability in widely-used file transfer software is exploited by an attacker (in MOVEit’s case, the Cl0p ransomware group). The vulnerability allows direct compromise of customer instances. Hundreds of downstream organisations whose data passed through MOVEit are affected. Each customer’s cyber policy responds to their own loss; each may pursue claims against MOVEit’s developer (Progress Software) but contractual recovery is limited.

Snowflake pattern. Snowflake’s platform was not directly compromised; rather, individual customer instances were compromised because customers had not enabled MFA on their Snowflake accounts. The cause attribution is therefore split: Snowflake’s posture (defaults around MFA enforcement) versus the customer’s own configuration. Insurance responds; recovery against Snowflake is harder because the configuration choice was the customer’s.

The drafting question: does the contingent BI head require the third party to have been “compromised”, or does it respond where the third party’s service fails for any reason? Better wordings respond to service failure regardless of cause.

Worked numerical example

The retailer’s outcome:

The contingent BI sub-limit is the critical variable. A £500k contingent BI sub-limit would leave £1.28m uninsured; a £2m sub-limit covers in full.

The pre-scheduled vs broad-form distinction

Cyber policies treat covered third parties in two ways.

Pre-scheduled. Some policies require the insured to list specific critical providers and pay a premium for each. The cover responds only to failure of listed providers. The advantage is certainty; the disadvantage is that if a non-listed provider fails, no cover.

Broad-form. Some policies cover failure of any critical IT service provider used by the insured, subject to definitions. The advantage is breadth; the disadvantage is that interpretive disputes over what is “critical” may arise.

The 2024–2026 market is generally moving toward broad-form for mid-market and lower; pre-scheduled remains the practice for very large insureds.

The cloud platform exclusion question

Some cyber policies exclude failures of the major cloud platforms (AWS, Azure, GCP) on grounds of correlated risk. The reasoning: a major AWS outage affects thousands of insureds simultaneously, creating an accumulation exposure the insurer cannot manage. Where this exclusion is mounted, the loss is uninsured.

For any business heavily dependent on a single cloud provider, this exclusion is the most consequential underwriting term in the policy. Negotiate hard for either: removal of the exclusion; a sub-limit specifically for cloud platform failure; or a follow-form arrangement with a specialist cloud BI provider.

Practical buyer takeaway

For any commercial business with material IT supply-chain dependency:

Negotiate explicit contingent business interruption / system failure cover with a sub-limit at least equal to your largest credible 72-hour revenue exposure.

Negotiate the contingent BI period of indemnity to at least 90 days. Major supply-chain incidents now routinely run that long.

Audit the cloud platform exclusion question with your broker. If it is mounted, push for removal, sub-limit or follow-form arrangement.

Audit the covered third party definition. Pre-scheduled versus broad-form; what triggers count as “failure”; whether configuration-based compromises (the Snowflake pattern) count.

Document your critical IT supply chain and review your contracts. Liability caps and DPAs are the recovery framework when the provider fails.

Engage in tabletop exercises that include third-party failure scenarios. The cross-functional preparation pays dividends.

Maintain a Vendor Cyber Posture Register. For each critical provider, what do you know about their controls, their certifications (SOC 2, ISO 27001, PCI DSS), their incident history, their cyber insurance position.

Ask each critical vendor for evidence of cyber insurance with adequate limits and a contractual commitment to maintain it.

FAQ

Q1. If my PSP is breached, does my own cyber policy or the PSP’s pay my loss? Both potentially respond. Your cyber policy under contingent BI / system failure is the primary route for first-party loss. The PSP’s policy responds to the PSP’s costs and the PSP’s third-party liability (which includes you). The PSP’s contractual cap usually limits your recovery from the PSP.

Q2. Is the customer notification cost ours or the PSP’s? You are the controller; the notification duty is yours. The cost is yours; your cyber policy responds. You may have a contractual recovery against the PSP.

Q3. What if my PSP doesn’t have adequate cyber insurance? Then your contractual recovery is severely limited and your own cyber policy is your only meaningful recovery. This is why vendor cyber posture diligence matters.

Q4. Does the cyber policy respond to a force majeure cloud outage? A pure cloud platform outage caused by, say, a power failure is not a cyber event per se. The cyber policy’s system failure head (if present) may extend to non-cyber-caused failures; a pure cyber wording does not. Many wordings now contemplate “any failure” rather than “cyber-caused failure”.

Q5. What’s the typical waiting period for contingent BI? 8 to 24 hours is common; some wordings have 48 hours. The waiting period is the cyber equivalent of an excess-on-time.

Q6. Can I recover from my PSP under the GDPR processor regime? Yes — Article 82 provides direct liability for processors. The DPA-based recovery is parallel to the contractual route. Practically, the recovery is still subject to the PSP’s solvency and policy limits.

Q7. What about the Synnovis NHS pathology incident pattern? The June 2024 Synnovis ransomware compromise affected NHS pathology services across multiple hospital trusts. The supply-chain pattern: a single critical provider’s compromise affecting many downstream organisations. Each affected NHS trust had its own cyber response position; the aggregate exposure was distributed across multiple insureds. The pattern is now classical.

Q8. Does contingent BI cover the loss caused by the regulator suspending the third party? Usually no — regulatory action against the third party is not a cyber event. Some specialist wordings extend.

Q9. What if the third party’s compromise is undisclosed to me for months? The cyber policy’s discovery-based first-party trigger covers losses discovered during the policy period. Notification clocks run from discovery; do not assume the loss is too historic to claim.

Q10. Aggregate exposure modelling — how do I size limits? The classical approach: identify your three largest credible single-provider failures by 72-hour revenue impact. Set the contingent BI sub-limit at the largest. Set the main cyber limit at the worst-case direct-compromise scenario. Re-test annually.

Sources

UK GDPR Articles 24, 28, 33, 82. Data Protection Act 2018. PCI DSS v4.0. Watford Electronics v Sanderson [2001] EWCA Civ 317. Unfair Contract Terms Act 1977. MOVEit Transfer / Cl0p ransomware incident (2023) — public reports. Snowflake customer-account compromise (2024) — public reports. Synnovis NHS pathology ransomware (June 2024) — public reports. SolarWinds Sunburst supply-chain compromise (2020). Kaseya VSA ransomware (July 2021). Sisense and Okta supply-chain incidents (2023–2024). NCSC supply chain cyber security guidance.

Related

Hub: Cyber Insurance for UK Commercial Businesses Spoke 1: Ransomware claim handling Spoke 6: Cyber for retailers Spoke 7: Cyber for hospitality

Disclaimer: Insurance and legal commentary, not advice on your specific cover. Cyber wordings vary materially across insurers — always read your specific policy or ask your broker. Apex Insurance Brokers Limited is authorised and regulated by the Financial Conduct Authority, FRN 724952.