Your client’s systems were never breached, never misconfigured, never touched — and the business still stopped anyway, because its software went down somewhere else. Allianz Commercial’s large-claims analysis puts a size on that secondhand loss: contingent business interruption (CBI) supply chain events accounted for 15% of the value of large cyber claims — those above €1 million — in the first half of 2025, up from 6% in 2024. Contingent business interruption is the loss that starts at a supplier, cloud host, or IT vendor and lands on your client’s income statement.
Read the figure on its own basis before repeating it. It is a share of claim value, not a count of claims, drawn only from large claims in one global insurer’s book — Allianz’s own analysis, not an industry census, and not a measure of all cyber or business interruption claims. What it does show is direction: the slice of big cyber losses that began at somebody else’s company more than doubled in a year, even as large-claim frequency fell by roughly 30%.
Allianz is explicit that these losses “can result from both attacks and technical faults” — and each kind has a recent, expensive example. In June 2024, a ransomware attack on CDK Global — the software US auto dealerships run on — put some 15,000 dealerships back on paper for close to three weeks — an estimated $1.02 billion in direct losses, per Anderson Economic Group. The dealerships were never attacked; their vendor was. A month later, no attacker at all: a flawed CrowdStrike update crashed an estimated 8.5 million Windows systems worldwide. Technical-failure business interruption appeared in Allianz’s large-loss data for the first time in 2024 — around 10% of large-claim value, driven in part by that one bad update.
A different grant
A cyber policy responds most readily to an outage on the client’s systems; an outage at a provider is a different grant — contingent, or dependent, business interruption — and forms split provider failures into two kinds. Nationwide’s E-Risk guidance puts the split plainly: insurers typically separate third-party technology failures into security failures, such as attacks, and system failures, such as human error or technical faults — and coverage often answers the first kind while excluding the second, or offering it only in limited, sublimited form. The CrowdStrike scenario — a vendor’s bad update, no crime anywhere — is precisely the one that can land outside the grant.
Five checks at renewal
The first two renewal questions are existence and cause. One: does this form carry contingent or dependent business interruption at all, or does its business interruption stop at the client’s own network? Two: when a provider fails, which failures count — only a malicious attack, or also the provider’s system failure: the botched update, the misconfiguration, the cloud region going dark? If the answer is malicious events only, tell the client that in those words, because the outage they’re most likely to have is the other kind.
Third: the waiting period — the hours that must pass before contingent coverage responds, with the client absorbing everything inside them. Cyber waiting periods commonly run six to twelve hours. That arithmetic is why a roughly fifteen-hour AWS outage in October 2025 produced insured losses well below its economic footprint — waiting periods of typically eight to twelve hours, expected AWS reimbursements, and the outage’s short duration did that. A waiting period is not fine print. Priced against a client that bills by the hour, it is a deductible denominated in time.
Fourth: how much, and for how long. Dependent business interruption is commonly sublimited below the policy’s main business interruption limit, so check the number on that insuring agreement, not the aggregate on the declarations page. And check the period it pays for: cyber business interruption usually runs 90 to 180 days, against 12 to 24 months for property, as Allianz notes. A vendor failure that takes a quarter to unwind can outlast an indemnity period that looked generous at binding.
Fifth: which providers the form recognizes. Some forms cover defined categories of provider; others want the critical ones named or scheduled — and an unnamed vendor may not be a dependent business under the policy. That question cannot be answered from the policy alone. It needs the client’s list: the cloud host, the managed service provider, the platform the operation runs on, the payment processor. A vendor missing from the client’s list never gets checked against the form — and a vendor missing from the form is not covered.
The real work is an inventory
Which makes the real renewal work an inventory, not a form review. Allianz’s Tresa Stephens makes the same point from the carrier side: businesses should “understand these critical dependencies and the potential impact on an organization should they go down.” A one-page dependency check — the top vendors, what stops without each one, how long the client can run without it — turns the five form questions into a comparison you can run. A broker who cannot name a client’s top five vendors cannot tell that client whether the policy answers the outages those vendors can cause.
So what do you tell the client at renewal? That their most likely large interruption no longer starts in their server room — it starts in someone else’s, and its share of large cyber losses is growing. That you checked the five things that decide whether the policy follows the loss there: the grant, the cause, the hours, the limit, and the names. And where the form stops short — system failure excluded, a key vendor unnamed, a sublimit sized for a smaller company — you say so plainly and price the fix. That is the broker’s conversation: not fear of the next outage, but knowing whose outage the policy covers before it happens.