How these numbers are modeled
Read this before quoting any figure. Short version: the outcomes are grounded in real frameworks; the dollar amounts are illustrative, not a price for your specific incident.
What the dollar impact combines
Four terms, stated in full so you can audit them:
- Breach handling, $42,000 per unit of sensitive data, accrued at the moment the attacker accesses a store, not when data leaves. Covers notification, regulatory and remediation effort.
- Downtime, $38,000 per hour, multiplied by the share of hosts currently encrypted. This accrues every hour the encryption persists, so a longer incident costs more even with the same systems affected.
- Recovery, $7,500 per host, charged once for each host at the hour it is encrypted.
- Rebuild penalty, $1.6M, added once when backups are destroyed and no offsite copy survives.
Two things the number is not. Data quantities are abstract weights, not counts of records, gigabytes, customers or regulated data classes, so a "unit" is a modeling convenience rather than something you can reconcile to your own inventory. And the $2.0M ransom demand in the story is narrative only: ransom is never added to the cost, because whether to pay is a decision this tool does not make for you. Legal fees, litigation, business interruption beyond modeled downtime, and long-term customer loss are all outside the model entirely.
The point of the number is to move as your posture changes, not to price a real event.
What is grounded in published sources
The attack mechanics and every technique tag map to the public MITRE ATT&CK® framework. The unpatched-edge entry path models the pattern in the CISA Known Exploited Vulnerabilities catalog.
Where we say public-facing-application exploitation (T1190) accounts for roughly 70% of cataloged known-exploited vulnerabilities, that figure is ours, not CISA's: it is our own mapping of the catalog to ATT&CK techniques, computed as 1,096 of 1,555 entries in catalog snapshot v2026.03.30. CISA does not publish an ATT&CK classification of the catalog, and the catalog changes over time, so treat the number as a dated derivation rather than an official statistic.
Two further caveats. The KEV catalogs vulnerabilities known to be exploited, not how often each attack type occurs in real incidents: it informs which attack paths exist in this model, not their frequencies. And a framework mapping supports the taxonomy of a technique. It does not calibrate a probability, and it does not measure how much a given control changes an outcome.
The business email compromise scenario
The second attack scenario (v0.33) models account takeover leading to payment diversion: a phished session token or a sprayed password, the mailbox read for invoice threads, then a supplier bank-detail change requested from inside the real conversation. Technique tags map to MITRE ATT&CK® (Email Collection T1114, Internal Spearphishing T1534, Financial Theft T1657). There is no encryption phase in this scenario, so the ransomware outcome classes are structurally out of reach and the outcome legend says so.
What is grounded: the technique mapping, and the scale anchor for the diverted amount. In the FBI IC3 2025 Internet Crime Report, business email compromise accounted for $3,046,598,558 in reported losses across 24,768 complaints, roughly $123,000 per reported incident on average. What is estimated: every probability in the fraud chain (the verification gate, the session gate, the attempt cadence) and the modeled loss band (measured across this model's own runs: median about $135K, range about $30K to $450K), all illustrative design estimates pending calibration.
Two measured properties of this scenario, stated so you do not have to discover them: employee training is the control that most moves the serious-loss rate here (the verification step is what stops a fraudulent payment change, and the phishing gate is what stops the entry); identity controls and detection substantially reduce completed fraud but the account takeover has usually already exposed data, which itself counts as a serious outcome. And either detection channel can catch this scenario: the fraud rides cloud identity, but the phished workstation is on-premises and visible to endpoint tooling, which raised the majority of alerts in our measurements at higher postures.
How the stress test picks its attacks
You control only your own side. Each of the 300 attacks draws its entry point (phishing 35%, unpatched VPN/edge appliance 30%, password spray 25%, vendor access 10%) and its attacker profile (opportunistic 50%, organized gang 40%, advanced 10%) from a fixed mix. The mix is illustrative: a fixed, documented weighting toward internet-facing and identity paths, not a measured incidence rate. For comparison, three published mixes, each over a different population (read from the publishers' pages 2026-09-03): Mandiant M-Trends 2026 (investigations, 2025): exploits 32%, voice phishing 11%, prior compromise 10%, email phishing 6%. Verizon 2026 Data Breach Investigations Report (22,000 confirmed breaches, November 2024 to October 2025): vulnerability exploitation 31%, phishing 16%, credential abuse 13%, pretexting 6%. Sophos, The State of Ransomware 2026 (2,158 ransomware victims): malicious email 26%, phishing 24%, compromised credentials 23%, exploited vulnerability 18%. The three disagree with each other by more than any of them disagrees with this mix, so the mix stays declared rather than fitted to one of them. What it exists to show is the gap between how common an attack type is and how often it gets through you. The same deck of 300 attacks replays from a fixed seed (shown on the panel), so re-running after a posture change is a true paired comparison; the confidence interval on the serious-loss rate reflects sampling uncertainty. Drawing a new deck resamples the mix.
One deck, one scenario (v0.44). The stress test runs the deck of the scenario selected in the Scenario panel; the two scenarios are never mixed into one deck, because that would need a sourced weighting for how often an attack is a ransomware intrusion versus a payment diversion, which this model does not have. The business email compromise deck uses the same illustrative mix filtered to the vectors and attacker profiles that scenario offers and renormalized: phishing 58%, password spray 42%; opportunistic 83%, advanced 17%. Its headline is the payment-diversion count, shown beside the serious-loss rate rather than instead of it, because a read mailbox already counts as a breach and the serious-loss rate alone barely separates the two decks (measured at the Medium stop, default organization: 61% on the business email compromise deck against 67% on the ransomware deck). Three measured properties of that deck, stated so you do not have to discover them: patching, detection, backups and response readiness leave its serious-loss count exactly unchanged when raised alone (a read mailbox is a breach whether or not the payment goes through), although detection does catch some diversions before payment; training and identity are the controls that move it; and the organization shape barely moves it either, because the scenario rides identity rather than infrastructure.
How detection is modeled
Two separate telemetry channels. Endpoint detection (EDR and staff awareness) sees on-premises activity only; SaaS logins are invisible to it. Cloud sign-in and token anomaly monitoring (the identity category) sees cloud activity only. A cloud-only account takeover is caught, or missed, by identity monitoring alone.
Cloud access is tiered. A sprayed or stolen sign-in gives user-level access to what that account can reach. Taking over cloud administration is modeled as a separate, harder step that identity controls (privileged-account separation, sign-in monitoring) resist.
Data exposure is staged. Reaching a store, accessing the data, and exfiltrating it are separate steps, and incident response can cut egress before accessed data leaves. Conservatively, accessed data is treated as exposed for cost and reporting even when egress was cut. The reason is that unauthorized acquisition, access, use or disclosure can trigger a legal, regulatory, contractual or customer-notification evaluation on its own. Whether it actually does depends on jurisdiction, data type, encryption status, contract terms and the facts of the incident, and several regimes include exceptions and their own risk assessments. This tool models a scenario; it does not decide a notification question, and a simulated percentage is not a legal threshold. Consult qualified counsel.
How often the model fails to detect an intrusion inside its ten-day horizon. Measured with 1,200 attacks per cell, mid size band, organized-gang attacker, review coverage set to business hours (build/probe-v025-published-figures.mjs, re-run by the test harness on every build so these numbers cannot drift): with every control at the bottom of the scale the model leaves 89% of intrusions undetected in a mostly on-premises environment and 87% in a mixed one. At the Low stop, 68% and 63%; at Medium, 45% and 38%; at High, 27% and 18%. A mostly-SaaS environment is caught by identity monitoring alone: 50% undetected at the bottom of the scale, 14% at Low, 3% at Medium, under 1% at High. Before v0.46 the same cells read 1.7% and 0.8% undetected at Medium and 0.0% at High, because the model's clock ran three to four times faster than the published clocks; the calibration below is what changed, and these are its consequences, measured.
How the clock was calibrated (v0.46). Read against the publishers' own pages on 2026-09-03: Sophos X-Ops, Active Adversary Report 2026 (661 incident-response and managed-detection cases, November 2024 to October 2025) puts the median time from initial access to detection at 2.00 days with managed detection, 3 days overall and 5.00 days for cases handled by incident response alone; Sophos, The State of Ransomware 2026 (2,158 organizations hit by ransomware) reports that 56% of attacks encrypted data; Google Cloud Mandiant, M-Trends 2026 (investigations in calendar 2025) reports a global median dwell of 14 days with 48% of cases first detected by an outside party. The model before calibration detected every intrusion at the Medium stop with a median first alert of 0.4 days and encrypted at a median 1.2 days. Slowing detection alone could not reach any published figure, because the attacker's own pace ended the run first, so the whole clock moved: attacker actions per hour divided by 3, both detection channels' hourly chance divided by 8, the horizon stretched from five days to ten. No functional form changed and no random draw moved; the same seeds produce the same events in a slower world. On the fixed 300-attack deck at the Medium stop the median first alert is now 2.5 days with business-hours review and 2.2 days with 24x7 review, the median encryption 3.3 days, the encrypted share 55% of attacks, and the serious-loss rate 64% against 63% before. The published error, stated as the plan requires: Medium business hours 2.5 days against Sophos's 3 days overall (0.5 day under); 24x7 2.2 days against 2.00 with managed detection (0.2 day over); Low 2.8 days against 5.00 for incident-response-only cases (2.2 days under, with 47% of intrusions never detected inside the horizon); encrypted share 55% against 56%; Mandiant's 14-day median is outside a ten-day horizon and cannot be matched by this model. Backups and the domain clock (v0.47). Sophos, "The impact of compromised backups on ransomware outcomes" (2024 survey of 2,974 organizations hit in the prior twelve months): 94% saw an attempt on their backups and 57% of attempts succeeded, about 54% of victims. Before v0.47 the opportunistic attacker profile, half of every deck, never went for the backup server, so only 31% of encrypting runs at the Medium stop lost their on-prem backups. Every attacker profile now hunts backups; nothing else moved, because success in this model already means the attacker reached the server through your posture. On the fixed deck at the Medium stop, 46% of encrypting runs now lose the on-prem backups (survey: about 54%, 8 points under), 58% at Low and 31% at High; the offsite immutable copy remains the thing that decides catastrophic loss. Sophos Active Adversary 2026 also reports a median 3.40 hours from initial access to Active Directory compromise; the model now records that hour on every run and reports it here without tuning to it: on the fixed deck at the Medium stop the model's median is about 34 hours, ten times the published figure. That gap is real and is the next calibration candidate (the attacker's privilege-escalation pace, separate from its lateral pace). Not calibrated, and still illustrative: the triage and authorization intervals (no source publishes that split), the attack mix (the three published mixes disagree with each other by more than any disagrees with ours; they are listed above), the cost constants (survey means over different populations), and ransom payment, which the model does not represent.
Detection keeps business hours when you do. With alert review set to business hours only, the tool-driven part of endpoint detection is reduced overnight (alerts fire; nobody triages them until morning), while 24x7 coverage watches every hour. The simulation clock starts at 9am on a Monday and runs for ten days (240 hours), so every run contains one weekend (hours 111 to 158). With alert review set to business hours, Saturday and Sunday run at the same reduced factor as a weeknight; 24x7 coverage watches the weekend as it watches every other hour, and the unreviewed setting never consulted the calendar in the first place. Measured on the fixed 300-attack deck at the Medium stop when the weekend was added (v0.48): the detected share of intrusions under business-hours review fell from 79% to 77%, first alerts that used to land on a Saturday or Sunday fell from 30 to 24, and the serious-loss count moved by one; runs under the other two settings are byte-identical. The clock names the weekday. The off-hours reduction is a design estimate, illustrative pending calibration.
How response is modeled
An alert is not a response. From this version the model separates three points that earlier versions collapsed into one: detection (a channel fires), triage (defenders have pieced together what is happening and know enough to act), and authorization (someone with the authority to take disruptive action has approved it). Containment, session revocation and credential resets begin only after authorization. This split came from an incident-response practitioner reviewing the tool: in his words, EDR might identify an anomaly, but it takes defenders quite a bit of time to piece things together and get approvals to kill access.
Triage speed is driven by the quality of the telemetry channel that raised the alert, by the attacker's stealth, and by your alert-review coverage: an alert raised overnight under a business-hours review schedule is worked at the reduced off-hours rate, not shelved. Authorization speed is driven by the response readiness category alone: a written plan, a named lead reachable out of hours, and pre-authorized containment actions shorten it; their absence stretches it. Every interval constant is an illustrative design estimate pending calibration, like the rest of the model.
Two measured properties of this change, stated so you do not have to discover them (build/probe-v036-response.mjs, 600 runs per cell): slower response mostly moves severity and cost, not the count of serious runs. Across the stress-test mix at medium posture, the catastrophic share roughly tripled and mean modeled cost nearly doubled compared to the previous model version, while the serious-loss rate itself moved a few points. And raising response readiness buys severity and money, not fewer incidents: it cannot repel or detect anything, so its measured effect is a lower catastrophic share, lower cost, and in the business email compromise scenario fewer completed frauds. If earlier versions of these numbers looked better, that is because the old model authorized a full response two hours after the first alert, which the practitioner review identified as unrealistically fast. The numbers moved because the model got more honest.
Three mechanics worth knowing before you argue with a result
A long incident detonates on its own. Ransomware fires when the attacker holds domain administration and enough of the estate, but it also fires after hour 72 in any run where the attacker holds more than a quarter of the hosts. A slow, quiet intrusion does not stay harmless forever.
Response can be what triggers detonation. When an attacker holding domain administration sees incident response begin, they detonate rather than lose access. This is a real pattern and it has a counter-intuitive consequence in the model: improving detection can make a run detonate sooner. It still improves outcomes on average, because most runs are stopped before that point, but you will occasionally see a better posture produce a faster detonation, and that is the model working rather than failing.
Size moves hosts far more than it moves data. The size band scales your departments, so a larger organization has proportionally more workstations and more ransomware exposure. Shared infrastructure such as file servers, databases and cloud stores is held at a fixed size across bands, so the sensitive-data volume behind a breach changes much less than the staff count does. Expect ransomware cost to scale with size and breach cost to scale weakly. That is a modeling simplification awaiting calibration, not a claim about real organizations.
The environment is a representative template, not a census. Your organization card selects one of three shapes (mostly on premises, a mix, mostly SaaS) and a size band; the map, the attack surface, and the stress-test mix follow. Where a shape has no VPN appliance, the unpatched-edge vector does not exist and the remaining mix is redistributed proportionally. SaaS-level ransomware and extortion (encrypting or ransoming cloud data) is not modeled yet: in a mostly-SaaS environment, serious outcomes appear as identity-led data breach, and backup discipline has NO modeled effect at all in that shape, because there is no on-premises backup infrastructure for an attacker to reach. Patching discipline is close to inert there for the same reason: measured across the full Low-to-High range it moves the serious-loss rate by well under one percentage point, against roughly nine in an on-premises or hybrid shape. Both controls still matter in reality; the model simply has nothing for them to act on here. The size band changes the size of a loss, not the odds of one. Measured with 1,200 attacks per band in the mixed shape with every control at the Medium stop (same probe, same harness check; re-measured for the calibrated clock, v0.46): mean modeled impact runs $2.2M, $3.0M and $4.5M across the three bands while the serious-loss rate is 62.9% in all three, identical to the tenth of a point. That is deliberate. A larger organization has more to lose, but nothing about being larger makes a given posture hold better or worse in this model, so a changed size band moves the money and leaves the outcome mix where it was.
What is still an estimate (most of it)
Earlier versions of this page listed only the cost constants here. That understated the position, so here is the accurate one: techniques and control concepts are mapped to published frameworks, but nearly every number in the model is an illustrative design assumption rather than a validated measurement. That includes the entry-success gates for each attack route, the attacker skill, stealth and speed profiles, token-theft likelihood, lateral and cloud movement probabilities, the privilege-escalation rate, backup resistance, the data access and exfiltration rates, base detection probabilities and response timing, the off-hours coverage factor, encryption and containment rates, and all four cost constants above.
Calibration against published 2026 benchmarks (IBM Cost of a Data Breach, Sophos State of Ransomware, incident-response reporting of that class) is the next build, with published calibration error. Until it ships, every percentage and every dollar figure here is an output of an uncalibrated model. Use them to compare postures against each other, not as a forecast of your own risk.
Results are generated entirely in your browser and are not signed or independently verified. They are suitable for discussion and training. They are not an audit artifact, a compliance opinion, an insurance estimate, or a board risk forecast.
How to read the output
Read it as relative, not absolute. "Adding immutable backups cut my catastrophic rate from 46% to 12%" is the intended takeaway. "My breach will cost exactly $3.1M" is not a claim this tool makes.
Illustrative model for executive training. Scenario facts are fictional; any organization name you enter stays in your browser and is not transmitted. Technique and vulnerability references are public frameworks (MITRE ATT&CK®, CISA KEV).