FAIR Model and Open FAIR Standard Guide (O-RT and O-RA)

Red, amber and green risk ratings cannot tell a board whether a control is worth its cost, because they do not measure how often loss happens or how large it is. FAIR (Factor Analysis of Information Risk) and its published form, the Open Group's Open FAIR standards, do: they define risk as the probable frequency and probable magnitude of future loss and give a method to estimate both in money. This guide explains the two standards (the Risk Taxonomy O-RT and the Risk Analysis O-RA), the factor tree, how an analysis is scoped, estimated and reported, how to apply it to identity and non-human identity scenarios, and how it maps to NIST CSF 2.0 and SP 800-53. It is for risk analysts, GRC leads and security architects. The broader case for quantification and tool choice is in the Cyber Risk Quantification Guide.

Key takeaways

Open FAIR is two standards. O-RT (Risk Taxonomy, current version 3.0.1) defines the factors and terms; O-RA (Risk Analysis, current version 2.0.1, C20A, November 2021) defines how to perform an analysis. Together they form the Open FAIR Body of Knowledge.
Risk has two branches. Loss Event Frequency (how often harm happens) and Loss Magnitude (how much it costs), each decomposed only as far as the data needs.
Scope narrowly. An analysis is about one loss scenario: a named asset, threat community, threat event and loss event. "Cyber risk" as a whole is not an analysable scenario.
Calibrated ranges, then Monte Carlo. Estimates are minimum, most likely and maximum values at about 90 per cent confidence, combined by simulation into a distribution of annual loss.
NHI scenarios suit FAIR well. Leaked keys and overprivileged service accounts have measurable contact frequency, susceptibility and loss forms, which makes the case for rotation or federation in financial terms.

What it is and who it applies to

FAIR began as a model for information risk and was adopted by The Open Group, which publishes it as two open standards and runs an Open FAIR certification programme. The FAIR Institute, a non-profit association, promotes the model and publishes extensions such as FAIR-CAM. No regulation mandates FAIR. It applies to anyone who wants risk expressed in financial terms: CISOs justifying investment, risk committees setting appetite, insurers and underwriters, and auditors testing whether a risk rating is supportable.

Document	Current version	What it defines
Open Group Risk Taxonomy (O-RT)	3.0.1 (C20B, November 2021)	Definitions and relationships of risk factors: LEF, TEF, Contact Frequency, Probability of Action, Vulnerability, Threat Capability, Resistance Strength, Loss Magnitude, primary and secondary loss, forms of loss
Open Group Risk Analysis (O-RA)	2.0.1 (C20A, November 2021)	The analysis process: scoping, estimation, calibration, Monte Carlo, controls modelling and reporting
Earlier set	O-RT 2.0 and O-RA 1.0	Basis of the original Open FAIR Foundation certification; the Open FAIR 2 Foundation certification is based on the current set
FAIR-CAM (FAIR Institute)	Extension, not an Open Group standard	How controls affect loss frequency and magnitude, measured in units such as frequency, probability or time

O-RT 3.0.1 made several changes from version 2.0: it removed "Accomplish Assigned Mission" as a threat agent action, renamed the external loss factor "Detection" to "External Party Detection", renamed the organisational loss factor "Due Diligence" to "Reasonable Care", removed a quantitative example that used a qualitative scale, and clarified terms. If your training material predates these changes, update the vocabulary.

Structure and key requirements

The factor tree

Factor	O-RT meaning	Decomposes into
Risk	The probable frequency and probable magnitude of future loss, from the Primary Stakeholder's perspective	Loss Event Frequency and Loss Magnitude
Loss Event Frequency (LEF)	How often, in a timeframe, a threat agent inflicts harm on an asset	Threat Event Frequency and Vulnerability
Threat Event Frequency (TEF)	How often a threat agent acts against an asset, whether or not it succeeds	Contact Frequency and Probability of Action
Contact Frequency (CF)	How often a threat agent comes into contact with the asset	Estimated directly
Probability of Action (PoA)	Probability that the threat agent acts once contact occurs	Estimated directly
Vulnerability (synonym: Susceptibility)	Probability that a threat event becomes a loss event	Threat Capability compared with Resistance Strength, Pr(TCap > RS)
Threat Capability (TCap)	Probable level of force a threat agent can apply, as a percentile of a threat community	Estimated directly
Resistance Strength (RS)	Strength of a control relative to the percentile of threat force it resists	Estimated directly
Loss Magnitude (LM)	Probable economic loss from a loss event, as a distribution	Primary Loss Magnitude and Secondary Loss
Secondary Loss	Loss from secondary stakeholders (regulators, customers, partners) reacting to the primary loss	Secondary Loss Event Frequency (a conditional probability) and Secondary Loss Magnitude

O-RT names six forms of loss: productivity, response, replacement, fines and judgments, competitive advantage and reputation. Every loss estimate should be built from these forms so that analysts do not double count or forget categories.

The analysis method in O-RA

Identify the loss scenario: name the Primary Stakeholder, asset, threat agent or community, threat event and loss event. O-RA advises keeping scope narrow.
Evaluate Loss Event Frequency: estimate LEF directly if you have data; otherwise estimate TEF and Vulnerability.
Evaluate Loss Magnitude: estimate primary loss and, where relevant, secondary loss, using the six forms.
Derive and articulate risk: run a Monte Carlo simulation and present results in the form the decision needs.
Model the effect of controls: O-RA groups controls as avoidance, deterrent, vulnerability and responsive, according to the factor they change.

Estimates: minimum, most likely and maximum, aiming for 90 per cent accuracy, so about 5 per cent of real outcomes fall below the minimum and 5 per cent above the maximum. Accuracy comes before precision.
Calibration: start with deliberately absurd ranges and narrow them while confidence holds; document assumptions.
Level of abstraction: work top-down and estimate at the highest level the data supports. Decompose only when the estimate is not usefully precise and better data exists lower in the tree.
Distributions: choose them to fit what is known, for example a log-normal distribution for a fat-tailed loss.
Reporting: averages, most likely values, percentile results such as the 90th percentile, loss exceedance curves and tornado charts for comparing options. O-RA warns that translating results back to qualitative labels can mislead and that management should approve any such scale.

Identity and NHI requirements

Open FAIR has no identity-specific clauses; it is a general model. Identity scenarios are among the easiest to analyse well, because many factors can be estimated from your own telemetry. The example below is hypothetical and its figures are illustrative, not benchmarks.

Element	Scenario: long-lived cloud access key leaked from a code repository
Asset	Production cloud account reachable with the key, holding customer data
Threat community	Opportunistic actors scanning public repositories for secrets
Contact Frequency	How often a key is exposed publicly: from your secret scanning history, for example 2 to 6 exposures a year, most likely 3
Probability of Action	Probability an exposed key is tested by an attacker before revocation: high for public repositories, for example 0.6 to 0.95
Vulnerability	Probability that use of the key causes loss: depends on its privileges and on whether network or conditional access restrictions apply, for example 0.2 to 0.7 for an overprivileged key
Primary loss forms	Response (investigation, rotation), productivity (service disruption), replacement (rebuild of affected resources), plus direct costs such as cloud resource abuse
Secondary loss	Probability of regulatory notification and customer reaction if data is accessed; fines and judgments and reputation forms
Controls to model	Push protection and scanning (lower contact frequency), federation to remove static keys (contact frequency towards zero for that class), least privilege (lower vulnerability), fast automated revocation (lower vulnerability and loss magnitude)

Running the scenario before and after removing static keys from pipelines gives a reduction in annualised loss exposure that can be set against the engineering cost. Real incidents help calibrate ranges: the LLMjacking campaigns show how quickly stolen cloud keys and API keys are put to use: in one test cited on that page, a deliberately exposed AWS key on GitHub was targeted within minutes, which supports a high Probability of Action range for public exposure. Good NHI scenarios to analyse include leaked secrets, overprivileged service accounts, compromised third-party OAuth integrations and AI agents with broad tool access. See the NHI Risk Scoring Guide for the asset-level scoring that feeds scenario selection, and the OWASP NHI Top 10 NHI7 Long-Lived Secrets Guide for the control side.

Implementation steps

Pick one decision: start with a real pending decision, such as whether to fund secrets rotation or a privileged access project, rather than trying to quantify the whole risk register.
Train two or three analysts: the Open FAIR Foundation certification gives a shared vocabulary. See the Open FAIR Foundation Certification Guide.
Agree loss tables with finance: pre-agree cost ranges for each form of loss (hourly cost of downtime, cost per record notified, incident response retainer rates) so every analysis uses the same figures.
Scope and estimate: write the scenario statement, estimate at the highest level your data supports and record the source of every range.
Simulate and challenge: run the Monte Carlo, then have someone outside the analysis challenge the ranges before results go to decision makers.
Report for the decision: show the current and proposed annualised loss distributions, the 90th percentile and the cost of the control.
Scale gradually: once two or three analyses have informed decisions, quantify the top risks on the register and link them to the risk appetite. See the Risk Appetite and Tolerance for Cyber Guide.

When to quantify and when not to: use Open FAIR when a decision involves material spend, a choice between options, a risk acceptance above a threshold or a question from the board about exposure in money. Stay qualitative for low-value screening, for risks where no one will act differently on a number, and where the scenario cannot be scoped tightly enough to estimate. The trade-off is analyst time: a well-scoped analysis takes days, not weeks, once loss tables exist, but the first few take longer.

Small and large organisations: a small organisation can run Open FAIR analyses in a spreadsheet with a Monte Carlo add-in for a handful of decisions a year. A large organisation usually needs a CRQ platform, a loss table maintained with finance and an analyst team; the method is the same.

Evidence and assessment

Open FAIR is not certified at organisation level; individuals are certified. Assessors and auditors look instead for a repeatable, documented method, which NIST CSF 2.0 GV.RM-06 calls "a standardized method for calculating, documenting, categorizing, and prioritizing cybersecurity risks".

Scenario records: each analysis with its scope statement, ranges, data sources, assumptions and analyst names.
Calibration evidence: training records and the challenge review for each analysis.
Loss tables: versioned and approved by finance.
Decision trail: which decisions each analysis informed, and the outcome.
Back-testing: comparison of estimated loss event frequency with actual incidents over time.

Useful measures: number of decisions informed by quantified analysis per year, percentage of top register risks with a current quantified analysis, median age of analyses, and how often actual annual losses fall outside the estimated 5th to 95th percentile range.

Mapping to other frameworks

Open FAIR element	NIST CSF 2.0	NIST SP 800-53 Rev. 5	Other
Standard method for calculating risk	GV.RM-06	PM-9 Risk Management Strategy, PM-28 Risk Framing	NIST IR 8286A Rev. 1 (final, December 2025) on estimating likelihood and impact for ERM
Loss Event Frequency and Loss Magnitude estimates	ID.RA-04, ID.RA-05	RA-3 Risk Assessment	Risk register entries. See the Risk Register Template.
Comparison of control options	ID.RA-06	RA-7 Risk Response	FAIR-CAM for control efficacy
Results against appetite	GV.RM-02, GV.RM-03	PM-9	Enterprise risk reporting. See the NIST IR 8286 Cybersecurity and ERM Integration Guide.
Back-testing and review	GV.OV-03	RA-3	Key risk indicators. See the Key Risk Indicators for Cyber Risk Guide.

Open FAIR complements rather than replaces qualitative methods such as NIST SP 800-30: many organisations screen risks qualitatively and quantify only those that drive investment decisions.

Common pitfalls

Scoping "ransomware" as one scenario: too broad to estimate. Split by asset, threat community and loss event.
False precision: presenting a single figure such as "£4.37 million" instead of a distribution with stated confidence.
Decomposing too far: estimating Contact Frequency and Probability of Action without data when a direct LEF estimate from incident history would be more accurate.
Uncalibrated estimators: ranges that are far too narrow because analysts have not practised calibration.
Mapping back to colours: converting results to red, amber and green without an approved scale, which O-RA warns can mislead.
Ignoring secondary loss: forgetting regulator and customer reactions, which often dominate data breach losses.

Practitioner checklist

Use the current O-RT 3.0.1 and O-RA 2.0.1 vocabulary in templates and training.
Choose one pending investment decision as the first analysis.
Agree a loss table for the six forms of loss with finance.
Write a scope statement naming asset, threat community, threat event and loss event for every analysis.
Record the data source and assumption behind every range.
Run an independent challenge of ranges before reporting.
Report distributions and percentiles, not single numbers.
Quantify at least one NHI scenario, such as leaked long-lived secrets, to test the case for federation or rotation.
Back-test estimates against actual incidents each year.

FAIR Model and Open FAIR Standard Guide: Taxonomy, Analysis Method and an NHI Worked Example