Skip to content

Incident Cost → Coverage Allocation Simulator

A real incident bill lands across several coverage parts at once — forensics here, business interruption there, a ransom, third-party claims, regulatory costs. Each part has its own sublimit, and the whole thing hits one retention and one aggregate cap. Split your modelled incident across the parts and see what the policy actually absorbs versus what you retain. Transparent arithmetic on your numbers; not insurance advice.

Coverage partCost ($)Sublimit ($, 0=full)
Incident response (forensics, counsel, notification, PR)
Cyber extortion / ransom
Business interruption
Data & systems restoration
Privacy / network liability (3rd-party claims)
Regulatory defense & fines
Recovery95% of cost
Total incident
$2,900,000
Insurer pays
$2,750,000
You retain
$150,000
Watch the sublimited parts (extortion, regulatory) — they cap first. Model the ransomware row in detail in the Coverage Reality Calculator, and check which parts even respond to your scenario in the Post-Mortem Lab.
TL;DR

What this simulator does

  • A real incident bill lands across several coverage parts at once — forensics, business interruption, extortion, third-party liability, restoration, regulatory.
  • Split your modelled incident across the parts, set each sublimit plus one retention and one aggregate, and see what the policy absorbs vs what you retain.
  • Surfaces how sublimited parts (extortion, regulatory) and the aggregate cap combine to leave a gap larger than any single number suggests.
  • Transparent arithmetic on your own figures; not insurance advice.

Why this matters

Boards reason about cyber cover as one number. Claims do not work that way: a serious incident is a stack of different costs that each hit a different coverage part with a different sublimit, all funnelled through one retention and one aggregate. The recovery that emerges is a function of that structure, and it is routinely lower than the limit on the declarations page suggests.

Modelling the allocation shows you exactly which part is your binding constraint, so you fix the right thing — a sublimit, the aggregate, a waiting period — instead of over-buying blindly. Transparent model, not insurance advice.

Frequently asked questions

How does a cyber policy pay out across different coverage parts?

A cyber policy is a bundle of coverage parts — incident response, cyber extortion, business interruption, data/systems restoration, privacy and network liability, regulatory defense — each of which can have its own sublimit. A real incident usually triggers several at once. The way it pays is: each cost is allocated to its coverage part and capped at that part’s sublimit (if any); the retention comes off; and the total recovery is capped at the policy’s aggregate limit. Because the sublimited parts cap first and the aggregate caps the whole, the recovery on a multi-part incident is often well below the headline limit. This simulator applies those mechanics to the split you enter.

Why model the allocation instead of just the total?

Because the structure, not the total, decides the payout. Two incidents with the same total cost recover very differently depending on where the cost falls: a loss concentrated in a sublimited part (say extortion at a $500k sublimit) recovers far less than the same dollars spread across unsublimited parts. Modelling the allocation shows you which parts are your real constraint, so you can raise the sublimit that matters, rather than assuming a big aggregate limit protects you everywhere.

Are these numbers real?

No — every figure is one you enter: the cost per coverage part, each sublimit, your retention and aggregate. The tool only does transparent arithmetic to show how those interact. It does not assert any market costs or payout rates, and it simplifies real policies (which vary in definitions, order of application, coinsurance and extensions). It is an educational model, not insurance advice; confirm your policy’s structure with your broker.

What should I do if the simulator shows a big retained gap?

Look at where the gap comes from. If a sublimited part is the constraint, consider raising that sublimit or adding an endorsement. If the aggregate caps the total, you may need more limit (model it in the tower builder). If business interruption is large, revisit your waiting period and restoration cap. The point is to turn "we have cyber insurance" into "we know what this specific kind of incident would actually cost us net," and to fix the biggest constraint first.

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.
Educational model on your own inputs — simplifies real policies; not insurance advice.
🎉 New here? Use code WELCOME10 for 10% off any plan at checkout
Cyber Incident Cost → Coverage Allocation Simulator — What the Policy Really Absorbs · PlayCISO