Examples

Walkthrough — Customer data breach (Event Risk)

The Customer data breach model is the worked example that ships inside Event Risk Exposure: one event quantified end to end, from two cause drivers and two impact dimensions through controls and treatments to a per-treatment cost-benefit. Open /event-risk in another tab and follow along; hit Sample to reset to it if you've edited. Compact as the scenario is, it covers the tool's core mechanics: shared multi-target controls, dual-reduction treatments, mixed likelihood input modes, and a cost-benefit table that does not rubber-stamp the treatments, which turns out to be the most instructive part.

The model behind the tool is explained on the event-risk methodology page; this page is the numbers-in-hand companion to it.

The event

Loss of sensitive customer data

Same event statement as the Beau-Tie sample (see that walkthrough for the qualitative bow tie of the same risk). Phrased noun-form, no embedded cause or consequence.

Two causes

1. Phishing of staff credentials

Likelihood mode: distribution (triangular). Parameters: min 15%, mode 35%, max 55%. Reflects elicited uncertainty: "we think a targeted campaign lands credentials in 15–55% of assessment periods, most likely 35%".

2. Malicious insider exfiltration

Likelihood mode: band at L2 (Unlikely). The default band probabilities are 10% / 30% / 50% / 70% / 90%, so L2 carries 30% per iteration. Band mode suits a driver where stakeholders can rank likelihood on the organisation's scale but a three-point probability elicitation would be false precision.

Two impacts

Regulatory fines and penalties

Distribution: triangular, min $200k, mode $800k, max $2.5M. Reflects statutory penalty ranges for data-protection incidents at the size of customer base being modelled.

Reputational damage and churn

Distribution: PERT, min $100k, mode $500k, max $3M. PERT rather than triangular because reputational impact tends to cluster around a most-likely 12-month churn estimate with rare-tail catastrophic scenarios, which is the PERT shape.

Two existing controls

MFA enforcement on all SSO accounts

Targets: both causes (phishing + insider). Reduction: 40% likelihood. A single control applying to multiple cause drivers, the multi-target pattern. Reads as: "MFA on every account reduces the chance of either a phishing or an insider-credential pathway succeeding by 40%".

Documented incident response runbook

Targets: both impacts (regulatory + reputational). Reduction: 20% consequence. The same multi-target pattern on the impact side: the runbook reduces severity if the event fires, applied to both consequence dimensions.

Two treatments

Comprehensive cyber training program (annual)

Targets: phishing cause and reputational impact. Reductions: 25% likelihood, 10% consequence. Cost: $180,000.

The dual-reduction, dual-target pattern in one treatment. Reads as: "better-trained staff reduce phishing-pathway likelihood by 25% and reduce reputational impact by 10% (faster incident response from trained staff cuts the 12-month churn estimate)".

DLP tooling rollout

Targets: insider cause only. Reduction: 35% likelihood. Cost: $240,000.

Indicative results (10,000 iterations)

The figures below come from a seeded 10,000-iteration engine run and are locked to the engine by a test. The tool itself doesn't expose a seed yet, so your on-screen numbers will differ by a percent or two; everything structural holds. Baseline first:

Baseline occurrence rate: about 35%. You can sanity-check this by hand: phishing averages 35% × 0.6 after MFA = 21%, the insider band is 30% × 0.6 = 18%, and any-of aggregation gives 1 − (0.79 × 0.82) ≈ 35%. When a headline number can be cross-checked with arithmetic, do it.
Baseline mean (expected loss): about $570k.
Baseline P80: about $1.49M. Baseline P90: about $1.93M. These are unconditional figures, measured across all iterations including the roughly 65% where the event never fires: 80% of simulated years cost at or below $1.49M. Note the unconditional P50 is $0, and correctly so: the event fires in fewer than half of the iterations.

Then run with treatments and compare:

Treated occurrence: about 25%. The treatments cut the trigger rate by about ten points.
Treated P80: about $1.10M (down about $390k from baseline). Treated mean: about $390k (expected loss down about $180k). Treated P90: about $1.67M.

Percentiles near the occurrence rate are brittle

Watch the relationship between the percentile you quote and the occurrence rate. The baseline P50 here is $0 because the event fires in only ~35% of iterations, and the treated P80 sits at the 20th percentile of the fired iterations (80% minus 75% zero mass, over 25% occurrence), a noisy, fast-moving region. Push treated occurrence below 20% and the treated P80 collapses to $0 outright, at which point the hero card's "reduction" reads as the whole baseline figure. For a rarely-firing event, low and mid unconditional percentiles say more about the occurrence rate than about severity; the "Impact distribution if the event fires" chart exists for exactly this reason, with conditional markers. Match the statistic to the question before quoting either.

Reading the cost-benefit table honestly

Two rows, one per treatment. The marginal-reduction column is leave-one-out: what you'd lose by skipping that treatment while keeping the other. On this envelope:

Training program ($180k): marginal expected-loss reduction about $92k, ROI about 0.51×. The dual reduction earns its lead: it acts on the dominant phishing pathway and trims the reputational tail.
DLP rollout ($240k): marginal reduction about $90k, ROI about 0.37×.
Portfolio ROI: about 0.43×. The pair costs $420k and cuts expected loss by about $180k a year.

So on the expected-loss maths alone, neither treatment pays for itself. That is the table doing its job. What the ROI column does not see: the ten-point occurrence drop, the $390k of P80 reduction, and anything outside the model (regulator expectations, attestation requirements, the phishing pathway's role in risks other than this event). A sub-1.0× row is an input to the investment conversation, not a veto.

Reading the driver sensitivity lists

Three side-by-side lists, each ranked by how much of the total variance disappears when that driver is removed and the baseline re-run. With the default envelope you'll typically see:

Causes: closer than instinct suggests (phishing roughly 37% against the insider's 30%). After MFA the two pathways fire at similar rates, 21% against 18%, so neither dwarfs the other; phishing edges ahead on its higher rate and its elicited likelihood range. The list's job is to replace the loudest-cause instinct with a measurement.
Impacts: both are large, regulatory ahead. Every fired iteration sums both impacts, so removing either collapses much of the total; the regulatory dimension edges ahead (roughly 77% against 64%) on its heavier mid-range, while the reputational PERT concentrates weight near its $500k mode despite the $3M tail.
Controls: the incident response runbook ranks first (roughly 56% against MFA's 16%). It trims every fired iteration's consequence on both impact dimensions, so removing it moves more variance than removing MFA's likelihood reduction. A consequence control on every pathway can matter more than a likelihood control, which is not the intuition most workshops start with.

Iterating on the model

The most valuable thing the tool does is let you ask "what if?" Edit a treatment's reduction percentages or cost and re-run. A few patterns:

The breakeven question. Halve a treatment's cost and re-run. If the ROI crosses 1.0×, you have your willingness-to-pay number for the conversation with the vendor.
The combination question. Delete one treatment and re-run. The other's marginal reduction will likely increase, because it now carries load that was previously shared. That tells you which treatments are complements and which are substitutes.
The reduction-sensitivity question. If the SME quoted "25% likelihood reduction" for the training program, try 15% and 35% and re-run. If the outputs barely move, the elicitation imprecision isn't a problem; if they swing, push the SME for more evidence.

What this model can't tell you

The limits worth naming before quoting any of these figures elsewhere. Causes trigger independently (any-of aggregation has no way to say "phishing and insider risk rise together"). Reduction percentages are elicited judgements applied as fixed multipliers, not measured control performance. On-screen figures move a percent or two run to run because the tool doesn't expose the engine's seed yet. And the figures here lead at the default P80; the Reported at chooser can lead the panel with P50 through P95, and which level an organisation should fund is an appetite decision, covered with the rest of the model's assumptions on the methodology page.