Monte Carlo Simulation for Cyber Risk: Building and Reading Loss Range Models

A cyber risk number such as "annualised loss of £1.2 million" hides the question boards actually ask: how bad could a year get, and how likely is that? Monte Carlo simulation answers it by sampling thousands of plausible years from ranges of frequency and loss, and turning them into a distribution of annual loss. This guide is the method detail behind the Cyber Risk Quantification Guide: how to structure a frequency and severity model, choose and fit distributions, decide how many iterations are enough, handle dependencies between scenarios, read loss exceedance curves and sensitivity charts, and validate the model so its output survives challenge. It is for risk analysts, security architects building their first quantitative model, and executives who need to judge whether a simulated number deserves trust.

Key takeaways

• The model is frequency times severity, sampled. Each iteration draws how many loss events happen in a year and what each costs, then records the annual total; the collection of totals is the answer.
• Inputs are ranges, not points. The Open Group's O-RA standard asks for estimates that are accurate 90% of the time and warns that results cannot be more precise than the inputs.
• Distribution choice shapes the tail. A log-normal fitted to a 90% interval produces far larger extreme losses than a symmetric distribution over the same range; choose deliberately and record why.
• Check convergence, do not guess it. Means stabilise quickly; the 95th and 99th percentiles that boards care about need many more iterations.
• Report a curve and a question. A loss exceedance curve with two or three named percentiles, tied to a decision such as an insurance limit or a control investment, beats a single expected loss.

What a Monte Carlo cyber risk model does

O-RA (Version 2.0.1, section 3.1) states that Open FAIR analysts use Monte Carlo or other stochastic methods to calculate results, and describes Monte Carlo simulation (section 4.4) as a method for modelling the future in the face of significant uncertainty that "models thousands of outcomes consistent with those parameters and their distributions". The output is not a forecast of next year; it is a picture of the range of years the organisation could plausibly experience, given what its experts and data say.

Use simulation when at least one of these is true: inputs are uncertain enough that a single estimate would mislead; several scenarios must be combined into one exposure figure; the decision depends on the tail (insurance limits, capital, risk appetite thresholds); or you need to compare the effect of a control on the whole distribution, not just the average. For a quick ranking of a dozen scenarios, a simpler qualitative or expected-loss method may be enough.

Monte Carlo compared with other approaches

Structuring the model

Almost every cyber Monte Carlo model is a frequency and severity model (actuaries call it a compound or aggregate loss model). Using FAIR terms, each iteration does this:

1. Sample a loss event frequency for the year, either directly or as Threat Event Frequency multiplied by Vulnerability (the probability a threat event becomes a loss event).
2. Sample a count of events from that rate, usually with a Poisson distribution, so some years have zero events and some have two or more.
3. Sample a loss for each event from the severity distribution, optionally split into primary loss (response, replacement, productivity) and secondary loss (fines, litigation, reputation) with its own probability of occurring.
4. Sum the year. Record the annual total, and the per-event losses if you want event-level statistics.
5. Repeat for tens of thousands of iterations and summarise the totals.

Decide early whether the scenario unit is an event type ("ransomware on the ERP estate") or an asset class, and keep scenarios mutually exclusive so you do not count the same loss twice. A Cyber Risk Scenario Library keeps scoping consistent across analyses. Where the scenario involves identity abuse, such as a stolen CI/CD token or a compromised service account, model Vulnerability from evidence such as the share of non-human identities with long-lived secrets or without MFA-equivalent controls, rather than from opinion alone.

Choosing and fitting distributions

O-RA (section 4.2.3) is explicitly agnostic on which distribution is right, suggesting a uniform distribution when only a minimum and maximum are known. In practice a handful of choices cover most cyber models.

The open-source riskquant library published by Netflix shows the common pattern: its SimpleLoss class uses a Poisson frequency with a log-normal magnitude fitted so that the low and high estimates fall at the 5% and 95% cumulative probability points, and its PERTLoss class swaps in a modified PERT frequency with a kurtosis setting that FAIR practitioners call "belief in the most likely". Whatever tool you use, write down the fitting rule: a range treated as a 90% interval and the same range treated as an absolute minimum and maximum give very different tails.

Inputs should come from calibrated estimators (O-RA section 4.3 describes calibration, starting from absurd estimates and narrowing, and the equivalent bet test) combined with data: incident history, control test results, business impact analysis for downtime costs, and legal advice for secondary loss.

Iterations, convergence and reproducibility

O-RA does not set an iteration count, referring only to thousands of outcomes. The right number depends on which statistic you report. The mean converges fastest; tail percentiles converge slowest because few iterations land there.

An illustrative single scenario, run by NHI Mgmt Group for this guide (loss event frequency PERT 0.2 / 0.6 / 2.0 a year, Poisson counts, log-normal loss per event with a 90% interval of £200,000 to £5 million, fixed seed), gave these 95th percentile annual losses as iterations increased:

• Convergence test: run the model with several seeds or in batches and confirm the percentiles you report move by less than an agreed tolerance (for example 2%). If they do not, add iterations.
• Tail statistics: a 99th percentile from 10,000 iterations rests on about 100 samples; use 50,000 or more if the 99th percentile drives a decision.
• Seeds and versions: record the random seed, tool version and input file for every published result so it can be reproduced and audited.
• Sampling methods: Latin hypercube sampling, offered by many spreadsheet add-ins, spreads samples across each input's range and can reach stable results with fewer iterations than simple random sampling.

Combining scenarios and handling dependencies

An enterprise view sums scenarios. Within each iteration, sample every scenario and add the annual totals, then build percentiles from the combined totals. Never add scenario percentiles together: the 95th percentile of the sum is not the sum of the 95th percentiles, and adding them overstates exposure when scenarios are independent.

• Independence is an assumption: many tools sample scenarios independently. That understates the tail when one root cause (a compromised identity provider, a shared managed service provider, a widespread outage) drives several scenarios at once.
• Model common causes explicitly: add a shared driver, such as a "supplier compromise" event that, when sampled, triggers losses in several scenarios in the same iteration. This is easier to explain than a correlation coefficient. See the Third-Party Concentration Risk Guide.
• Rank correlation: where a common cause cannot be modelled, apply rank correlation between scenario frequencies or losses, and test results with and without it.
• Controls: model a control by changing the inputs it affects (Vulnerability, frequency, or loss magnitude), run before and after with the same seed, and compare distributions. The FAIR-CAM Controls Analytics Model Guide covers how controls affect each factor.

Reading the outputs

O-RA (section 5.4) says analysts should provide data useful for the decision the stakeholder is trying to make, and lists presentation formats including the loss exceedance curve, a distribution curve and a tornado chart. It defines a loss exceedance result as a percentile threshold: if 10% of simulated years exceed £1 million, the 90th percentile threshold is £1 million.

• Loss exceedance curve: plots the probability (y axis) that annual loss exceeds each amount (x axis). Overlay a risk tolerance curve from the appetite statement to show where exposure is unacceptable. See the Cyber Risk Appetite Statement Template.
• Tornado or sensitivity chart: vary each input across its range while holding others at their central values and rank the effect on the mean or a chosen percentile. It tells you where better data or a control buys the most reduction.
• Before and after curves: the cleanest way to show a control's value is two curves on one chart, with the reduction at the percentile the board cares about.
• Language: say "in our model, one year in twenty exceeds £5.5 million", not "we will lose £5.5 million". Round results to two significant figures, consistent with O-RA's warning that results cannot be more precise than inputs.

Using results in decisions

• Control investment: compare the reduction in mean annual loss with the annual cost of the control, and show the change at the 95th percentile for tail-focused decisions.
• Insurance: compare the 95th and 99th percentile annual loss with retention and limit options; check which loss forms the policy covers before netting them. See the Cyber Insurance Guide.
• Risk appetite: express tolerance as a point or curve ("no more than a 5% chance of losses over £10 million in a year") and test the simulated curve against it.
• Board reporting: show the top scenarios by contribution to the 95th percentile, the trend since last quarter and what changed. See the Board Cyber Risk Reporting Guide.
• Small versus large organisations: a small organisation can run three to five scenarios in a spreadsheet with a simulation add-in; a large one with dozens of scenarios, controls and dependencies benefits from code under version control or a platform with an audit trail.

Tooling options

Validating the model and measuring the programme

1. Peer review inputs: have someone outside the analysis challenge every range and its source before running.
2. Sanity-check outputs: compare the simulated maximum and 99th percentile with the organisation's revenue, insurance limits and any published losses for comparable incidents; an unbounded log-normal can produce losses larger than the company.
3. Back-test: each year, compare actual incidents and losses with the frequencies and ranges used. Repeated surprises in one direction mean the estimators need recalibration.
4. Stress test: rerun with wider ranges, different distributions and dependency on, and report how conclusions change.
5. Govern changes: version inputs and code, record seeds, and keep an analysis log for audit.

Metrics: percentage of reported percentiles that pass the convergence test; calibration score of estimators (share of actual values falling inside their 90% ranges, target near 90%); share of inputs backed by internal data rather than opinion alone; number of risk decisions per quarter informed by a simulation; and year-on-year drift between modelled and actual incident frequency.

Framework mapping

Common failure patterns

• False precision: reporting "£1,230,451" from inputs that were rough ranges. Round, and show the range.
• Adding percentiles: summing each scenario's 95th percentile to get an enterprise figure, which overstates independent risks and hides the method error.
• Ignoring common causes: treating scenarios as independent when one identity provider or supplier compromise would trigger several at once, understating the tail.
• Unbounded tails: log-normal ranges so wide that simulated maxima exceed any credible loss, then presenting the maximum as meaningful.
• Too few iterations: quoting a 99th percentile from 1,000 iterations, which rests on about ten samples.
• Uncalibrated inputs: ranges from a single overconfident expert, which narrow the distribution and make the risk look smaller and more certain than it is.

Practitioner checklist

• Define each scenario so scenarios are mutually exclusive and tied to a decision.
• Collect inputs as calibrated 90% ranges, with the data source or estimator recorded for each.
• Choose distributions deliberately (PERT for rates, Poisson for counts, log-normal for losses) and document the fitting rule.
• Cap losses where contracts, policy limits or company size bound them.
• Run enough iterations for the reported percentiles to converge within an agreed tolerance, and record seeds and versions.
• Combine scenarios within each iteration and model common causes explicitly.
• Present a loss exceedance curve, two or three named percentiles and a sensitivity chart, rounded to two significant figures.
• Compare before and after control curves with the same seed to show value.
• Back-test annually against real incidents and recalibrate estimators.
• Keep inputs, code and results under version control with peer review.

Standards and references

• The Open Group: Risk Analysis (O-RA) Standard, Version 2.0.1
• The Open Group: Risk Taxonomy (O-RT) Standard
• NIST: IR 8286A Rev. 1, Identifying and Estimating Cybersecurity Risk for Enterprise Risk Management
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5
• IEC: IEC 31010:2019, Risk management, Risk assessment techniques
• Netflix Skunkworks: riskquant library

Related NHI Mgmt Group resources: Cyber Risk Quantification Guide · FAIR Model and Open FAIR Standard Guide · FAIR-CAM Controls Analytics Model Guide · Cyber Risk Quantification Platform Buyers Guide · Board Cyber Risk Reporting Guide