Three Layers of Business Interruption Coverage

It helps to separate the grants, because they respond to different events and often carry different limits, waiting periods, and triggers. Network interruption coverage responds to loss of income from an interruption of the insured own computer systems. The usual trigger is a security failure, meaning an actual or suspected unauthorized act or attack. System failure coverage, where included, broadens that to an unintentional and unplanned outage of the insured own systems that was not caused by an attack. Dependent business interruption responds to loss from an interruption at a third party the insured relies on. And dependent system failure extends that third party coverage to outages at the provider that were not caused by a security failure, which is the category most real cloud outages fall into. The gap most companies discover too late sits between the last two. A policy with dependent business interruption but not dependent system failure may respond to a provider that was attacked and not to a provider that simply went down.

• Network interruption: your own systems, triggered by a security failure
• System failure: your own systems, outage not caused by an attack
• Dependent business interruption: a third party systems, triggered by a security failure
• Dependent system failure: a third party systems, outage not caused by an attack
• The common gap is having dependent coverage but not dependent system failure

Which Providers Count

The definition of the dependent provider is the second decisive term, and forms differ substantially. Some policies cover only providers specifically scheduled by name. That is precise and it fails when a dependency nobody listed goes down, which is common given how many services a modern stack touches. Some cover any provider of information technology services to the insured under a written contract, which is broader but excludes services used without a formal agreement. Two practical questions follow. First, does your form schedule providers, and if so is the schedule current with your actual architecture? Second, does the definition require a written contract, and do you have one with every provider you genuinely depend on?

• Some forms cover only named, scheduled providers; keep any schedule current
• Some require a written contract with the provider, which excludes click through services
• Some reach outsourced providers broadly, and a few include utilities and telecommunications
• Check whether the definition reaches customer side dependencies as well as suppliers

Waiting Periods, and Why They Decide Cloud Claims

The waiting period is the single most important number in this coverage, and it is where most cloud outage claims fail. Business interruption coverage in cyber policies is generally subject to a waiting period expressed in hours, and coverage applies only to the loss suffered after the interruption has lasted beyond that period. Dependent coverage frequently carries a longer waiting period than first party coverage. Now consider the shape of a real provider outage. Major cloud and infrastructure outages are frequently measured in hours rather than days. An outage that costs a company a meaningful amount of revenue can resolve well inside a waiting period, which means the loss is real and the coverage never attaches.

• Coverage applies only to loss after the interruption exceeds the waiting period
• Dependent coverage waiting periods are often longer than first party periods
• Major provider outages frequently resolve within a typical waiting period
• Treat the waiting period as a negotiable term, informed by your own outage history
• Time sensitive revenue models need shorter waiting periods than usage based ones

What the Loss Includes, and What It Does Not

Where coverage attaches, the measure is generally lost net income plus continuing expenses during the period of interruption, sometimes with extra expense to mitigate. Several limitations recur. Sublimits are common on dependent coverage, frequently well below the policy aggregate, and sometimes with a separate sublimit for dependent system failure specifically. Reputational or long tail loss is usually excluded or separately sublimited. Customers who cancel after an outage, and revenue that does not return, are generally outside the interruption period the policy measures. Contractual penalties deserve direct attention for technology companies. Service level agreement credits owed to customers after an outage are a contractual obligation, and cyber policies commonly exclude liability assumed under contract or liquidated damages.

• Expect a sublimit on dependent coverage, sometimes separate for dependent system failure
• Reputational and post outage customer loss is usually excluded or separately sublimited
• Service level agreement credits are contractual and commonly excluded
• Provider agreements typically cap liability at fees paid and disclaim consequential damages

Talk It Through With a Specialist

Dependent system failure coverage and the waiting period attached to it are the two terms that decide whether a cloud outage is a claim or an absorbed loss. We can review which interruption grants your cyber policy carries, check the provider definition against your actual dependencies, and test the waiting period against the outages you have already lived through. Grandbay Financial Services places technology and cyber risks across the specialty and surplus lines markets, with leadership bringing 20+ years in commercial insurance. Book a time at calendly.com/grandbayfinancial. This article is for general information and is not a substitute for policy language or professional advice.