Risk Quantification (FAIR)
Onam's Risk engine converts security findings into dollar-denominated financial risk using FAIR (Factor Analysis of Information Risk) — the only internationally standardized quantitative model for information risk. The output is a business-language view: total financial exposure, the top risks ranked by dollar impact, and the remediation actions that reduce the most exposure per engineering hour.
This page explains the FAIR formula chain, how Onam calibrates each factor from live scan data, the multiplier and cost tables the model uses, and where the engine runs in the platform pipeline.
The FAIR Model
FAIR decomposes risk into frequency and magnitude:
Risk = LEF × LM
LEF = TEF × Vulnerability (Loss Event Frequency)
LM = Primary + Secondary Loss (Loss Magnitude)| Factor | Question it answers | How Onam calibrates it |
|---|---|---|
| Threat Event Frequency (TEF) | How often does a threat actor attempt the action? | CISA KEV flags and EPSS exploitation probabilities |
| Vulnerability | Given an attempt, how likely does it succeed? | Finding type, effective exposure from the Network engine, attack-path reachability |
| Primary Loss | Direct cost of a successful event | IBM/Ponemon per-record breach costs, IR hours, notification counts |
| Secondary Loss | Indirect cost — fines, churn, reputation | The fine schedules of the frameworks in your compliance configuration |
Where the Engine Runs
Risk Quantification runs as Layer 4 of the platform — after discovery, checks, and the domain engines have all completed, so it prices the finished picture rather than raw signals:
| Stage | What happens | Output |
|---|---|---|
| 1. ETL | Pulls Critical and High findings from every engine database once the scan completes | Normalized risk input set |
| 2. Evaluate | Applies the FAIR computation per finding — exposure, threat probability, loss, multipliers | P50 / P90 exposure per finding |
| 3. Report | Writes portfolio rollups to risk_report, risk_summary, and risk_trends | Dashboard, trends, and API views |
Scores recalculate after every scan (typically daily) and whenever the KEV or EPSS feeds update.
Per-Finding Computation
1. Exposure surface
- Is the affected resource internet-exposed? (from the Network Security engine)
- What is the blast radius if compromised? (from the Attack Path engine)
- Is this a crown-jewel asset? (user-designated or inferred from data classification)
2. Threat probability
- Is this finding type actively exploited in the wild? (CISA KEV flag)
- What is the exploitation probability in the next 30 days? (EPSS score)
- Is there a known PoC exploit? (NVD / exploit-db correlation)
3. Loss estimation
Primary loss builds from four components:
| Component | Basis |
|---|---|
| Incident response | $150/hour × estimated IR hours by breach type |
| Data recovery | Per-record cost × affected record estimate |
| Breach notification | $5/notification × estimated notification count |
| Business interruption | Daily revenue × estimated downtime |
Per-record costs come from the IBM Cost of a Data Breach 2024 benchmarks, selected by your industry:
| Industry | Cost per record |
|---|---|
| Healthcare | $10.93 |
| Financial services | $6.08 |
| Technology | $4.88 |
| Retail | $3.28 |
| All other industries (default) | $4.45 |
Secondary loss uses the fine schedules of the frameworks in your compliance configuration:
| Framework | Maximum exposure |
|---|---|
| GDPR | €20M or 4% of global annual turnover |
| HIPAA | $1.9M per violation category per year |
| PCI-DSS | $5,000–$500,000 per month until compliant |
| SOX | $5M plus criminal liability for willful violations |
Multipliers
Three multiplier systems adjust Loss Magnitude to your environment.
Regulatory multipliers — when a finding touches regulated data, the highest single applicable multiplier applies (they do not stack):
| Regulation | Multiplier |
|---|---|
| GDPR | ×1.5 |
| SOX | ×1.4 |
| HIPAA | ×1.3 |
| PCI-DSS | ×1.2 |
| CCPA, APPI, PDPA, PIPEDA | ×1.1 |
Data-sensitivity multipliers — driven by the DSPM classification of the affected store, and overridable per tenant:
| Data classification | Multiplier |
|---|---|
| Restricted | ×3.0 |
| Confidential | ×2.0 |
| Internal | ×1.0 |
| Public | ×0.1 |
Crown-jewel multipliers — assets designated as crown jewels reflect that the same breach costs far more on a production system than on a dev resource:
| Crown jewel type | Multiplier |
|---|---|
| Payment processing service | 5× |
| Secrets / credentials store | 4× |
| Production database | 3× |
| PII-containing data store | 3× |
| Business-critical API | 2× |
Multipliers apply to the Loss Magnitude side of the equation only — they never inflate the probability side. A public dev bucket with test data and a public prod bucket with PHI have similar LEF but very different LM, which is exactly what the dollar figures should show.
Output Metrics
Per finding:
- P50 financial exposure — median loss estimate
- P90 financial exposure — 90th-percentile loss estimate, the worst plausible outcome
- Risk Reduction Value — exposure eliminated by fixing this finding
- Blast radius — assets, users, and data records at risk
Per portfolio:
- Total exposure — aggregate risk across all open findings
- Top-10 risks — ranked by P50 exposure
- Risk trend — total exposure over the last 90 days
- Exposure by domain — posture, identity, code, and vulnerability risk
Remediation Prioritization
The engine outputs a remediation queue ranked by Risk Reduction Value per fix:
- The ten fixes with the highest risk-reduction value, each with estimated engineering effort (T-shirt sized S/M/L) and the dollar exposure eliminated.
- The minimum-cut fix — the single change that collapses the most attack paths and removes the most exposure, cross-referenced with the Attack Path engine's choke-point ranking.
- A business-case summary for engineering: "these 5 fixes eliminate $12M in potential exposure and take 3 engineering days."
API
# Blast radius for the current environment
GET /api/v1/risk/blast-radius
# Crown-jewel assets and their exposure
GET /api/v1/risk/crown-jewelsFull schemas are in the API reference.
FAQ
Can I calibrate the model with our own financial data? Yes. Provide annual revenue, total data records processed, and breach-cost assumptions from your cyber-insurance policy — these override the industry-average defaults and sharpen the estimates for your organization.
Does this replace a formal risk assessment? No. Onam Risk Quantification is continuous automated estimation, designed to drive prioritization and board reporting. For SOC 2, ISO 27001, or regulatory audits, a formal FAIR assessment by a practitioner is still required.
How often are risk scores updated? After every scan (typically daily) and whenever the KEV or EPSS databases update — both are daily feeds from CISA and FIRST.org.
Next steps
- Attack Path — the reachability and choke-point data behind blast radius
- Vulnerability Management — the KEV and EPSS signals that calibrate TEF
- Compliance — the framework configuration that selects fine schedules
- Book a demo — see your estate's exposure in dollars