Cyber Risk Quantification Guide: FAIR and Monte Carlo

A red cell on a heat map cannot tell a board whether a £2 million control is worth buying, but that is the question boards actually ask. Cyber risk quantification (CRQ) expresses cyber risk as a range of probable financial loss over a period, so it can be compared with other business risks, with risk appetite and with the cost of controls. This guide explains the FAIR model as standardised by The Open Group, how to scope loss scenarios, how to produce calibrated estimates, how Monte Carlo simulation and loss exceedance curves work, and how to present results without false precision. It is written for risk analysts, security architects and CISOs who need defensible numbers, and for GRC teams moving from qualitative registers to quantitative analysis.

Key takeaways

Quantify scenarios, not assets or threats. A FAIR analysis starts from a countable loss event: a named threat community, an asset and an observable effect.
Ranges beat point values. The Open Group Risk Analysis standard (O-RA) asks for estimates that are accurate 90% of the time, expressed as minimum, most likely and maximum, rather than a single "best guess".
Annualised loss expectancy hides the tail. A scenario with an expected loss of about £1.1 million a year can still carry roughly a one in twelve chance of losing more than £5 million. Loss exceedance curves show this; a single ALE figure does not.
Value controls by the change in risk. The worth of a control is the difference between simulated loss with and without it, which turns security spending into a return-on-investment discussion.
Calibrate people before you buy tools. The hard parts are scoping, estimation discipline and data. A spreadsheet with good inputs beats a platform with poor ones.

What cyber risk quantification is, and what it replaces

The Open Group Standard for Risk Taxonomy (O-RT) Version 3.0.1 defines risk as "The probable frequency and probable magnitude of future loss." CRQ is any method that estimates both parts in measurable units (events per year and money) and combines them into a distribution of possible outcomes. Open FAIR, the body of knowledge made up of O-RT and its companion Risk Analysis standard (O-RA) Version 2.0.1, is the main open model for doing this; insurer actuarial models and bespoke Monte Carlo models built on the same principles also count.

Approach	How risk is expressed	Strengths	Weaknesses
Qualitative	High, medium, low; 5x5 heat map	Fast, needs no data, familiar to auditors	Cannot be added up or compared with cost; ordinal scales invite arithmetic that is meaningless (3 x 4 is not "12 units of risk")
Semi-quantitative	Scores or bands mapped to numeric ranges (for example "likely" = 10% to 50% a year)	Easier transition, more consistent between assessors	Band edges create cliff effects; still hard to aggregate across scenarios
Classic quantitative (ALE)	SLE = asset value x exposure factor; ALE = SLE x annualised rate of occurrence	Simple, single money figure	Point estimates hide uncertainty and the tail; treats rare catastrophic and frequent small losses as equivalent if the product is the same
Stochastic quantitative (FAIR with Monte Carlo)	Distribution of annual loss; loss exceedance curve; percentiles	Shows uncertainty, tail risk and control value; aggregates across scenarios	Needs calibrated estimators, scenario discipline and some tooling

CRQ consumes the output of control assessments, vulnerability management and threat modelling rather than replacing them.

The FAIR model: factors and definitions

FAIR decomposes risk into factors that are easier to estimate than risk itself. Estimate at whichever level of the tree has the best data. Definitions below are from O-RT 3.0.1.

Factor	O-RT definition (summarised)	Unit	Typical evidence
Loss Event Frequency (LEF)	Probable frequency, within a timeframe, that a threat agent will inflict harm upon an asset	Events per year	Internal incident history, insurer and industry loss data
Threat Event Frequency (TEF)	Probable frequency that a threat agent will act against an asset	Events per year	Blocked attempts, phishing reports, WAF and authentication logs, threat intelligence
Contact Frequency and Probability of Action	How often a threat agent comes into contact with the asset, and the probability it acts once in contact	Events per year; percentage	Exposure data (internet-facing assets, number of users or credentials)
Vulnerability (Susceptibility)	The probability that a threat event becomes a loss event; the probability that Threat Capability exceeds Resistance Strength	Percentage	Penetration and red team results, control testing, phishing simulation rates
Threat Capability and Resistance Strength	Probable force a threat agent can apply, and the strength of a control expressed as a percentile of the threat population it resists	Percentile	Threat intelligence, control design reviews
Primary Loss Magnitude	Loss arising directly from the threat agent's action against the asset	Money per event	Incident response costs, outage cost per hour, replacement costs
Secondary Loss Event Frequency and Magnitude	Conditional probability that a primary loss leads to secondary stakeholders (regulators, customers, litigants) reacting, and the size of that reaction	Percentage; money per event	Legal and regulatory precedent, notification costs, customer churn

O-RT 3.0.1 also defines six forms of loss that keep magnitude estimates complete: productivity, response, replacement, fines and judgments, competitive advantage and reputation. Estimating each form with the business owner who would carry it stops analysts forgetting that an outage costs lost revenue as well as response fees.

Scoping a loss scenario

O-RA 2.0.1 describes scoping as "the process of identifying a countable, easily understandable Loss Event and risk scenario statement", built around the sentence: a threat agent breaches or impairs an asset, causing an observable loss event. It asks analysts to name the most probable threat communities rather than every conceivable one, and to split a scenario when asset types or observable losses differ.

Too broad: "Ransomware risk" mixes threat communities, entry points, assets and outcomes, so no one can estimate its frequency.
Well scoped: "Financially motivated cyber criminals use a stolen CI/CD pipeline token to exfiltrate the customer database, leading to regulatory notification and customer claims." It names the threat community, the asset, the vector and the effect.
Effect: pick one of confidentiality, integrity or availability per scenario. An outage of order processing and a theft of customer data have different loss profiles and different controls.
Timeframe: normally one year, so scenarios are comparable.
Source of every estimate: O-RA asks analysts to document the source of all estimates, so the analysis can be challenged and repeated.

Start with the scenarios in the top-right corner of the current heat map: familiar risks can be sense-checked by people who know the business, which earns credibility.

Estimating inputs: calibration, distributions and data

Calibrated estimates

O-RA treats accuracy as more important than precision: "To increase the probability that an estimate is accurate, reduce its precision." Each input is a range (minimum, most likely, maximum) that the estimator believes contains the true value 90% of the time, so the actual value should fall below the minimum no more than one time in twenty. The standard describes three techniques:

Start absurd and narrow: begin with a range that is obviously too wide (between zero and 1,000 incidents a year) and tighten each end until it is uncomfortable.
Decompose: if LEF is hard to estimate, estimate TEF and Vulnerability separately; if loss magnitude is hard, estimate each form of loss.
Equivalent bet (wheel test): would the estimator rather bet on the range, or spin a wheel with a 90% chance of winning? Preferring the wheel means the range is too narrow and should be widened.

Run a short calibration exercise (trivia questions answered as 90% ranges) with every estimator. Most people start overconfident, and feedback corrects this quickly: it is the cheapest improvement a CRQ programme can make.

Choosing distributions

O-RA is "agnostic on what distribution is 'right'" and gives examples: uniform when nothing else is known, log-normal for losses with a fat tail, and Poisson for event frequency. In practice most tools use one of these:

PERT (beta-PERT): takes minimum, most likely and maximum directly; mean = (min + 4 x most likely + max) / 6. Good default for frequencies and percentages.
Log-normal: for loss magnitudes where the maximum could be many times the most likely, such as regulatory fines or class actions. Usually parameterised from a 90% interval.
Poisson: to turn an annual rate (0.5 a year) into a count of events in each simulated year, including years with two or more events.

Where the data comes from

Input	Internal sources	External sources
Threat Event Frequency	SIEM and EDR detections, blocked logins, phishing reports, DLP alerts	Threat intelligence on campaigns against your sector
Vulnerability	Penetration and red team findings, control test results, phishing simulation click rates, patch latency	Exploitation data such as the CISA Known Exploited Vulnerabilities catalogue
Primary loss	Cost per hour of downtime (from the business impact analysis), incident response retainer rates, staff costs	Vendor and insurer incident cost studies (attribute them; methods vary)
Secondary loss	Legal counsel's view of notification and litigation costs, customer contract penalties	Published regulatory penalties and settlements for comparable incidents

The business impact analysis described in NIST IR 8286D, which assigns impact values to assets supporting mission objectives, is usually the best internal source for productivity losses.

Monte Carlo simulation and loss exceedance curves

O-RA requires Monte Carlo or another stochastic method to combine the inputs: the simulation "models thousands of outcomes consistent with those parameters and their distributions". Each iteration samples every input, works out how many loss events occur that year and what each costs, and records the annual total. Ten thousand or more iterations give a stable result.

A worked example

The scenario above (stolen CI/CD token, customer data exfiltration) with illustrative inputs:

TEF: 0.5 / 2 / 6 attempts a year (PERT)
Vulnerability: 10% / 20% / 35%
Primary loss per event: £150,000 / £400,000 / £2,000,000
Secondary loss event frequency: 30% / 50% / 70%
Secondary loss per event: £200,000 / £1,200,000 / £15,000,000

A 100,000-iteration simulation of these inputs (PERT distributions, Poisson event counts) gives a mean annual loss of about £1.15 million. An ALE calculation gives the same figure. The distribution says much more: about 62% of simulated years have no loss at all, the 90th percentile is about £4.4 million, the 95th about £6.6 million, and there is roughly an 8% chance of losing more than £5 million in a year. Plotting the probability of exceeding each loss amount gives the loss exceedance curve, one of the presentation formats O-RA names alongside the distribution curve and tornado chart.

A high percentile of annual loss (often the 95th) is sometimes called cyber value at risk by analogy with financial VaR. Define one percentile in your methodology and use it consistently.

Valuing a control

Replacing the long-lived pipeline token with short-lived federated credentials mainly reduces Vulnerability. Re-running the same model with Vulnerability at 3% / 5% / 10% drops the mean annual loss to about £0.3 million and the chance of a loss above £5 million to about 2%. The difference, roughly £850,000 a year in expected loss and a much thinner tail, is the value of the control to set against its cost. The FAIR Controls Analytics Model (FAIR-CAM) separates loss event controls (prevention, detection, response), variance management controls that keep other controls working, and decision support controls, and notes that "Loss events only occur when controls are missing, fail, or are insufficient." Model a control's operational efficacy, not its intended efficacy.

Communicating risk in financial terms

NIST CSF 2.0 subcategory GV.RM-02 expects risk appetite and risk tolerance statements to be established, communicated and maintained, and GV.RM-06 expects a standardised method for calculating, documenting, categorising and prioritising cybersecurity risks. CRQ gives both a concrete form:

Appetite in money: "We accept no more than a 10% chance of a cyber loss above £20 million in any year." This is a point on an aggregate loss exceedance curve, and the curve can be checked against it each quarter.
Register entries: NIST IR 8286A Rev. 1 and IR 8286B describe recording likelihood and impact in a cybersecurity risk register that feeds the enterprise risk register. Store the inputs, distributions and outputs (mean, chosen percentile, probability of exceeding tolerance), not only a final number.
Decision framing: present options: "Option A costs £400,000 a year and cuts expected loss by £850,000; option B costs £150,000 and cuts it by £300,000."
Show uncertainty honestly: report ranges and use a tornado chart to show which inputs drive them.
Disclosure: US public companies describe their cyber risk assessment processes under Regulation S-K Item 106 and generally file Form 8-K Item 1.05 within four business days of deciding an incident is material. Quantified scenarios help disclosure committees, but materiality stays a legal judgement.

The scale of tail losses is not theoretical: the Marks and Spencer cyberattack in 2025 was reported to have cost around £300 million, a figure no qualitative rating would have conveyed. See the Business Case Guide for turning these figures into an investment case.

Where identity fits

Many high-frequency loss scenarios start with a credential: a phished login, a help desk reset, a leaked API key or an over-privileged service account. Identity telemetry is a rich source of estimates:

Threat Event Frequency: password spraying and credential stuffing volumes, MFA push denials, secret-scanning alerts for leaked keys.
Vulnerability: the share of privileged accounts without phishing-resistant MFA, the share of non-human identities with long-lived static credentials or no owner, the time to revoke credentials after a leaver.
Loss magnitude: what data and systems a compromised account could reach drives primary loss.

See the Identity Security Metrics Guide and the Service Account Security Guide.

Implementing a CRQ programme

Phased rollout

Agree the decision. Choose one decision CRQ will inform in the first six months (a budget allocation, an insurance limit, a control investment).
Write the methodology. Document the taxonomy (O-RT), timeframe, distributions, iteration count, chosen percentile and how estimates are sourced and reviewed. This is your GV.RM-06 artefact.
Calibrate estimators. Train everyone who will supply estimates (security, IT operations, finance, legal, business owners) and measure calibration before and after.
Pilot on five scenarios. Pick scenarios with reasonable data and senior interest. Run them in parallel with the existing qualitative register, not instead of it.
Test the results. Sense-check outputs with finance and business owners, compare simulated frequencies with incident history, run sensitivity analysis and peer-review each analysis.
Extend and aggregate. Grow to 20 to 40 scenarios covering the top of the register, then aggregate them into an enterprise loss exceedance curve to compare with appetite.
Embed. Use CRQ in budgeting, insurance renewal and exception approvals; refresh inputs quarterly and after major incidents.
Keep a rollback path. Keep the qualitative ratings until leadership has accepted at least one budget cycle of quantified results. If a model is found to be wrong, withdraw its figures, correct the inputs and reissue with a change note rather than quietly revising numbers already reported.

Choosing an approach and tooling

Option	Best fit	Trade-offs
Spreadsheet or script (Python, R) Monte Carlo	Small and mid-sized organisations; teams learning FAIR; up to about 20 scenarios	Cheap and transparent; key-person risk, version control and aggregation are on you
Open-source or community FAIR tools	Teams that want structure without licence cost	Varying maintenance and support; check the maths before relying on it
Commercial CRQ platforms	Large organisations with many scenarios, business units and reporting lines	Workflow, libraries and integrations; risk of treating vendor default loss tables as your own data. Ask how every default was derived
Outside-in scoring or insurer models	Third-party risk, insurance negotiation	External signals only; no substitute for your own scenarios

Small organisations: quantify three to five scenarios that matter to the board (ransomware outage, payment fraud, customer data theft). The value is in the conversation, not the tooling.
Large organisations: standardise the methodology centrally, let business units own scenarios, and invest in data feeds so inputs are refreshed rather than re-estimated.
Choose FAIR over ALE whenever the decision depends on rare, severe outcomes (insurance limits, appetite thresholds). ALE is acceptable for frequent, low-variance losses such as lost laptops.

Measurement and framework mapping

Measuring whether CRQ is working

Decision coverage: the percentage of security investments above an agreed threshold that were supported by a quantified analysis.
Estimator calibration: the share of estimators' 90% ranges that contain the true answer in calibration tests; aim for 80% to 90%.
Back-testing: how often actual annual losses and incident counts fall within the simulated 90% interval.
Scenario freshness: the percentage of top scenarios with inputs reviewed in the last quarter.
Position against appetite: the aggregate probability of exceeding the tolerance threshold, tracked over time.
Realised control value: for funded controls, the change in modelled loss after deployment using measured operational efficacy.

Framework mapping

Framework	Reference	What CRQ contributes
NIST CSF 2.0	GV.RM-02, GV.RM-03, GV.RM-06	Appetite and tolerance in money; cyber risk expressed in ERM terms; a documented, standard calculation method
NIST CSF 2.0	ID.RA-04, ID.RA-05	Recorded likelihoods and impacts; inherent risk used to prioritise response
NIST SP 800-53 Rev. 5	RA-3 Risk Assessment, RA-7 Risk Response, PM-9 Risk Management Strategy, PM-28 Risk Framing	Quantified assessment, response prioritisation and risk tolerance
NIST IR 8286 series	IR 8286A Rev. 1, 8286B, 8286D	Cybersecurity risk register feeding the enterprise risk register; BIA-derived impact values
ISO/IEC 27001:2022	Clauses 6.1.2, 6.1.3, 8.2, 8.3	Risk assessment and treatment method that produces consistent, valid and comparable results
ISO/IEC 27005:2022	Risk management guidance	Quantitative risk analysis and evaluation
US SEC rules (2023)	Regulation S-K Item 106; Form 8-K Item 1.05	Evidence of a risk assessment process; structured input to materiality discussions

Common failure patterns

Quantifying the heat map: converting "high" to £10 million and multiplying by a likelihood score. This keeps every flaw of ordinal scales and adds false precision.
Scenarios that cannot be counted: "insider threat" as one scenario, so each estimator imagines a different event.
Forgetting productivity and secondary losses: estimating only response costs. Large incidents are dominated by business interruption: the MGM Resorts breach was reported as a $100 million loss and the Jaguar Land Rover cyberattack halted global production, both far beyond any incident response invoice.
Overconfident ranges: narrow ranges look authoritative but miss the true value far more than 10% of the time, understating the tail.
Accepting tool defaults as data: embedded industry loss tables may not reflect your revenue, sector or jurisdiction.
Reporting one number: the mean alone hides tail risk; switching between mean and percentile erodes trust.

Practitioner checklist

Write a CRQ methodology based on O-RT and O-RA: timeframe, distributions, iterations, reporting percentile and estimate sourcing.
Calibrate every estimator with 90% range exercises before they provide inputs.
Scope each scenario as threat community, asset, effect and observable loss.
Estimate all six forms of loss with the business owners who would bear them.
Run Monte Carlo simulation and present loss exceedance curves, not only annualised loss expectancy.
State risk appetite as a probability of exceeding a money threshold and track the aggregate curve against it.
Value each proposed control as the change in simulated loss, using realistic operational efficacy.
Pilot alongside the qualitative register and keep it until quantified results have survived a budget cycle.
Back-test scenarios against actual incidents and refresh inputs at least quarterly.

Standards and references

Related NHI Mgmt Group resources: Business Case Guide · Identity Security Metrics Guide · Identity Security Programme Guide · Board and CISO Briefing