Dependent / Contingent-BI Mapper
When a critical provider goes down and takes your revenue with it, is it covered? Dependent (contingent) business-interruption cover is narrower than most assume. List your critical dependencies and see the two gaps that catch everyone — unnamed providers and security-failure-only triggers — plus the waiting period. Educational, not insurance advice.
- Security-failure-only trigger — a plain outage (config error, hardware, fibre cut) would not trigger cover; most real outages are non-malicious.
- Not named/scheduled — many dependent-BI extensions only cover providers you have specifically scheduled.
- Non-IT dependency — some cover is limited to IT/technology providers, so this category may fall outside entirely.
- Security-failure-only trigger — a plain outage (config error, hardware, fibre cut) would not trigger cover; most real outages are non-malicious.
- Not named/scheduled — many dependent-BI extensions only cover providers you have specifically scheduled.
What this mapper does
- When a critical SaaS, cloud or payment provider goes down and takes your revenue with it, that loss is only covered if your policy has dependent (contingent) business-interruption cover — and most of your providers are probably not covered the way you assume.
- List your critical dependencies and the mapper flags the two gaps that catch everyone: the provider is not named/scheduled, and the trigger is limited to the provider’s security failure (not a plain outage).
- It also reminds you the waiting period applies before any dependent-BI pays — the first several hours of downtime are usually yours.
- Educational and directional — read it against your actual policy wording with your broker. Not insurance advice.
Why this matters
Modern revenue runs on other companies’ uptime — cloud, payments, authentication, email, DNS, a handful of SaaS apps. When one of them fails, your income can stop even though nothing of yours was touched. Dependent (contingent) business-interruption cover is meant for exactly that, and it is one of the most misunderstood parts of a cyber policy: buyers assume a critical outage is covered, then discover the vendor was never scheduled, or that the cover only responds to a security failure and the outage was a plain technical one.
This mapper lays your dependencies against those gaps so you can see where you are actually exposed and fix it — schedule the right providers, negotiate a system-failure trigger, and understand the waiting period — before an outage proves the point. Educational and directional, not insurance advice.
Frequently asked questions
What is dependent or contingent business interruption (CBI) in cyber insurance?
Dependent business interruption — also called contingent business interruption — covers the income you lose when a third party you rely on suffers an outage, rather than when your own systems go down. If your e-commerce stack depends on a cloud provider, a payment processor and an authentication service, a failure at any of them can stop your revenue even though nothing of yours was breached. Dependent-BI cover is the part of a cyber policy that responds to that. The catch is that it is narrower than most buyers assume, which is what this mapper is for.
Why might my cloud or SaaS outage not be covered?
Two reasons dominate. First, scheduling: many dependent-BI extensions only cover providers you have specifically named (scheduled) on the policy, or only cover certain categories such as IT/cloud providers — an unnamed vendor or a non-IT dependency falls outside. Second, the trigger: some dependent-BI cover only responds when the provider’s outage was caused by a security failure (a cyberattack), not a system failure (a plain technical outage, a config error, a fibre cut). A huge share of real third-party outages are non-malicious system failures, so a security-failure-only trigger leaves a wide gap. This tool flags both for each dependency you list.
What is the waiting period and why does it matter here?
Dependent-BI cover almost always carries a time-based waiting period (often several hours) that must elapse before the policy starts paying — the early hours of an outage are retained by you regardless. For dependencies whose outages are typically short, the waiting period can mean you rarely or never actually collect, even when the dependency is otherwise covered. It is a real part of the coverage picture, so the mapper surfaces it alongside the scheduling and trigger gaps.
Is this a coverage determination or insurance advice?
No. It is an educational model that shows where dependent-BI cover commonly falls short so you can check your actual policy wording and your schedule of named providers with your broker. Whether any specific outage is covered depends on your exact wording, the cause of the outage and the facts. Confirm with your broker and read the dependent-BI section of your policy.
This tool is free and always will be. Would a Pro workspace — saved designs, team sharing and exports — be worth paying for?
Show me Pro →No account needed to use this tool — this just tells us whether Pro is worth building out.