FAIR Risk Quantification at After Action

How we turn exercise gaps into annualized loss expectancy

After Action | Version 1.0 | April 2026

Executive Summary

Most cyber risk conversations happen in words: "critical gap", "high exposure", "significant risk". These descriptions are useful for prioritization but useless for budget decisions. A board asking "how much should we spend on endpoint detection?" needs a dollar answer, not an adjective.

The Factor Analysis of Information Risk (FAIR) methodology, originally developed by Jack Jones and standardized by The Open Group (the O-RT Risk Taxonomy and O-RA Risk Analysis standards), converts qualitative cyber risk into quantitative dollar ranges. After Action implements a full FAIR engine with Monte Carlo simulation (10,000 iterations per scenario), integrated directly with the exercise gap data collected during tabletop exercises.

This whitepaper documents the methodology, the Monte Carlo implementation, and the exercise-to-FAIR bridging logic that makes it all automatic.

1. Why FAIR

1.1 The problem with qualitative scoring

Most cyber risk assessments produce color-coded matrices: red/amber/green, 1-5 scales, "high/medium/low". These are useful for communicating relative priority but fail when executives ask:

• "How much annual loss does this gap actually create?"
• "If we fix this, what's our ROI?"
• "At what point does the cost of mitigation exceed the expected loss?"
• "What's our 90th percentile worst-case scenario?"

These are budget questions, not color questions. They need money answers.

1.2 FAIR answers these questions

FAIR decomposes cyber risk into measurable, composable sub-factors and produces a probability distribution of financial loss. The output is a dollar range with confidence intervals: "90% confident that annual loss from this scenario falls between $220K and $1.8M, with an expected value of $640K."

That's a number a CFO can act on.

1.3 FAIR is an open standard

• Standardized by The Open Group as the Risk Taxonomy (O-RT) and Risk Analysis (O-RA) standards
• Commonly used alongside ISO 31000-style risk management programs (FAIR itself is an Open Group standard, not an ISO standard)
• Used by enterprise risk committees, cyber insurance carriers, and government agencies

Using FAIR isn't experimental. It's what mature risk programs already do.

2. The FAIR Ontology

FAIR breaks down cyber risk into a hierarchy of factors:

Risk (Annualized Loss Expectancy)
├── Loss Event Frequency (LEF)
│   ├── Threat Event Frequency (TEF) — attempts per year
│   └── Vulnerability — probability an attempt succeeds
└── Loss Magnitude (per event)
    ├── Primary Loss — direct costs
    │   (detection, response, recovery, lost revenue during downtime)
    └── Secondary Loss — indirect costs
        (fines, lawsuits, reputation, customer churn)
        × Secondary Loss Event Frequency (probability secondary losses occur)

Core formula

LEF = TEF × Vulnerability
Expected loss per event = PrimaryLoss + (SecondaryLEF × SecondaryLoss)
ALE = LEF × Expected loss per event

Example

A ransomware scenario:

• TEF: 0.5 attempts per year (1 in 2 years)
• Vulnerability: 0.4 (40% chance an attempt succeeds given current controls)
• LEF: 0.5 × 0.4 = 0.2 events per year (1 every 5 years)
• Primary Loss: $250K (incident response, recovery, downtime)
• Secondary LEF: 0.3 (30% chance secondary losses occur — regulatory fines, lawsuits)
• Secondary Loss: $1,500K
• Expected loss per event: $250K + (0.3 × $1,500K) = $700K
• ALE: 0.2 × $700K = $140K per year

A board can budget against $140K. A board cannot budget against "high".

3. Monte Carlo Simulation

3.1 Point estimates are wrong

The example above uses point estimates. In reality, every factor is uncertain:

• TEF might be 0.3 to 0.8 attempts per year, not exactly 0.5
• Vulnerability might be 0.25 to 0.55, not exactly 0.4
• Primary loss ranges wildly based on how bad the incident is

Multiplying uncertain numbers compounds the uncertainty. The correct output isn't a single dollar figure — it's a distribution.

3.2 Beta-PERT distribution

For each factor, After Action accepts a Beta-PERT distribution defined by four parameters:

• min — optimistic bound
• mostLikely — expected value
• max — pessimistic bound
• confidence — 1-5, how tightly to cluster around mostLikely

Beta-PERT is the industry standard for expert-elicited estimates because it's flexible enough to model asymmetric distributions (the "long tail" of worst-case scenarios) while being simple enough for domain experts to parameterize.

3.3 The simulation loop

For each scenario, After Action runs 10,000 iterations:

for i in 1..10,000:
  tef  = samplePERT(scenario.tef)
  vuln = samplePERT(scenario.vulnerability)
  lef  = tef × vuln

  primary = samplePERT(scenario.primaryLoss)
  secondaryLef = samplePERT(scenario.secondaryLef)
  secondary = samplePERT(scenario.secondaryLoss)

  totalLossPerEvent = primary + (secondaryLef × secondary)
  ale[i] = lef × totalLossPerEvent

3.4 Outputs

After 10,000 iterations we have a population of 10,000 possible annual loss values. From this we compute:

• Mean — expected annual loss (the "headline" number)
• p10 — optimistic scenario (10% of iterations are lower)
• p50 (median) — the middle outcome
• p90 — pessimistic scenario (10% of iterations are higher)
• Max — worst observed iteration
• Loss exceedance curve — P(loss > X) for any X

3.5 Loss exceedance curve

The exceedance curve is the single most useful output for executive conversations. It reads:

"There's a 23% chance our annual loss from this scenario exceeds $500K. There's a 5% chance it exceeds $2M. There's a 0.5% chance it exceeds $10M."

Boards can look at the curve and decide where they're comfortable. If they accept up to a 10% chance of $1M loss, they can see exactly how much additional control spend would shift the curve.

4. Exercise-to-FAIR Bridging

4.1 The problem FAIR doesn't solve

FAIR assumes you can parameterize the factors accurately. In practice, parameterizing TEF, Vulnerability, Primary Loss, and Secondary Loss is hard. Most organizations don't have the data, and specialist FAIR consulting engagements are expensive enough to put quantification out of reach for the mid-market.

4.2 What After Action solves

After Action's exerciseToFairScenarios() function converts exercise gaps into FAIR scenarios automatically:

1. Groups open gaps by category (detection, containment, recovery, etc. — unknown categories fall back to the "process" template)
2. Looks up default PERT ranges for each category ([ASSUMPTION] modeling values — §4.4)
3. Scales the vulnerability range by the worst gap severity in the category, clamped so min/mostLikely never exceed 0.95 and max never exceeds 0.99
4. Scales loss magnitudes by industry multiplier × severity multiplier × gap-count multiplier, where the gap-count multiplier is 1 + (n − 1) × 0.15 — more open gaps in the same category means higher modeled loss
5. Returns a fully parameterized set of FAIR scenarios ready for simulation, with PERT confidence fixed at 3 (moderate) for all auto-generated scenarios

No consultant required. A completed exercise becomes a quantified annual loss expectancy in a single pass.

4.3 Severity and industry multipliers [ASSUMPTION]

A single severity multiplier applies to both the vulnerability range (with the clamps above) and the loss magnitudes (as one term of the loss product):

critical: 2.5x
high:     1.5x
medium:   1.0x (baseline)
low:      0.6x
info:     0.3x

Industry loss multipliers (applied to loss magnitudes only):

healthcare 1.50 | financial services 1.40 | energy 1.25
technology 1.10 | government 0.90 | all others 1.00

4.4 Category → default PERT ranges [ASSUMPTION]

Each gap category has a default scenario template with PERT-distributed parameters — ten templates in total (detection, escalation, containment, communications, recovery, process, technology, personnel, documentation, plus a communications alias). For example, a "detection" category gap maps to:

scenarioName: "Undetected Intrusion — Extended Dwell Time"
tef:           { min: 2, mostLikely: 6, max: 12 }       (events/year)
vulnerability: { min: 0.30, mostLikely: 0.50, max: 0.70 }
primaryLoss:   { min: $50K, mostLikely: $250K, max: $800K }   (pre-multiplier base)
secondaryLoss: { min: $100K, mostLikely: $500K, max: $2M }    (pre-multiplier base)
secondaryLef:  { min: 0.20, mostLikely: 0.40, max: 0.60 }

These are [ASSUMPTION] modeling values, defined in GAP_SCENARIO_DEFAULTS in src/lib/risk-quantification.ts and revised manually with engine releases. They are not derived from a published dataset and not auto-updated — challenge them, and bring your own parameterization if you have better loss data (the engine accepts custom scenarios).

5. Breach Cost Regression Model

As an independent sanity check on the FAIR output, After Action runs a parallel breach cost regression model based on the IBM Cost of a Data Breach methodology.

5.1 Base cost

base_per_record_cost = $165 (2024-2025 average)
base_cost_floor = $500,000 (minimum for small orgs)

5.2 Industry multipliers [ASSUMPTION]

From IBM Ponemon sector reports:

5.3 Breach type multipliers [ASSUMPTION]

5.4 Cost breakdown [ASSUMPTION]

Per IBM Ponemon research:

• Detection & escalation: 29%
• Notification: 6%
• Post-breach response: 27%
• Lost business: 38% (the hidden cost most executives underestimate)

5.5 Formula

records = provided_count || (employee_count × 50) || 10000
per_record = base_per_record_cost × industry_mult × breach_type_mult
base = max(base_cost_floor, records × per_record)

# Diminishing per-record cost above 100K records:
if records > 100000:
  base = 100000 × per_record + (records − 100000) × per_record × 0.6

# Readiness modifiers, summed then applied once:
total = base × (1 + Σ modifier_pct / 100)

Modifier constants ([ASSUMPTION]): IR plan −9.4% (its absence adds +9.4%), IR team −14%, encryption −7%, security training −5%, fast identification (<100 days) −10%, slow identification (>200 days) +23%, fast containment (<30 days) −8%, slow containment (>90 days) +12%. The reported range is median ±30%.

When the FAIR output and the breach cost regression agree within ±50%, the numbers are defensible. When they diverge significantly, something's wrong with the input data and a human should review.

6. Implementation

6.1 Pure function architecture

The FAIR engine is a single file: src/lib/risk-quantification.ts. It exports:

• quantifyRisk(scenario, iterations) — runs Monte Carlo, returns full result
• estimateBreachCost(input) — runs the regression model
• exerciseToFairScenarios(data) — bridges exercise data to FAIR scenarios
• compareScenarios(results) — side-by-side comparison of current vs. remediated

(The Beta-PERT sampling primitive, samplePERT, is internal to the module.)

Every function is pure (no DB, no network, no LLM). The 10,000-iteration simulation runs synchronously within the request; we don't publish a benchmarked latency figure.

6.2 Surfacing in the platform

The FAIR engine is surfaced at /app/client/risk-quantification. Clients see:

• 4 StatCards: expected annual loss, 90th percentile, 10th percentile, scenario count
• Independent breach cost regression sanity check
• Per-scenario risk cards ranked by mean ALE
• Inline loss exceedance curve SVG for the top scenario

7. Licensing

The FAIR methodology itself is public. After Action's implementation, including:

• The exercise-to-FAIR bridge (exerciseToFairScenarios())
• The calibrated category defaults
• The severity-adjusted multipliers
• The integration with the readiness scoring engine
• The Monte Carlo simulation code

...is proprietary trade secret. Commercial licensing available via licensing@afteraction.dev.

© 2026 After Action. FAIR is a methodology published by The Open Group. After Action's implementation is proprietary. Contact licensing@afteraction.dev for commercial terms.