Quantitative Cyber Risk Analysis Based on FAIR

1. Overview

A. Definition

FAIR (Factor Analysis of Information Risk) is an open risk-analysis model that decomposes information-security risk into the frequency of loss events and the magnitude of loss, expresses uncertainty through probability distributions, and analyzes exposure in economic terms.

Rather than stopping at labels such as “high,” “medium,” or “low,” FAIR addresses how often a defined loss scenario may occur and what range of loss may follow. Its purpose is not to predict an incident with certainty, but to expose evidence and assumptions and provide decision-useful estimates and uncertainty. The resulting analysis connects technical threat descriptions to management decisions about security investment, risk acceptance, transfer, and control design.

FAIR models risk through the combination of Loss Event Frequency (LEF) and Loss Magnitude (LM), rather than fixing risk as a single score. Risk is understood as the probable frequency and probable magnitude of future loss; quantitative analysis documents the ranges, distributions, and evidence behind its factors. Even when a result is summarized as a single amount, such as KRW 10 million, the underlying output is a loss distribution shaped by assumptions.

The Open FAIR Body of Knowledge consists of the Risk Taxonomy (O-RT), which defines risk factors and their relationships, and Risk Analysis (O-RA), which describes how to perform analysis using them. In May 2025, The Open Group announced O-RA Version 2.1 and O-RT Version 3.1, updated for consistency with the Governance function in NIST CSF 2.0. The publicly available online O-RA text explains detailed analysis principles but displays earlier edition labels, so current-edition citations should be checked against the latest update announcement.

B. Background and Need

Security leaders may receive a report that risk is “high” yet still lack a consistent way to decide which exposure is more urgent, how much to invest, or whether a control reduces loss. Color ratings or weighted scores can use different meanings across systems, making it difficult to allocate risk budgets and business priorities consistently. FAIR seeks to narrow this decision gap through common loss units and decomposable risk factors.

Uncertainty in risk analysis is not noise to be removed; it is information to be represented in the result. Incident histories, threat intelligence, vulnerability data, and control-effectiveness evidence are often incomplete. Producing a precise single number despite this uncertainty can mislead decision makers. FAIR provides a structure for recording estimation evidence and ranges and identifying which factors should be updated when better data arrives.

Quantification does not turn risk into objective truth. The model supplies agreed definitions and calculation procedures, but inaccurate asset values, scenario boundaries, or estimates will distort the result. The information-management professional should therefore examine the scenario, data, distributions, and stakeholder judgments behind the number.

C. Scope and Assumptions

FAIR can be applied to cyber and information-security risks and to other scenarios, such as project, operational, or financial losses, where frequency and magnitude can be analyzed. Quantification is most useful when the result informs a real choice. It is usually more efficient to start with a specific management question than to attempt to quantify every asset and threat at once.

A loss scenario identifies the asset, threat agent or community, action or path, observable loss event, and affected stakeholders. For example: “An external criminal group exploits an authentication path exposed by a customer-data service, exposing customer records and causing notification, legal, and recovery costs.” Broad labels such as “ransomware risk” may combine different actors, assets, and loss types and are therefore poor analysis boundaries.

2. Risk-Factor Decomposition and Conceptual Model

A. Overall Concept

The diagram separates a scenario into frequency and magnitude, combines distributions based on evidence and assumptions, and delivers the result to management decision making.

flowchart LR
  S["Loss scenario<br/>asset · threat · loss event"] --> F["Loss Event Frequency (LEF)"]
  S --> M["Loss Magnitude (LM)"]
  T["Threat Event Frequency (TEF)"] --> F
  V["Vulnerability · resistance"] --> F
  P["Primary loss"] --> M
  Q["Secondary loss"] --> M
  F --> MC["Combine probability distributions<br/>Monte Carlo, etc."]
  M --> MC
  D["Data · expert estimates<br/>ranges · assumptions · confidence"] --> MC
  MC --> R["Loss exposure distribution<br/>annual expectation · exceedance"]
  R --> B["Control alternatives · acceptance<br/>cost-benefit decision"]

FAIR decomposition is more detailed than simply multiplying “likelihood × impact.” On the frequency side, it distinguishes opportunities for a threat action from the probability that the action becomes an actual loss event. On the magnitude side, it separates direct organizational loss from additional loss caused by reactions from external stakeholders.

B. Loss Event Frequency (LEF)

Loss Event Frequency (LEF) is the estimated number of observable loss events for a defined scenario during a specified period. Conceptually, LEF is described through Threat Event Frequency (TEF) and vulnerability. A simplified relationship is (LEF \approx TEF \times P(\text{loss event} \mid \text{threat event})).

Threat Event Frequency (TEF) estimates how often a threat agent contacts or acts against an asset. Daily automated scanning of a public login page differs in frequency and intent from a targeted intrusion against a particular industry. The threat community and attack path should be differentiated for each scenario so the estimation evidence has a clear scope.

Vulnerability represents the conditional likelihood that a threat event results in a loss event. In the detailed FAIR model, the relationship is explained by comparing Threat Capability with the Resistance Strength of controls. Vulnerability is therefore not another name for the number of known flaws; it is a scenario-level probability arising from the interaction of threat capability and defenses.

The appropriate level of LEF decomposition depends on evidence quality and the analysis purpose. Reliable incident statistics may support a direct estimate of overall loss frequency, while limited data may require decomposition into TEF and vulnerability factors. Excessive decomposition can accumulate error and assumptions, so analysts should prefer the simplest model that remains accurate and useful.

C. Loss Magnitude (LM)

Loss Magnitude (LM) estimates the economic impact borne by the organization if a loss event occurs. The analyst defines currency and time units consistently and identifies relevant losses, including direct costs, business interruption, recovery, and contractual liability. Economic expression is not meant to reduce the importance of security to money; it creates a decision language that can be compared with other business risks and control costs.

Primary Loss is the direct cost borne by the primary stakeholder as a consequence of the loss event. Incident response, system restoration, external experts, customer notification, and reduced productivity may be included. The organization documents the scenario and accounting rules used to decide which items belong in this category.

Secondary Loss is additional loss resulting from the actions of customers, regulators, partners, media, or other secondary stakeholders. Regulatory investigation, litigation, contract termination, and reputational effects are possible examples, but they should not be presumed to occur in every scenario. Their probability and amount should be estimated separately, and causal links and double counting should be reviewed.

Breaking loss magnitude into response cost, outage duration, and number of affected customers makes control effects easier to trace than using one maximum amount. Encryption may reduce secondary loss from data exposure but does not necessarily reduce availability loss or recovery expense by the same proportion. Controls should therefore be linked to the loss factors they can actually affect, while unchanged factors remain visible.

D. Interpreting the Risk Output

Combining frequency and magnitude estimates produces a loss-exposure distribution over a defined period. This distribution does not claim that annual loss will be exactly a particular amount; it represents possible outcomes and their relative likelihood. Reports should present more than a mean: they should include percentiles, exceedance probabilities, ranges, assumptions, and sensitive input factors.

Expected Annual Loss or Annualized Loss Expectancy can help allocate resources, but an average may conceal tail risk. Rare but very large losses can materially influence the mean, so the mean alone is not enough to determine acceptance. The organization should also consider loss exceedance probabilities, upper percentiles, and severe scenarios in light of risk appetite and financial resilience.

FAIR enables comparison with other financial and operational risks, but it does not imply that every loss can be perfectly monetized. Human rights, privacy, safety, and legal obligations cannot be replaced by a financial estimate. Non-negotiable legal, ethical, and safety constraints should be applied in addition to monetary analysis.

3. Analysis Process and Quantitative Modeling

A. Process Diagram

The flow below summarizes the basic analysis stages described in the publicly available O-RA online text. For exact requirements and wording of the current edition, check the official O-RA 2.1 update materials; this diagram is an explanatory summary.

flowchart TD
  A["1. Scope the scenario"] --> B["2. Estimate loss event frequency"]
  B --> C["3. Estimate loss magnitude"]
  C --> D["4. Derive and explain risk"]
  D --> E["5. Model control effects"]
  E --> F{"Decision criteria met?"}
  F -->|Yes| G["Accept risk · allocate budget · decide controls"]
  F -->|No| H["Review controls and assumptions"]
  H --> B
  G --> I["Reassess using operational evidence"]

B. Stage 1: Scope the Scenario

The first stage defines the analysis question and loss scenario boundaries. It identifies who bears the loss, which asset is at risk, which threat community uses which path, and what observable loss event may result. Without a clear scope, different attacks and losses become mixed, making frequency and magnitude difficult to estimate reliably.

The business or system owner should review the scenario together with the security analyst. Security specialists explain threat behavior and control conditions, while business, finance, and legal teams understand operational impact and stakeholder response. Executives determine which outcomes matter to the decision and approve the analysis level.

Do not exclude every low-likelihood scenario, but also avoid endless expansion based only on speculation. Narrow the loss path to an observable event and avoid combining threat communities or loss types that lack common characteristics. When grouping assets or attack paths, verify that their frequency, controls, and loss profiles are sufficiently homogeneous.

C. Stage 2: Estimate Loss Event Frequency

Frequency estimation determines how often the scenario may produce an event over a defined period. Record the source of evidence separately, including external incident statistics, internal incident and blocking logs, threat intelligence, exposure data, control tests, and expert judgment. Do not simply average or add datasets that describe different populations or observation periods.

When expert judgment is needed, collect minimum, maximum, and most-likely values with their rationale rather than a point estimate alone. Independent estimates from multiple analysts followed by discussion can reduce personal bias and excessive confidence. The report should distinguish a reasoned estimate from a verified fact.

When modeling control effects, distinguish a control's existence from its operation. Multifactor authentication may be deployed, but exceptions, recovery procedures, phishing resistance, and coverage affect its real resistance. Do not infer low vulnerability from a control name without checking operational evidence and testing.

D. Stage 3: Estimate Loss Magnitude

Estimate loss by cost component and label each component as a direct consequence or a response by a secondary stakeholder. Depending on the organization, relevant elements can include response and investigation, system recovery, business interruption, contractual cost, notification and support, litigation, or regulation. Finance and legal teams should review the definitions to prevent the same cost from being counted in multiple categories.

Useful evidence may include internal incidents, insurance claims, recovery projects, business-impact analyses, or comparable organizations. When no comparable data exists, expert estimates may be used while adjusting for differences in sector, scale, regulation, and data sensitivity. For reputational effects that are difficult to price directly, disclose uncertainty and explain the proxy measures and range.

Secondary loss does not occur automatically merely because an incident occurred, so model each stakeholder reaction separately. For example, notification may be driven by law, contract, or voluntary policy, each with different probability and response cost. If litigation, regulatory action, and customer churn are included together, examine overlap and explain the causal model.

E. Stages 4 and 5: Explain Results and Model Controls

After calculating results, explain what drives the loss rather than merely attaching numbers to a report. Sensitivity analysis identifies whether threat frequency, vulnerability, outage time, customer response, or another estimate has the greatest influence. Improving evidence for a critical input may help decisions more than adding precision to an unimportant factor.

Compare control alternatives against a baseline with the same scope and time horizon. Show which frequency or magnitude factors change after the control and provide evidence, implementation cost, operating cost, and conditions for sustained effectiveness. If controls act on the same path, consider interaction and overlap rather than simply adding their effects.

Do not rank investments only by expected loss reduction. Consider risk appetite, legal requirements, recoverability, and combinations of controls. Executives approve acceptance criteria, and any residual risk beyond those criteria should have a named owner, deadline, and formal treatment or acceptance decision. Analysis does not end at control selection; ongoing monitoring must confirm that controls are deployed and achieving their intended results.

F. Probability Distributions and Monte Carlo Analysis

Frequency and magnitude inputs are rarely known exactly, so they are represented as ranges or probability distributions. When data is limited, a triangular distribution based on minimum, maximum, and most-likely values may be used if it fits the purpose and evidence. There is no universal rule for selecting a distribution; observed data and scenario characteristics should guide the choice.

Monte Carlo simulation repeatedly samples from each factor's distribution and calculates frequency and magnitude for each iteration, approximating a distribution of possible loss outcomes. Thousands of iterations can provide a mean, median, percentiles, and the probability that loss exceeds a specified threshold. More iterations do not automatically correct an inaccurate input or poorly scoped scenario.

Assuming all inputs are independent may miss real-world correlations. For instance, a larger breach may increase customer churn and regulatory response together. If evidence for correlation is weak, document the simplification and compare alternative assumptions such as independence and positive correlation.

Operational analysis records distribution selection, ranges, correlation, time horizon, currency basis, duplicate costs, and data sources. This record enables independent review and consistent updates when new incident evidence arrives. Keep the model as simple as possible and add complexity only when it can materially improve a decision.

4. Quantitative Example and Comparison

A. Illustrative Hypothetical Example

The following is a fictional e-commerce customer-data exposure scenario used only to explain the calculation; it is not an estimate for a real company or incident. Assume attack attempts range from 0.4 to 1.2 per year, with a baseline of 0.8, and the probability that an attempt becomes a loss event ranges from 10% to 30%. Multiplying the baseline values gives a simplified LEF of 0.16 per year, approximately one event every 6.25 years on average; this does not guarantee event spacing.

If a loss occurs, suppose direct response and recovery cost ranges from KRW 20 million to 80 million, with secondary notification, support, and contractual costs from KRW 10 million to 120 million. These are example inputs for stakeholder discussion, not industry averages or legal thresholds. In a real analysis, replace them with internal incident records, customer counts, data sensitivity, and legal and contractual review.

A combination of stronger MFA and restrictions on public APIs may be modeled as reducing successful-event probability and the scope of impact rather than changing attempt frequency. Compare pre-control and post-control distributions on the same time horizon and present both risk reduction and implementation and operating costs. If encryption of sensitive data does not resolve an availability outage, the corresponding loss-factor reduction should be small or zero.

The analyst's central role is not to create arbitrary precision but to document scenario boundaries and evidence and test the effects of key assumptions. Even if executives see an expected annual loss of KRW 50 million, they should consider tail loss, financial resilience, and legal obligations. Control value should also include effects on prevention, recovery, compliance, and customer trust, not just mean loss reduction.

B. Comparison with Qualitative Matrices and Other Approaches

Qualitative matrices are quick, understandable, and useful for initial screening when data is scarce. However, multiplying ordinal ratings such as “likelihood 4” and “impact 5” can treat a rank scale as if it were a ratio scale, and changing rating thresholds may reverse priorities. FAIR requires more evidence and analysis effort but focuses on scenario frequency, magnitude, and uncertainty in comparable economic units.

FAIR and NIST SP 800-30 need not be treated as substitutes. NIST SP 800-30 provides organizational guidance for preparing, conducting, and maintaining risk assessments, while FAIR can complement it by decomposing loss factors into a quantitative model. Organizations can retain their existing risk-management process and regulatory requirements while applying FAIR quantification to selected scenarios with material investment decisions.

Comparison	Qualitative risk matrix	FAIR quantitative analysis
Output	Ordinal rating or color	Probability, frequency, and economic-loss distribution
Main strength	Fast screening and easy communication	Scenario comparison and control cost-benefit analysis
Main evidence	Expert rating	Incident, threat, control data, and range estimates
Uncertainty	May be hidden within a category	Can be represented through ranges, distributions, and assumptions
Limitation	Rating gaps may be mistaken for measurable ratios	Requires modeling skill and data acquisition effort
Best use	Initial risk register and communication	Investment, residual-risk comparison, and sensitivity analysis

Quantification is not an automatic guarantee of objectivity. Analyst bias can persist while qualitative judgments are translated into money, and complex-looking scores may create false confidence. Rather than simply converting matrix ratings into FAIR numbers, organizations should independently review scenario definitions, evidence, and probability estimates.

C. Industry Application Examples

A financial institution can decompose an online-banking account-takeover scenario into authentication failure frequency, detection and blocking, fraud loss, customer reimbursement, and regulatory response. Alternatives such as phishing-resistant authentication, transaction anomaly detection, real-time limits, and customer contact procedures can be compared by whether they affect frequency or magnitude. Finance, security, and compliance teams should agree on loss definitions to avoid double counting fraud and reimbursement or legal costs.

A public agency can analyze a prolonged outage of a public service by considering recovery time, workarounds, substitute service cost, and statutory service obligations. For a service where availability is more important than confidentiality, service-level obligations should remain explicit constraints rather than being reduced to monetary value alone. This supports comparison of recovery investments while preserving the agency's non-financial public-service responsibilities.

A manufacturer can model ransomware disruption by production line or plant. Lines with different alternative capacity, inventory buffer, recovery capability, or safety-stop impacts should not be collapsed into one average downtime. The analysis can show how immutable backups, network segmentation, and manual-operation procedures change occurrence and magnitude factors.

5. Advanced Topic: Governance, Control Investment, and Standards

A. Alignment with CSF 2.0 and Enterprise Risk Management

In May 2025, The Open Group announced Open FAIR O-RA 2.1 and O-RT 3.1, noting alignment with the new Govern function in NIST CSF 2.0. This revision history reinforces that quantitative risk analysis should connect to accountability, policy, oversight, and risk appetite rather than remain a technical calculation isolated from governance. CSF and FAIR do not produce the same type of output, so CSF outcomes and categories should not be treated as one-to-one FAIR input variables.

Business and system owners provide business context and operational evidence, while security analysts structure threat, vulnerability, and control paths. Finance, legal, and privacy specialists review cost definitions, legal exposure, and contract and notification requirements. Risk committees approve appetite and investment boundaries; separating roles reduces the chance that analysts overstate the value of their own proposed controls.

Linking analysis to the risk register, security portfolio, continuity plans, and audit evidence clarifies ownership for updates. Quantitative results do not replace compliance evidence or vulnerability remediation. Mandatory improvements should still apply where law, policy, or baseline security requirements are not satisfied, even if estimated monetary exposure appears low.

B. Control Cost-Benefit and Sensitivity Analysis

Compare baseline and post-control distributions with identical scope and time horizons. Subtracting control implementation and operating costs from expected risk reduction can be a useful initial economic screen, but non-financial effects, correlation, and residual risk also matter. Distinguish whether a control protects only one attack type or acts across multiple scenarios.

Sensitivity analysis ranks the inputs that drive results. If threat-frequency estimates dominate, improve threat intelligence or logging; if magnitude dominates, improve business-impact analysis and recovery exercises. Improving evidence for an uncertain factor may create more decision value than immediately adding another control.

Express output precision at the level supported by the model and data. Use broad ranges and conservative assumptions for initial screening, and add independent experts and external data before large investment or risk-transfer decisions. Do not use more significant digits or currency precision than the inputs support, and do not let an average conceal upper-tail outcomes.

C. Exam Answer Strategy

Begin an exam answer by defining FAIR and the management decision problem that motivates quantitative risk analysis. Draw a concept diagram decomposing risk into LEF and LM, then explain TEF, vulnerability, primary loss, and secondary loss in prose. Describe the analysis process, distributions and simulation, pre- and post-control comparison, and differences from a qualitative matrix in terms of strengths, limits, and contexts.

An answer gains depth by not stopping at “risk = probability × impact.” Include scenario scope, data quality and uncertainty, evidence that controls operate, avoidance of duplicate loss, and legal and ethical limits on monetization. Conclude with the O-RA 2.1 and O-RT 3.1 update, CSF 2.0 governance alignment, and a staged application based on risk appetite.

6. Considerations and Implications

A. Fix the Decision Purpose and Scope First

Analysis should start from a decision that the organization must make. Attempting to quantify every asset and threat is expensive and can produce results that are never used. Business owners and risk authorities should agree on the intended decision, time horizon, and acceptance criteria.

An overly broad scenario mixes actors, paths, and losses and makes results hard to interpret. Excessive subdivision increases evidence and maintenance cost and may exaggerate trivial differences. Choose analysis units based on decision-relevant homogeneity and manage scope changes through versioning.

B. Control Data Quality and Estimation Bias

Internal incident records may include only events that were detected or reported and may not represent all threat activity. External industry statistics may come from populations that differ in scale, technology, and reporting practice. Record source, period, population, processing method, and the rationale for adjusting evidence to the organization.

Expert judgment fills evidence gaps, but seniority, recent incidents, and confirmation bias may distort estimates. Independent estimates, calibration exercises, range and confidence records, and alternative assumptions help reduce individual influence. Document why estimates changed and retain unresolved disagreements rather than concealing them.

C. State the Limits of Monetary Measures

Monetization is a convenience for comparing investments, not a complete price for social harm or individual rights. Privacy, life and safety, discrimination, and statutory duties must be managed as constraints in addition to expected monetary loss. Reports should state which factors were not monetized and why.

D. Validate Model and Control Assumptions

Input distributions and correlations matter more than increasing the number of Monte Carlo iterations. Use peer review and scenario testing to check model structure, units, duplicate loss, time horizon, and logical consistency in pre- and post-control changes. For material decisions, check whether the conclusion remains stable under alternative estimation methods or conservative assumptions.

E. Make Residual Risk and Accountability Explicit

Record the owner, acceptance period, additional measures, and review date for residual risk after controls are applied. Acceptance is not an implicit choice by the security team; it is a governance decision by an authorized business owner who has reviewed the evidence. Link the FAIR analysis version and data-change history to the risk register for auditability.

F. Update Estimates Through Continuous Monitoring

Threat conditions, system architecture, customer base, and control operation change; risk analysis is not a one-time report. Reassess key inputs when incident, near-miss, exposure, control-test, or business-impact evidence changes. Set review frequency according to risk and change velocity, and trigger an out-of-cycle review for material changes.

G. Integrated Application from the Professional Engineer's Perspective

Apply FAIR as a complement to existing risk management and security-control systems, not as a universal replacement framework. Pilot it on high-priority scenarios, connect it to qualitative assessment, NIST guidance, enterprise risk management, and audit evidence, and build capability in stages. When quantitative results are presented alongside non-financial duties, executives can make transparent choices among cost, safety, trust, and resilience.

References

The Open Group, “Exciting Updates for the Open FAIR Body of Knowledge and Certification Program” (O-RA 2.1 and O-RT 3.1 update announcement): https://blog.opengroup.org/2025/05/22/exciting-updates-for-the-open-fair-body-of-knowledge-and-certification-program/
The Open Group, “Risk Analysis (O-RA) Standard” online text (analysis principles and process; edition label should be checked against the current update announcement): https://pubs.opengroup.org/security/o-ra/
The Open Group, “The Open FAIR Body of Knowledge”: https://www.opengroup.org/open-fair
NIST, “Guide for Conducting Risk Assessments, SP 800-30 Rev. 1”: https://www.nist.gov/publications/guide-conducting-risk-assessments
NIST, “Cybersecurity Framework”: https://www.nist.gov/cyberframework

In one line: FAIR converts cyber risk into comparable management evidence by analyzing loss-event frequency and economic magnitude as distributions that include uncertainty.