RaptorGRC — Offline GRC

// BLOG

Monte Carlo Risk Assessment How to Actually Run One

Published 30 July 2026

Monte Carlo Risk Assessment: How to Actually Run One

Illustration for: Monte Carlo Risk Assessment, How to Actually Run One

Illustration for: Monte Carlo Risk Assessment, How to Actually Run One

Ask a risk register how much a bad year could cost and it will answer with a colour. Amber, probably. Amber does not tell the board whether to buy the £120,000 control, whether the cyber insurance limit is adequate, or whether the risk sits inside appetite. A Monte Carlo simulation answers those questions directly, because instead of scoring the risk once it lives through the year ten thousand times and reports back what happened. I made the general case for quantification in an earlier post in this series. This one is the practical deep dive, the four steps from a vague worry to a loss exceedance curve, with the traps marked along the way.

What the simulation actually does

The idea is older than the computers that made it useful. Stanislaw Ulam, recovering from illness in 1946, wondered whether the odds of winning at solitaire could be found by simply playing a hundred hands and counting. He and John von Neumann applied the same trick to neutron physics at Los Alamos, and the code name for the method came from the casino where Ulam’s uncle gambled.

Applied to risk, it works like this. You cannot know exactly how many ransomware incidents you will suffer next year or exactly what each will cost. But you can estimate ranges for both, and you can describe how likely the values inside each range are. The simulation then samples a random value from each range, plays out one hypothetical year, records the total loss, and repeats the process ten thousand times. No single trial is a prediction. The pile of ten thousand trials, sorted, is a probability distribution of annual loss, and that is something you can set against a risk appetite, an insurance limit, or the price of a control.

Four step flow diagram of a Monte Carlo risk analysis, from defining the event to reading the results

Four step flow diagram of a Monte Carlo risk analysis, from defining the event to reading the results

The whole method in four steps. Everything difficult lives in the first two, everything the board sees comes out of the last one.

There is no advanced mathematics in the loop. The craft is entirely in what you feed it.

Step one, define the loss event

Vague risks cannot be simulated, which turns out to be a feature. “Cyber risk” has no frequency and no magnitude because it is not an event. “Ransomware encrypts the ERP estate and halts order processing until systems are restored” is an event. You can ask how often something like it happens to organisations like yours, and what it costs when it does.

Be precise about the boundary. Does the event include incidents your EDR contains in minutes, or only those that reach encryption? Does the cost include ransom payment, or is your position that you will never pay? Half the value of a quantitative exercise is that these questions get asked and answered in writing before anyone touches a spreadsheet. In my experience the definition step alone kills a quarter of a typical register, because entries dissolve on contact with the question “what would actually have happened”.

Step two, estimate ranges you can defend

You need two estimates, how often the event occurs and how much it costs when it does, and both should be ranges, not points. The standard form is a 90 per cent confidence interval. For frequency that might be “between once in ten years and twice a year”. For magnitude, “between £150,000 and £4 million per event”.

Calibration matters more than data volume. Most people are badly overconfident, giving 90 per cent intervals that contain the true value less than half the time. Douglas Hubbard’s work showed that a few hours of calibration training, practising against questions with known answers, largely fixes this. Do the training before the estimation workshop, not after the first embarrassing result.

You have more data than you think. Your own incident history, sector breach reports, insurer claims data, regulator enforcement notices and your last penetration test all bound the plausible range. The common objection, that quantification is impossible without perfect data, gets the logic backwards. If you genuinely knew nothing about frequency or magnitude, you could not have put the risk on the register in the first place. Ranges exist precisely to carry honest uncertainty.

Write every assumption down. The range, the sources, who estimated it and when. The simulation will be challenged, and the defence is the audit trail behind the inputs, not the elegance of the outputs.

Step three, give each range a shape

A range says where values can fall. A distribution says how likely each part of the range is, and choosing a sensible shape is where most practical guidance stops short.

Input

Shape to use

Why

Event frequency

Poisson

Counts of independent events per year

Loss magnitude

Lognormal

Skewed, heavy tailed, never negative

Workshop estimates

PERT from low, likely, high

Smooth curve from three defensible points

Simple yes or no

Bernoulli

Did the event happen at all this year

The important argument is against the familiar bell curve. Losses are not normally distributed. A normal distribution is symmetric, allows negative losses, and makes catastrophic outcomes vanishingly rare. Real loss data is skewed the other way, many small events and a long tail of rare, enormous ones, which is exactly what a lognormal distribution describes. Feed a normal distribution into your model and it will quietly assure you that the disaster scenario is impossible. That assurance is worth nothing.

A skewed probability curve built from three estimate points labelled low, likely and high

A skewed probability curve built from three estimate points labelled low, likely and high

Three defensible numbers from a workshop become a full curve. The long tail on the right is the part your board most needs to see.

Step four, run the trials

The loop itself is short enough to describe completely.

  1. Sample a number of events for the year from the frequency distribution.
  2. For each event, sample a loss from the magnitude distribution.
  3. Add them up and record the year’s total.
  4. Repeat ten thousand times, then sort the results.

Excel can do this with data tables or add-ins, Python and R do it in a dozen lines, and the FAIR ecosystem offers purpose-built tooling. The tool does not matter. Ten thousand trials gives stable percentiles and runs in seconds.

Reading the outputs

The standard presentation is the loss exceedance curve, which plots every possible annual loss against the probability of exceeding it. It slopes downward, small losses are near certain, enormous ones are rare, and every point on it is a plain sentence. “There is a 10% chance that annual losses from this risk exceed £2.1 million.”

Downward sloping loss exceedance curve with a marked risk appetite point

Downward sloping loss exceedance curve with a marked risk appetite point

One curve, three decisions. Where the curve crosses appetite tells you whether to act, the tail tells you what insurance limit you need, and the gap between two curves prices a control.

Draw your risk appetite on the same chart and the conversation changes character. A manufacturing client I worked with had argued for a year about whether a legacy plant network was “red or amber”. The curve showed a one in eight chance of exceeding their stated £1 million annual tolerance, and the argument ended in one meeting because the question was finally in the same units as the appetite statement.

The deepest value comes from running the model twice. Simulate the risk with and without a proposed control, and the horizontal gap between the two curves is the control’s benefit in pounds, ready to set against its cost. No colour scale on earth can do that.

The honest counterarguments

Garbage in, garbage out is true. The simulation cannot rescue bad estimates, it can only combine them honestly. The fair response is that a qualitative score is built from the same guesses with the uncertainty hidden. Monte Carlo does not add rubbish, it makes existing rubbish visible and challengeable.

False precision is a real hazard. A percentile quoted to the pound invites more confidence than expert ranges can support. Report rounded figures and full ranges, and say “roughly” out loud in board papers.

The effort is genuine. A defensible analysis takes half a day to two days per risk. Nobody should quantify a 200-row register. Reserve the method for the risks where a decision with real money attached is waiting on the answer.

Naive models understate the tail. Simulating risks independently ignores the fact that bad years correlate, one incident triggers another, and a single cause fires several risks at once. Treat portfolio-level totals from independent models with suspicion, and say so in the caveats.

Where this leaves the humble matrix

Nothing here retires qualitative assessment. Triage still belongs to the matrix, breadth is its virtue, and most of the register never needs more. But for the handful of risks where the business is about to spend serious money, accept a large exposure, or set an insurance limit, a colour is not an answer. Ten thousand simulated years, built on ranges someone was willing to sign, turn the question into pounds and probabilities, which is the language the decision was always going to be made in. The board can still choose to accept the risk. The difference is that they will know what they accepted, it will be written down, and a deliberate decision recorded in numbers beats an accidental default rated amber.

Run your GRC programme in your own network.

RaptorGRC Community Edition is free — every module, offline licence activation, nothing phones home.

Register / Download Contact us
An unhandled error has occurred. Reload 🗙

Rejoining the server...

Rejoin failed... trying again in seconds.

Failed to rejoin.
Please retry or reload the page.

The session has been paused by the server.

Failed to resume the session.
Please retry or reload the page.