Framework

FAIR (Factor Analysis of Information Risk)
Quantitative cyber risk on one operating record

Factor Analysis of Information Risk (FAIR) is the most widely adopted quantitative cyber risk methodology and the model most enterprise programmes converge on when they need to express cyber risk in financial terms. FAIR is maintained by the FAIR Institute and the Open Group (Open FAIR, the certified analyst stream), is referenced by NIST and ISO, and is methodology-only: it works in spreadsheets, commercial CRQ platforms, and open-source Monte Carlo libraries. This page covers the FAIR ontology, the FAIR Lite variant, the inputs a programme has to feed the model, the audit and board evidence the methodology produces, how FAIR sits next to ISO 31000, NIST SP 800-30, COSO ERM, and NIST AI RMF, and how to run FAIR against an operating security record rather than against a snapshot.

Get Started Free

No credit card required. Free plan available forever.

FAIR (Factor Analysis of Information Risk) explained

Factor Analysis of Information Risk (FAIR) is the most widely adopted methodology for quantitative cyber risk analysis. The methodology is maintained by the FAIR Institute and the Open Group (through the Open FAIR analyst certification stream), is referenced by NIST and ISO, and is the model most enterprise programmes converge on when they need to express cyber risk in financial terms rather than in qualitative high, medium, low language. FAIR is methodology-only: the same ontology runs in a spreadsheet, in a commercial Cyber Risk Quantification (CRQ) platform, or in an open-source Monte Carlo library. The discipline lives in the inputs and the ontology, not in the tool.

For CISOs, GRC owners, enterprise risk management teams, vulnerability management teams, AppSec teams, and the board reading the output, FAIR is the vocabulary that connects the engineering-side security record to the financial expression the executive layer consumes. Programmes already running the cyber risk quantification programme or holding the COSO ERM portfolio view typically adopt FAIR (or another quantitative method) as the engine that produces the financial output. FAIR is complementary to, not a replacement for, CVSS, EPSS, and CISA KEV; those produce the inputs FAIR combines into the financial estimate the board reads.

The FAIR ontology: how the model decomposes

FAIR decomposes risk into a small set of named factors with explicit relationships. The ontology is the discipline that prevents the analysis from collapsing into a single defended number; each node accepts a distribution that combines into the next level via Monte Carlo simulation. Analysts work the ontology top-down to scope the analysis and bottom-up to defend the inputs.

Risk (top-level)

The probable frequency and probable magnitude of future loss. FAIR resists collapsing risk into a single point estimate; the top-level node accepts a distribution that decomposes downward into the factors that produce it. Programmes that try to short-cut the decomposition and quantify risk directly typically end up arguing about the number rather than about the inputs that produced it.

Loss Event Frequency (LEF)

The probable frequency, within a given time-frame, that a threat agent will inflict harm on the asset. LEF further decomposes into threat event frequency and vulnerability. LEF carries the question how often a loss event occurs, with the explicit separation between how often the actor tries and how often the attempt succeeds.

Threat Event Frequency (TEF)

The probable frequency, within a given time-frame, that a threat agent will act against an asset. TEF reads against threat intelligence, MITRE ATT&CK technique prevalence, peer breach data, internal incident history, and the kind of asset the scenario covers. TEF is not the same as a CVE being exploited in the wild; TEF is the actor-side rate that drives the analysis.

Vulnerability (V)

The probability that a threat event becomes a loss event, given the controls in place. Vulnerability reads against the control coverage evidence, the control efficacy record, the exception register entries, the patch state, and the live operating posture. The discipline FAIR enforces is that vulnerability is a conditional probability, not a point statement about how many CVEs exist on the asset.

Threat Capability and Resistance Strength

Vulnerability decomposes further into threat capability (the skills, resources, and motivation of the threat community) and resistance strength (the strength of the controls in place against that capability). The decomposition is the analyst path when the headline vulnerability estimate cannot be defended directly; it surfaces where the control investment changes either the capability the actor brings or the resistance the controls produce.

Loss Magnitude (LM)

The probable magnitude of primary and secondary loss resulting from an event. LM decomposes into primary loss and secondary loss. The discipline FAIR enforces is that magnitude is paired explicitly with frequency in the top-level model; programmes that estimate magnitude in isolation tend to produce numbers that cannot be combined into expected annual loss.

Primary Loss

The direct cost the organisation incurs when the loss event occurs: incident response cost, productivity loss during outages, replacement cost for damaged assets, contractual penalties borne directly, lost competitive advantage, regulatory fines borne directly. Primary loss is usually the easier of the two to defend because the inputs come from incident history, finance records, and contract terms.

Secondary Loss

The loss that arises because secondary stakeholders react to the event. Secondary loss covers regulatory penalties beyond the direct response cost, civil litigation, customer churn, brand damage, increased insurance premiums, and secondary contractual penalties cascading from the primary event. Secondary loss is usually the larger number and the harder one to defend; the discipline of separating it from primary loss is what keeps the analysis honest.

FAIR vs FAIR Lite: the pragmatic adoption variant

FAIR Lite is the variant most enterprise programmes start with. It uses the same ontology but accepts ranges (minimum, most-likely, maximum) per leaf input rather than full distributions. The output is still a Monte Carlo combination with confidence bands; only the input specification is relaxed. FAIR Lite is the recommended entry point because it surfaces the input gaps rather than forcing analysts to invent precision the underlying signal cannot support.

FAIR uses full distributions per leaf input. FAIR Lite uses ranges (minimum, most-likely, maximum) per leaf input. The combination is the same Monte Carlo logic; only the input specification differs.
FAIR Lite is the pragmatic entry point. Most programmes run FAIR Lite for the first two cycles and only adopt full distributions for the small set of scenarios where the inputs are mature enough to support the precision.
FAIR Lite makes the input gaps visible. Programmes discover where the underlying signal is weak by attempting the range estimate and finding the range has to span an order of magnitude. The fix is to improve the input source, not to invent more precision.
FAIR Lite supports calibration training. Analysts trained on calibrated estimation (the discipline of producing ranges with stated confidence) produce input ranges that hold up under audit; analysts who guess produce ranges that collapse the first time the assumptions are challenged.
FAIR Lite output is still defensible. The output is a distribution with confidence bands rather than a point estimate. Programmes that report FAIR Lite output as point estimates lose the methodology value; the value is the explicit uncertainty around the estimate.

Where FAIR sits next to ISO 31000, NIST SP 800-30, RMF, COSO ERM, and AI RMF

FAIR is an analytical method, not a process framework. The adjacent frameworks cover the governance, the process, and the operating sequence the method runs inside. Programmes that adopt FAIR without naming the surrounding process layer get challenged the first time an auditor asks where the analysis sits in the enterprise risk management lifecycle. The matrix below names the most common adjacencies and the responsibility split each pair carries.

ISO 31000 (Risk Management)

The umbrella standard for enterprise risk management. ISO 31000 is process and principle, not method. FAIR is one of the analytical methods the standard mentions; programmes follow ISO 31000 at the governance and process layer and apply FAIR at the analysis layer for the scenarios that warrant quantitative treatment.

NIST SP 800-30 (Risk Assessment)

The federal guide to conducting risk assessments. 800-30 supports both qualitative and quantitative approaches and does not prescribe a quantitative method. FAIR is the most common operationalisation of the quantitative path within 800-30; federal programmes typically reference 800-30 for the process and FAIR for the method when quantitative analysis is required.

NIST SP 800-39 and NIST SP 800-37 (RMF)

NIST 800-39 sits above 800-30 as the strategic enterprise risk management guide. NIST 800-37 (RMF) sits below 800-30 as the operating sequence for federal systems. FAIR contributes to the risk assessment work in 800-30 and to the residual risk determination the Authorising Official reads against in the RMF Authorise step.

COSO ERM

The enterprise risk management framework boards and audit committees read against for cross-organisation risk. COSO ERM does not prescribe a quantification method, but Principle 11 (Assesses Severity of Risk) and Principle 14 (Develops Portfolio View) read well against quantitative output. Programmes that adopt FAIR or another quantification method use it as the engine that produces the severity and portfolio inputs COSO ERM expects.

NIST AI Risk Management Framework (AI RMF 1.0)

AI RMF is the AI-specific framework that complements the general risk management catalogue. The MEASURE function reads against the methods used to assess AI risk; FAIR is one of the methods enterprise programmes adopt for the AI scenarios where financial expression is required, particularly for the GenAI Profile (NIST AI 600-1) scenarios with significant secondary loss exposure.

CVSS, EPSS, CISA KEV, and SSVC

CVSS scores technical severity. EPSS estimates exploit probability. CISA KEV catalogues active-exploitation. SSVC produces vulnerability decisions on a stakeholder-specific basis. None are risk quantification; they are inputs to FAIR. CVSS contributes to vulnerability under LEF. EPSS contributes to TEF. KEV elevates TEF for active-exploitation scenarios. SSVC operates at a different layer (per-vulnerability decision) and feeds the disposition record FAIR points to.

Where FAIR inputs come from: sourcing the leaf nodes

FAIR analyses fail at the input layer, not at the ontology layer. The methodology is well-defined; the work is sourcing the inputs from places the analysis team can defend per cycle. A FAIR programme that holds the inputs on the operating record produces analyses that refresh per cycle without rebuilding the underlying source evidence; a programme that holds the inputs separately discovers by quarter two that the input maintenance work has overwhelmed the analysis team.

Threat intelligence subscriptions and threat reports for the threat communities relevant to the scenario, with the per-community capability and motivation profile.
MITRE ATT&CK technique prevalence data for the threat actions named in the scenario, with the technique-to-control-coverage mapping the programme has built.
Peer breach data (Verizon DBIR, IBM Cost of a Data Breach, industry-specific information sharing communities) for the threat event frequency and loss magnitude reference points.
Internal incident history covering prior attempts and successful events against the asset class, with the per-event cost record finance can validate.
Authenticated scanning evidence covering the live posture on the asset, with the control coverage gap record and the exception register entries that affect vulnerability.
Code scanning evidence covering the developer-side controls, with the secure-coding standard adherence record and the dependency vulnerability state.
CVSS and EPSS data for the per-CVE technical severity and exploit probability that feed the vulnerability node for vulnerability-driven scenarios.
CISA Known Exploited Vulnerabilities (KEV) catalogue for the active-exploitation signal that elevates threat event frequency for the scenarios where the CVE matters.
Contract terms and SLA penalties for the primary loss inputs the legal and finance functions can validate against the underlying agreements.
Regulatory penalty schedules for the secondary loss inputs the compliance function can validate against published regulator guidance.
Cyber insurance policy terms covering the deductible, the sub-limits, the exclusions, and the per-event recovery the insurance broker can validate.
Customer churn and brand damage modelling from prior incidents in the sector or from internal events the marketing and revenue functions can validate.

Recurring failure modes FAIR programmes hit

Programmes that struggle with FAIR typically hit a small set of recurring failure modes. Naming them upfront lets the programme design the operating model to avoid them rather than discovering them at the second cycle when the analysis team is already overcommitted.

Treating FAIR as a tool rather than a methodology. FAIR is the analytical model. Tools (commercial CRQ platforms, Monte Carlo spreadsheets, open-source libraries) implement the model. Programmes that adopt a tool without internalising the methodology end up with analyses they cannot defend when the tool changes its default assumptions or the vendor relationship ends.

Quantifying everything in the first cycle. Programmes that try to apply FAIR to fifty scenarios on the first run discover that the input maintenance work overwhelms the analysis team by cycle two. The pattern that survives is to start with three to five top loss scenarios, mature the inputs, and expand the scenario library only after the first set is stable.

Reporting FAIR output as point estimates. The methodology produces a distribution. A FAIR programme that reports a single number (the average annual loss expectancy alone) loses the value the methodology adds. The board reading expects ranges with confidence bands, the audit committee expects the input rationale, and the regulator expects the methodology reference. Point estimates from FAIR are usually a misread.

Collapsing threat event frequency and vulnerability. The two are explicitly separated in the ontology because they have different inputs and different mitigations. Programmes that produce a single loss event frequency without decomposing it lose the audit trail for why a control investment changes the rate. The decomposition is the discipline that lets the programme defend the analysis when the inputs change.

Skipping calibration training. Calibrated estimation is the analyst skill that turns subjective inputs into defensible ranges. Programmes that hire FAIR analysts without calibration training produce ranges that collapse the first time the underlying assumptions are challenged. Open FAIR certification covers the methodology but not the estimation skill; the calibration training is the complementary investment most programmes underinvest in.

Treating secondary loss as a guess. Secondary loss is usually the bigger number and the harder one to defend. Programmes that wave at secondary loss with a single high estimate get challenged the first time the audit committee asks for the breakdown. The discipline is to decompose secondary loss into the named secondary stakeholders (regulators, litigants, customers, insurers, competitors) and to source each input from a place the relevant function can validate.

Holding the input record outside the operating record. The FAIR analyses the board reads against need to reconcile with the live security posture. Programmes that hold the FAIR work in a separate analytical environment (a CRQ platform, an analyst spreadsheet, an offline workbook) discover that by quarter two the analyses no longer match the operating reality. The fix is to source the inputs from the live record so the per-cycle refresh is a re-read rather than a rebuild.

Evidence a FAIR programme is expected to produce

A defensible FAIR programme produces a stable evidence set per scenario. The same set reads cleanly under ISO 31000, NIST SP 800-30, COSO ERM, NIST AI RMF, regulator inquiries, board reporting, audit committee reads, and procurement-side risk questionnaires. The discipline is to hold the evidence at the scenario level rather than at the per-analysis level so the per-cycle refresh produces a delta rather than a new artefact stack.

Scenario library with the per-scenario definition: the asset, the threat community, the threat action, the effect, and the scope statement bounding the analysis
Per-scenario input distributions or ranges with the rationale per input, the source per input, the analyst signature, and the per-cycle refresh record
Monte Carlo combination output per scenario, with the iteration count, the output distribution, the 10th and 90th percentile bands, the median, and the average annual loss expectancy
Per-cycle refresh evidence covering which inputs were re-sourced, which inputs were unchanged, which inputs the analysis team flagged as requiring better data, and the analyst sign-off per refresh
Linkage record connecting the FAIR inputs to the underlying operating evidence: scan execution records, finding triage records, exception register entries, patch records, incident records, peer breach data references
Disposition record per scenario: mitigate, transfer, accept, share, or avoid; the named disposition owner; the rationale for the disposition; the implementation evidence reference; the review cadence
Risk committee review record with the per-cycle agenda, the decisions taken, the open actions, the next-cycle inputs the committee asked the analysis team to source, and the attendance record
Board reporting record with the per-cycle FAIR output presented at the board level, the narrative around the change since the prior cycle, the comparison against the risk appetite, and the board response captured in the minutes
Audit evidence record covering the analyst calibration certifications, the methodology reference (FAIR Institute publications, Open FAIR standards, ISO 31000 cross-reference, NIST 800-30 cross-reference), and the per-analyst training record
Per-scenario exception or override record: the cases where the analysis team accepted a non-FAIR estimate, the reason for the override, the approver, and the rationalisation against the FAIR ontology

How FAIR reads across enterprise security functions

FAIR is a cross-functional methodology. The same scenario library reads differently depending on the function that holds the work. Programmes that run FAIR as a GRC exercise alone lose the engineering depth the inputs require; programmes that run it as an engineering exercise alone lose the executive vocabulary the methodology was designed to produce. The named functions below own different parts of the same scenario record.

CISOs and security leaders

Run the FAIR programme as the executive-facing risk vocabulary. Hold the scenario library, the per-cycle output, and the board reporting record on one workspace so the analyses the board reads against reconcile to the live operating posture. Carry the AAL (average annual loss) figure paired with the confidence bands rather than as a point estimate, and tie each disposition to the operating record the security programme reads.

GRC and compliance teams

Use FAIR for the scenarios where qualitative severity does not produce the financial language the audit committee, the regulator, or the enterprise risk owner asks for. Pair the FAIR analyses with the ISO 31000 process record, the NIST SP 800-30 cross-reference, the COSO ERM principle alignment, and the per-cycle exception register so the audit trail reads cleanly across the multiple risk vocabularies.

Enterprise risk management teams

Bring the cyber FAIR analyses into the broader ERM portfolio so cyber risk sits next to operational risk, financial risk, strategic risk, and compliance risk on the same expression layer. The portfolio view the COSO ERM Component 3 expects reads cleanly against FAIR output because the methodology produces output in the same financial unit the other risk types report against.

Vulnerability management teams

Supply the live vulnerability state, the exception register, the remediation SLA adherence, the per-asset criticality scoring, and the patch state into the vulnerability input under loss event frequency. The signal FAIR reads against is the operating record, not the snapshot from the analysis week; running FAIR on a workspace that holds the live vulnerability state lets the analysis refresh per cycle without rebuilding the underlying record.

AppSec and product security teams

Carry the code-scanning state, the dependency vulnerability state, the secure-coding adherence record, and the SDLC integration evidence into the vulnerability and threat capability inputs for the development-driven scenarios. FAIR scenarios that cover application breach paths, API exposure, or supply chain compromise need the AppSec evidence as the primary input source rather than as a footnote.

Security operations and incident response leaders

Supply the incident history, the prior loss event records, the MTTD/MTTR record, and the threat-actor attribution into the primary loss and threat event frequency inputs. The defensible secondary loss estimates the board reads against are usually rooted in the incident response record from prior events; without the IR record feeding the model, secondary loss collapses into guesses.

Running FAIR on SecPortal

SecPortal is built around the operating record a FAIR programme reads against: the engagement carries the per-scenario analysis cycle, the findings record carries the vulnerability state feeding the LEF inputs, the documents area carries the scenario library and the Monte Carlo output, and the activity log carries the audit trail the per-cycle refresh reads against. The platform alignment below maps the verified product capabilities to the FAIR methodology so the programme is held on one operating record rather than across a separate analytical environment that drifts from the live posture.

Engagement management as the workspace anchor for the FAIR programme, with the per-scenario analysis cycle tracked as an engagement that carries the scenario definition, the input set, the Monte Carlo output, the disposition, and the review cadence as a single record rather than as a separate analytical project
Findings management with CVSS 3.1 calibration so the per-finding severity reading the vulnerability input under LEF reads against is consistent across the scanner intake, the analyst triage, the exception register, and the remediation SLA record
Compliance tracking across ISO 31000, NIST SP 800-30, NIST SP 800-37 (RMF), COSO ERM, NIST AI RMF, ISO 27001, SOC 2, and PCI DSS so the FAIR scenarios the programme runs read against the same control catalogue and the disposition records consume cleanly into the parallel framework reads
Authenticated scanning so the vulnerability node under LEF reads against the live posture record on the asset rather than against a snapshot from the analysis week, with the per-asset coverage record archived per scenario refresh
Code scanning via Semgrep against connected repositories so the AppSec input feeding the vulnerability node for application-breach scenarios reads against the live code state, with the per-repo finding state archived per scenario refresh
Document management for the scenario library, the input rationale per leaf node, the Monte Carlo output reports, the board reporting decks, and the audit evidence package so the FAIR programme lives on the operating record rather than across a folder hierarchy that drifts from the analysis reality
Activity log with CSV export so every change to a scenario definition, an input source, an analyst sign-off, a disposition, or a review cycle is reproducible from one source, which is the audit trail the FAIR programme reads against during the per-cycle defence
AI report generation that turns the per-cycle scenario record into the board-readable narrative, the risk committee briefing pack, and the audit committee summary so the executive layer reads the FAIR output in the language each stakeholder consumes
Team management with RBAC so the analyst, the reviewer, the approver, and the executive role boundaries the FAIR programme reads against are enforced at the workspace layer rather than at the per-document level
Multi-factor authentication for workspace access so the analyst sign-off, the disposition approval, and the review cadence evidence the audit committee reads against carry the authentication record the methodology defence expects
Retesting workflows paired to the remediation commitments arising from the FAIR disposition record so the closure evidence the next-cycle refresh reads against carries the verify-after-fix record rather than a status statement

Key control areas

SecPortal helps you track and manage compliance across these domains.

The FAIR ontology: loss event frequency and loss magnitude

FAIR decomposes risk into two top-level factors: loss event frequency (LEF) and loss magnitude (LM). LEF further decomposes into threat event frequency (how often a threat actor takes an action against the asset) and vulnerability (the probability the action results in a loss event). LM further decomposes into primary loss (the direct cost the organisation incurs when the loss event occurs) and secondary loss (the downstream cost from secondary stakeholders, such as regulators, customers, and litigants, reacting to the event). Each leaf node accepts a distribution rather than a point estimate; Monte Carlo combination produces the output distribution the programme reports against.

FAIR Lite: the pragmatic adoption variant

FAIR Lite uses the same ontology but accepts ranges (minimum, most-likely, maximum) over full distributions and skips deeper decomposition for inputs where the underlying signal is weak. The output is less precise but the discipline is the same, and the programme learns where the data has to improve before it commits to a fuller decomposition. Most enterprise programmes run FAIR Lite for the first two cycles and only adopt fuller distributions for the small set of scenarios where the inputs are mature enough to support the precision.

Scenario definition: the model only works against named scenarios

A FAIR analysis runs against a named scenario, not against an abstract risk. The scenario specifies the asset, the threat community (the kind of actor: cybercriminal, nation-state, malicious insider, non-malicious insider, partner organisation), the threat action (the named action the actor takes), and the effect (the named loss outcome). A loose scenario produces loose inputs. Programmes that adopt FAIR without disciplining the scenario library end up rerunning analyses every time a stakeholder asks a different question, because the inputs were never bounded by the scenario.

Threat event frequency and vulnerability: separating the two

FAIR explicitly separates threat event frequency (the rate at which the threat actor attempts the action) from vulnerability (the conditional probability the attempt produces a loss). The separation matters because the programme treats the two with different inputs: threat event frequency reads against threat intelligence, ATT&CK technique prevalence, peer breach data, and prior incident history; vulnerability reads against control coverage evidence, control efficacy, exception register entries, and the live posture record. Programmes that collapse the two lose the audit trail for why a control investment changes either of them.

Primary loss and secondary loss: separating the two

FAIR separates the loss the organisation incurs directly (primary loss: response cost, productivity loss, replacement cost, fines borne directly, lost competitive advantage) from the loss that arises because secondary stakeholders react to the event (secondary loss: regulatory penalties beyond the direct response cost, civil litigation, customer churn, brand damage, increased insurance premiums, secondary contractual penalties). The separation is the discipline that prevents double-counting and that exposes where the controversial inputs sit; secondary loss is usually the bigger number and the harder one to defend.

Open FAIR: the certified analyst stream

Open FAIR is the Open Group certification for the FAIR analyst role. The certification covers the FAIR ontology, the Open Risk Taxonomy (O-RT), and the Open Risk Analysis (O-RA) standards. The certification exists so that programmes can hire and develop analysts against a defined competency catalogue and so that audit evidence references a recognised methodology rather than a bespoke one. Programmes that operate under regulated or contractual risk reporting obligations typically require Open FAIR-certified analysts for the analyses that feed the formal reporting line.

FAIR Lite Monte Carlo: ranges, distributions, and confidence

FAIR output is a distribution rather than a point estimate. The Monte Carlo combination samples each leaf input independently and combines them per the ontology to produce an output distribution across many thousands of iterations. The programme reports the output as a range with confidence bands (the 10th percentile, the median, the 90th percentile, plus the average annual loss expectancy). Point estimates from FAIR are usually a misread of the methodology; the value FAIR produces is the explicit uncertainty around the estimate, not the single number at the centre of the range.

FAIR vs ISO 31000: where they sit relative to each other

ISO 31000 is the umbrella standard for enterprise risk management; it is process and principle, not method. FAIR is the analytical method that produces the quantification ISO 31000 mentions as one of the techniques the framework supports. A mature enterprise risk programme follows ISO 31000 at the process layer (governance, framework, process, integration with management decisions) and uses FAIR (or another quantitative method) at the analysis layer for the scenarios that warrant quantitative treatment.

FAIR vs NIST SP 800-30: where they sit relative to each other

NIST SP 800-30 (Guide for Conducting Risk Assessments) is the federal guide to the risk assessment process, sitting under NIST SP 800-39 at the strategic layer and feeding NIST SP 800-37 (RMF) at the operating layer. 800-30 describes the assessment process and supports both qualitative and quantitative approaches. FAIR is the most common operationalisation of the quantitative path within 800-30; programmes that operate under FISMA, FedRAMP, or CMMC and need quantitative risk analysis typically reference 800-30 for the process and FAIR for the method.

FAIR vs CVSS, EPSS, and CISA KEV: complementary rather than substitutive

CVSS scores the technical severity of a specific vulnerability. EPSS estimates the 30-day probability a CVE is exploited. CISA KEV is the catalogue of CVEs confirmed under active exploitation. None of these are risk quantification: they are inputs that feed FAIR. CVSS contributes to vulnerability under loss event frequency. EPSS contributes to threat event frequency for the scenarios where the CVE matters. KEV elevates threat event frequency for active-exploitation scenarios. FAIR is the model that combines them into a financial loss estimate the executive layer reads against.

Adoption pattern: the operating model that survives the second cycle

Programmes that adopt FAIR successfully follow a recognisable pattern. Start with three to five top loss scenarios. Build defensible models using FAIR or FAIR Lite. Source inputs from telemetry that already exists on the operating record (scanner evidence, finding history, exception register, incident records, peer breach data). Present output as ranges with confidence rather than as point estimates. Review quarterly with the risk committee and re-source inputs each cycle. Expand the scenario library only after the first set is stable. Programmes that try to quantify everything in the first cycle fail at the second cycle because the input maintenance work overwhelms the analysis team.

Audit and board evidence FAIR is expected to produce

A defensible FAIR programme produces a stable evidence set per scenario: the scenario definition (asset, threat community, threat action, effect), the input distributions or ranges with the rationale and source per input, the Monte Carlo output distribution with the confidence bands, the per-cycle input refresh record, the linkage to the operating telemetry (scan execution, finding remediation, exception register, incident history), the disposition record (mitigate, transfer, accept, share, or avoid), the named owner per disposition, and the review cadence record. The same evidence set reads cleanly under ISO 31000, NIST SP 800-30, COSO ERM, NAIC ORSA, FedRAMP, regulator inquiries, and board reporting.

Related features

Orchestrate every security engagement from start to finish

Vulnerability management software that tracks every finding

Compliance tracking without a full GRC platform

Test web apps behind the login

Find vulnerabilities before they ship

Document management for every security engagement

Every action recorded across the workspace

AI-powered reports in seconds, not days

Collaborate across your entire team

Multi-factor authentication on every workspace

Verify fixes and track reopens on the same finding record

Run a defensible FAIR programme on one operating record

Hold the scenario library, the input record, the per-cycle refresh evidence, the output distributions, and the disposition trail on one workspace so the FAIR analyses the board reads against reconcile to the live security posture rather than to a snapshot from the analysis week. Start free.