// 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
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
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
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.
- Sample a number of events for the year from the frequency distribution.
- For each event, sample a loss from the magnitude distribution.
- Add them up and record the year’s total.
- 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
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