Inside the FAIR Monte Carlo: How 10,000 Simulations Turn Security Judgment Into a Risk Number

Why FAIR needs Monte Carlo at all

If you ask a security team for the annual risk of a data breach, you usually get a single number: $2.4 million. That number is a lie, and everyone knows it. It implies a precision that doesn't exist. The real answer is a range: somewhere between $200,000 and $12 million, with a lot of uncertainty in between.

FAIR (Factor Analysis of Information Risk) exists to make that uncertainty explicit. It breaks risk into two components: loss event frequency (how often a bad thing happens) and loss magnitude (how bad it is when it does). Each of those components is itself a range, not a point. The Monte Carlo simulation is the engine that combines those ranges into a single, defensible distribution of possible outcomes.

Without Monte Carlo, you'd be stuck doing arithmetic on averages. That would give you a number that is mathematically correct but practically useless. For example, if you have a 10% chance of losing $10 million and a 90% chance of losing $0, the average is $1 million. But that average doesn't tell you the most likely outcome (which is $0) or the worst case (which is $10 million). A board needs to know both. Monte Carlo gives you the full picture.

This isn't about being more precise. It's about being honest. That's a conversation a CFO can respect.

When you present a range to your board, you're really saying: “We don't know exactly, but we know the shape of the uncertainty, and we're planning for the tail.”

The inputs are ranges, not numbers

FAIR defines six factors that feed into the model. For each, you provide a range, not a single estimate. The standard approach is to use a PERT or triangular distribution, defined by three values: minimum, most likely, and maximum.

Here are the inputs you'll be calibrating:

• Loss Event Frequency (LEF) — How often the event occurs per year. This is itself derived from Threat Event Frequency (TEF) and Vulnerability (Vuln).
• Threat Event Frequency (TEF) — How often a threat actor attempts the event.
• Vulnerability (Vuln) — The probability that an attempt succeeds, given it occurs.
• Loss Magnitude (LM) — The financial impact when the event occurs. This splits into Primary Loss (direct costs) and Secondary Loss (downstream effects).

For each input, you'll specify a minimum, most likely, and maximum. For example, for TEF you might say: "We see phishing attempts against our finance team about 20 times a month, but it could be as low as 5 or as high as 50." That gives you a triangular distribution with min=60, most likely=240, max=600 per year.

The PERT distribution is similar but gives more weight to the most likely value, which is often more realistic for expert estimates. It uses the same three points but calculates a different shape. Either works; the key is that you're capturing uncertainty, not pretending you know the exact number.

Calibration is the hard part. The simulation is only as good as the inputs. If your ranges are too narrow, you'll get false confidence. If they're too wide, the output will be so broad it's useless. This is why we spend time on calibration training — it's a separate discipline, but it's the foundation of any credible FAIR analysis. You can learn more about that in our risk assessment practice.

What the simulation actually does

Once you have your input distributions, the Monte Carlo simulation runs thousands of iterations. Here's the step-by-step:

1. For each iteration (say, 10,000 times), the simulation randomly samples a value from each input distribution.
2. It then propagates those samples through the FAIR equation: LEF = TEF × Vuln, and Risk = LEF × LM (with LM split into primary and secondary).
3. It records the resulting risk value for that iteration.
4. After all iterations, it aggregates the 10,000 results into a distribution of possible annual risk.

This is where the central limit theorem kicks in. Even if your input distributions are skewed (which they usually are), the distribution of the sum or product of many random variables tends toward a normal distribution as the number of iterations grows. That's why 10,000 iterations give you a stable, smooth output curve.

Let's be concrete. Suppose you have a LEF range of 0.1 to 5 events per year, and a LM range of $100,000 to $10 million. The simulation will produce a distribution of annual loss that might look like this: a median of $400,000, a mean of $1.2 million, and a 90th percentile of $3.5 million. Those three numbers tell a very different story than any single point estimate.

The simulation doesn't just give you one number. It gives you the entire probability curve. That curve is what you need to make informed decisions about insurance, budget, and risk tolerance.

Reading the output: the loss exceedance curve

The primary output of a FAIR Monte Carlo is the loss exceedance curve (LEC). It plots the probability that loss will exceed a given amount. For example, the curve might show that there's a 90% chance loss will be under $2 million, and a 10% chance it will exceed $5 million.

From the LEC, you can extract key metrics:

• Mean (expected loss) — The average of all simulated outcomes. This is what you'd use for budgeting or insurance pricing.
• 90th percentile (VaR) — The loss level that you expect to exceed only 10% of the time. This is the number to plan for if you want to be conservative.
• Median (50th percentile) — The midpoint. This is often lower than the mean because the distribution is right-skewed (rare, large losses pull the mean up).

Why not plan on the median? Because the median ignores the tail. If the median is $400,000 but there's a 10% chance of losing $5 million, planning on $400,000 leaves you exposed. The 90th percentile captures that tail risk. For a board, the 90th percentile is often the number that drives the decision: "We need to reserve $3 million to cover a 1-in-10 year event."

Here's a sample table to illustrate how the metrics differ:

When you present this to your board, don't just give them the mean. Show them the LEC and explain what each percentile means. That's how you turn a risk number into a business decision.

Confidence and convergence: when have you run enough?

How many iterations do you need? The answer is: enough that the percentiles stabilize. If you run 1,000 iterations and then 10,000, the 90th percentile should not move by more than a few percent. If it does, you need more iterations.

In practice, 10,000 iterations is usually sufficient for most FAIR analyses. The standard error of the percentile estimates decreases with the square root of the number of iterations. So going from 1,000 to 10,000 reduces the error by about a factor of 3. Going from 10,000 to 100,000 only reduces it by another factor of 3, which is rarely worth the compute time.

Here's a quick rule of thumb:

• 1,000 iterations — Good for a rough sense, but percentiles may wobble.
• 10,000 iterations — Standard for a defensible analysis.
• 100,000 iterations — Only if you need extreme tail precision (e.g., 99.9th percentile).

You can check convergence by running the simulation multiple times with the same inputs and comparing the outputs. If the 90th percentile varies by less than 5% between runs, you're converged. If not, increase the iteration count.

This is also where you validate your model. If the output distribution looks weird — say, a spike at zero or a bimodal shape — that's a sign your inputs are mis-specified. Go back and check your ranges.

Common Monte Carlo mistakes and how to catch them

Even experienced practitioners make mistakes. Here are the most common ones and how to spot them:

1. Using point estimates instead of ranges

If you input a single number for LEF or LM, the simulation becomes deterministic — it just multiplies those numbers. That defeats the purpose. Always use a distribution. If you're tempted to use a point estimate, ask yourself: "Do I really know this to the dollar?" The answer is almost always no.

2. Ignoring correlation between inputs

In reality, inputs are often correlated. For example, if threat event frequency goes up, vulnerability might also go up because attackers are more active. The standard FAIR model assumes independence, which can understate risk. If you suspect correlation, you need to model it explicitly. This is advanced, but it's worth flagging to your board as a limitation.

3. Overly narrow ranges

People tend to be overconfident. They set a min and max that are too close to the most likely value. This produces a deceptively tight output distribution. To catch this, ask: "What's the 1-in-100 scenario?" If your max doesn't cover that, widen it.

4. Misinterpreting the mean

The mean is not the most likely outcome. In a skewed distribution, the mean is pulled by rare, large losses. If you present the mean as "the risk," you'll overstate the typical year. Always present the median alongside the mean.

5. Not validating against historical data

If you have historical loss data, compare your simulated distribution to it. If your 90th percentile is way off from what actually happened, your inputs are probably wrong. This is a sanity check that catches many errors.

6. Treating the output as a measurement

Monte Carlo is modeling, not measurement. The output is a function of your inputs. If your inputs are judgment-based, the output is judgment-based. That doesn't make it useless — it makes it a structured way to reason about uncertainty. But you must be honest about that when presenting to the board.

To avoid these mistakes, document your assumptions and ranges. Show your work. That's what makes a FAIR analysis defensible in an audit or a board meeting.