How the number is made

You describe one system and the state it is in today, pin that as the baseline, then change the sliders to describe each alternative and pin it with what it costs. Every pinned option is simulated the same way and shown side by side over the horizon you choose. "Do nothing" is an option like any other; it has no spend, and it has a cost.

A contact is a capable attacker getting a position from which this system can be attacked. You estimate contacts per year for two communities, because they respond differently to your options: opportunistic (automated exploitation, ransomware affiliates, commodity intrusions) and targeted (adversaries who want this organization specifically). Network position scales both: isolation changes how often the system is reached, not whether an attack works. An internet-facing system is treated as contacted at least monthly by opportunists regardless of the slider.

Nobody knows their contact rate better than a factor of two, so a stated rate r is simulated as a three-point distribution from r/2 to 2r, most likely r.

Success is the probability a contact gets in, derived from the findings on the system. Each class of finding has a per-finding success probability for each community, and they combine as 1 − ∏(1 − pi). Known-exploited vulnerabilities dominate for opportunists, who run what is already weaponised; criticals matter more to targeted adversaries, who will obtain or build what they need. This is why the sliders behave the way they do: with many KEVs present the probability saturates near 1 and nothing else moves the number; take the KEVs to zero and the opportunistic probability falls while the targeted one barely does if hundreds of criticals remain; mediums and lows almost never move it at all. The per-class probabilities are placeholders; the next version replaces them with per-CVE exploit prediction scores.

Successful events per year follow a Poisson process with rate contacts × success for each community, summed.

Each successful event is costed from the recovery it forces, using facts you have rather than a guess:

• Detect and decide: half a day to five days.
• Do the backups survive? A probability set by whether they are immutable and offsite. Intruders go for the backups before they detonate.
• If they survive: the restore takes at least backup size ÷ usable link speed (physics), plus validation; multiplied up if a restore has never been tested or the plan never exercised. Data since the last backup must be re-keyed.
• If they do not: a rebuild, far longer on an end-of-life platform where there is no supported path back; weeks of data are lost; and with some probability a ransom is paid, which shortens the outage without removing it.
• Outage cost = days down × the system's daily revenue × the share actually lost or still spent. Loss is not revenue; that share is yours to set.
• Response cost: forensics, legal, notification, overtime, as a share of revenue with a floor.

Ten thousand simulated years give the distribution of annual loss. The tool reports its mean (expected annual loss), the 90th and 99th percentiles (the 1-in-10 and 1-in-100 year), the chance of at least one event this year and over the horizon, and the loss exceedance curve: for any dollar amount, the probability a year's losses exceed it. Expected loss over the horizon is the annual figure times the years; the exposure of an end-of-life system actually grows over time, which the next version will model.

In the decision table, net for an option is the expected loss it removes over the horizon minus the extra it costs over the horizon. The cost of saying no is read directly from the table: the additional expected loss, and the additional chance of an event, that the baseline accepts relative to the best alternative.

Every run uses the same random seed, with an independent stream per simulated year. Two settings therefore reuse the same draws, so the difference between them is the model and not the dice, and the readout moves smoothly as a slider moves. While a slider is in motion the tool runs a few thousand years; when it rests, it runs the full set and refines the figure.

• Not a prediction. It is a structured estimate whose every assumption is listed on the page and open to challenge.
• Not a score. Nothing here is a 1-to-5; scales hide the very uncertainty a decision needs to see.
• Not a service. The page is static; your inputs never leave your browser; there is no account and no upload.

Version 0.1. The arithmetic is final; the numbered assumptions in "What the model assumes" are placeholders chosen to be plausible and conservative, each to be replaced by a cited source or by your own data. Planned next: per-CVE exploit prediction in place of per-class priors, growth of exposure over the horizon for unpatched systems, a sensitivity view that names the three inputs carrying the answer, and a printable memo for the risk owner to sign.