Risk Assessment Methods Compared: FAIR vs NIST SP 800-30 vs ISO 27005 vs OCTAVE Allegro

Most security teams pick a risk assessment method by habit or by whichever template came with the last audit, then discover a year later that it cannot answer the question the board or the regulator is actually asking. Open FAIR, NIST SP 800-30 Rev. 1, ISO/IEC 27005:2022 and OCTAVE Allegro all claim to assess information risk, but they were built for different decisions: pricing a loss, authorising a federal system, running an ISO/IEC 27001 management system, and getting a small team to a defensible answer quickly. This guide compares the four on what each produces, what it demands, where it fails and when to choose it, then shows how to combine them. It is for GRC leads, risk analysts, CISOs and internal auditors choosing or redesigning a method. Each method has its own deep guide on NHI Mgmt Group; this page is the chooser.

Status checked 14 November 2026: Open FAIR Risk Taxonomy (O-RT) 3.0.1 and Risk Analysis (O-RA) 2.0.1 from The Open Group; NIST SP 800-30 Rev. 1 (September 2012, final); ISO/IEC 27005:2022 (edition 4, October 2022, no amendment listed); OCTAVE Allegro as described in SEI technical report CMU/SEI-2007-TR-012 (May 2007).

Key takeaways

• Three are processes, one is a measurement model. NIST SP 800-30, ISO/IEC 27005 and OCTAVE Allegro tell you how to run an assessment; Open FAIR tells you how to measure a single loss scenario in money, and slots inside any of the other three.
• The output decides the method. If the decision needs a currency figure (insurance limits, control investment, risk appetite in money), use FAIR. If it needs auditable conformance to ISO/IEC 27001 clause 6.1.2, use 27005. If it supports a federal authorisation or a NIST RMF programme, use 800-30. If a small team needs prioritised risks in days, use OCTAVE Allegro.
• None of them fixes bad scenarios. All four fail the same way when scenarios are vague ("cyber attack on the cloud"), owners are missing or criteria are invented after scoring.
• Hybrids are normal and sensible. A common mature pattern is ISO/IEC 27005 or 800-30 as the programme process, qualitative screening for the long tail, and FAIR analysis for the top ten to twenty scenarios.
• Effort scales very differently. OCTAVE Allegro targets one to about seven people and a few days per asset; a credible FAIR programme needs trained analysts, calibrated estimators and loss data; 800-30 and 27005 sit in between, depending on how much you tailor them.

The four methods at a glance

For the methods individually, see the FAIR Model and Open FAIR Standard Guide, the NIST SP 800-30 Risk Assessment Guide and the ISO/IEC 27005 Information Security Risk Guide. For two-way detail, see FAIR vs NIST SP 800-30 and ISO 31000 vs ISO 27005.

What each method is built to answer

The fastest way to choose is to ask what question each method was designed around, because each one optimises for that question at the expense of others.

Open FAIR: how much could this cost, and how often?

Threat model: FAIR models a threat agent or community acting against an asset. Loss Event Frequency decomposes into Threat Event Frequency (contact frequency and probability of action) and Vulnerability (threat capability against resistance strength). Loss Magnitude splits into primary loss and secondary loss from regulators, customers or partners reacting, across six forms of loss: productivity, response, replacement, fines and judgments, competitive advantage and reputation.

Architecture in words: O-RA runs five stages: identify the loss scenario, evaluate Loss Event Frequency, evaluate Loss Magnitude, derive and articulate risk with Monte Carlo simulation, and model the effect of controls (grouped as avoidance, deterrent, vulnerability and responsive). Estimates are calibrated ranges rather than single values.

Failure modes: scenarios scoped too broadly to estimate; uncalibrated estimators producing false precision; results converted back to red, amber and green, which O-RA itself warns can mislead; and analysis effort spent on scenarios that a qualitative screen would have shown were immaterial.

NIST SP 800-30 Rev. 1: what is the risk to this system, mission or organisation?

Threat model: a generic risk model with five factors: threat (split into threat sources and threat events), vulnerability, predisposing condition, likelihood and impact. Appendices D to I give exemplary tables for threat sources, threat events, vulnerabilities and predisposing conditions, likelihood, impact and risk determination.

Architecture in words: four steps: prepare for the assessment, conduct it, communicate results and maintain it. You choose an assessment approach (quantitative, qualitative or semi-quantitative) and an analysis approach (threat-oriented, asset/impact-oriented or vulnerability-oriented), and you can apply it at Tier 1 (organisation), Tier 2 (mission or business process) or Tier 3 (information system). It sits beneath SP 800-39 and feeds the Risk Management Framework in SP 800-37.

Failure modes: copying the appendix tables wholesale instead of tailoring them; semi-quantitative scores (the publication shows bins such as 0 to 15 and 86 to 100) being added or multiplied as if they were measurements; and assessments that never reach Step 4, so results go stale between authorisations.

ISO/IEC 27005:2022: how do we run risk inside an ISO/IEC 27001 ISMS?

Threat model: deliberately open. The 2022 edition puts event-based identification (risk sources and scenarios) and asset-based identification (assets, threats and vulnerabilities) on an equal footing and lets you combine them.

Architecture in words: the ISO 31000 process specialised for information security: context establishment and risk criteria, identification, analysis, evaluation, treatment, then operation, communication, monitoring and review. Each stage maps to an ISO/IEC 27001:2022 clause (6.1.2 for assessment, 6.1.3 for treatment, 8.2 and 8.3 for performing them). Treatment options are modify, retain, avoid and share.

Failure modes: a register built to pass certification and never used for decisions; criteria agreed after scoring; asset-based inventories so detailed that the assessment never finishes; and residual risk "accepted" by people without authority to accept it.

OCTAVE Allegro: what are the risks to our most important information, quickly?

Threat model: information-centric. The team profiles a critical information asset, maps where it lives (technical, physical and people containers, inside or outside the organisation), lists areas of concern and expands them into threat scenarios using four threat trees: human actors using technical means, human actors using physical access, technical problems and other problems.

Architecture in words: eight steps in four activity areas. Establish drivers (Step 1, risk measurement criteria); profile assets (Steps 2 and 3, information asset profile and containers); identify threats (Steps 4 and 5, areas of concern and threat scenarios); identify and mitigate risks (Steps 6 to 8, identify risks, analyse risks, select mitigation approach). The SEI report says it does not depend on formal workshops and can be run by one person or a team of up to about seven.

Failure modes: treating the relative risk score as a measurement (the report says small score differences are not meaningful); profiling one asset and stopping; and relying on a 2007 report without adding current threat context such as cloud identities and SaaS integrations.

How scoring and prioritisation differ

The practical point: only FAIR produces numbers you can add up or compare with a control budget. The other three produce rankings whose meaning depends on criteria you define. That is not a weakness if the decision only needs a ranking, and the Quantitative vs Qualitative Cyber Risk Guide explains how to make ordinal scales defensible.

Decision guidance: choosing a method

Small versus large organisations: below roughly a hundred staff, OCTAVE Allegro or a lightly tailored 27005 process with a simple three-by-three scale is usually enough, and quantification is rarely worth the effort except for one or two scenarios that drive insurance. Large organisations typically need a programme process (27005 or 800-30), an enterprise roll-up (NIST IR 8286 Rev. 1 describes cybersecurity risk registers feeding enterprise risk management) and a FAIR capability for material scenarios. The Risk Management Guide covers the programme around the method.

Regulated sectors: no regulation covered here mandates one of these four by name. Check what your regulator or certification body expects to see as evidence before you choose; methods are judged on whether criteria, owners and decisions are documented.

Worked scenario: one risk, four methods

Take one scenario: a long-lived cloud access key belonging to a deployment pipeline is exposed in a public code repository and used to read a customer database.

• ISO/IEC 27005 (event-based): risk source "external opportunistic attacker scanning public repositories"; scenario "exposed pipeline key used to exfiltrate customer data"; consequence rated against the agreed consequence scale (say "major", because personal data and notification duties are involved); likelihood rated "likely" given public scanning activity; level compared with acceptance criteria; treatment "modify" by replacing static keys with federated workload identity, owner the platform engineering head, residual risk accepted by the data owner.
• NIST SP 800-30 (threat-oriented, Tier 3): threat source adversarial, outsider; threat event "obtain credentials from public code repository and access data"; predisposing condition "long-lived credentials in pipeline configuration"; vulnerability "no secret scanning on push"; likelihood and impact taken from the tailored Appendix G and H scales; risk from the Appendix I table; result documented for the system owner and authorising official.
• OCTAVE Allegro: information asset "customer database"; containers include the database service (technical), the pipeline that holds a credential to it (technical) and the engineers who manage keys (people); area of concern "credential leaked from pipeline"; impact areas scored, for example reputation High (3) times rank 4 = 12, fines High (3) times rank 5 = 15, productivity Low (1) times rank 3 = 3, giving a partial relative score of 30 that places it in a top pool and points to mitigate.
• Open FAIR: scope primary stakeholder (the company), asset (customer records), threat community (opportunistic external actors), loss event (confidentiality breach). Threat Event Frequency estimated from how often exposed keys are found and tried; Vulnerability from whether the key had read access and whether detection would revoke it in time; Loss Magnitude from response costs, notification, fines and judgments and customer churn, each as a calibrated range; Monte Carlo produces an annualised loss distribution. Rerun with federation in place to show the reduction against the project's cost.

The same root cause appears in all four; what differs is the decision each output supports. For the identity side of the scenario, see the NHI Risk Scoring Guide.

Implementation: adopting or switching methods

1. Write down the decisions the assessment must support. List them (treatment approval, budget, authorisation, insurance, board appetite) before picking a method. This is the only reliable selection criterion.
2. Agree criteria first. Likelihood and consequence scales, acceptance criteria and who may accept what level of risk, approved by management. ISO/IEC 27005 and OCTAVE Allegro Step 1 both start here for good reason.
3. Build one scenario library. Write scenarios with an asset, a threat source, an event and a consequence, reusable across methods. The Cyber Risk Scenario Library Guide shows the format.
4. Pilot on one business unit or system. Run the chosen process end to end, including treatment and acceptance. Time it, and record where assessors disagreed.
5. Add quantification selectively. Pick the five to ten scenarios that drive the biggest decisions and analyse them with FAIR; train at least two analysts and calibrate estimators before results go to the board.
6. Run old and new in parallel for one cycle. When replacing a method, keep the old register live until the new one has covered the same scope, then map old risks to new scenarios so nothing drops out silently.
7. Roll back cleanly if needed. If the new method stalls (no estimates, no owners), revert to the previous process for business-as-usual risks and keep the new method only for the pilot scope while you fix the cause.
8. Connect to the enterprise view. Feed results into a risk register that rolls up to enterprise risk management; the Risk Register Template and Risk Treatment Plan Template are ready to use.

Detection and measurement: is the method working?

• Decision coverage: percentage of material security investments and risk acceptances with a documented assessment behind them. Target close to 100 per cent for anything above your approval threshold.
• Acceptance hygiene: proportion of accepted risks with a named owner of the right authority and an expiry date. See the Security Exceptions and Risk Acceptance Guide.
• Freshness: median age of risk assessments for in-scope systems, and the share reassessed after a significant change.
• Inter-assessor consistency: for qualitative methods, how often two assessors rate the same scenario in the same band; persistent disagreement signals vague criteria.
• Calibration (FAIR): share of estimators' 90 per cent ranges that contain the true answer in calibration tests, and later, how often actual losses fall inside forecast ranges.
• Incident back-testing: for each significant incident, whether a matching scenario existed in the register and how it was rated.

Common failure patterns

• Method chosen for the template, not the decision: a 27005 register full of heat-map scores is then asked to justify a seven-figure budget it cannot support. Fix by stating the decision first.
• Arithmetic on ordinal scores: multiplying a likelihood "4" by an impact "5" and ranking on the product. 800-30 semi-quantitative bins and OCTAVE scores rank risks; they do not measure them.
• Quantifying everything: trying to run FAIR on 300 register entries exhausts analysts and produces uncalibrated numbers. Screen qualitatively, quantify the few that matter.
• Asset inventories that never end: asset-based 27005 or Allegro applied to every system before any risk is rated. Start event-based at the top, go asset-based only where needed.
• Machine identities missing from scenarios: service accounts, API keys and OAuth grants left out because they are not "assets" in the inventory, although credential misuse is a frequent incident path. See the Top 10 NHI Risks.
• No maintenance step: assessments done for an audit or authorisation and never refreshed after change, which all four methods warn against in their own terms.

Framework mapping

Practitioner checklist

• List the decisions your risk assessments must support before choosing a method.
• Get likelihood, consequence and acceptance criteria approved by management before any scoring.
• Name who may accept which level of residual risk, and record acceptances with expiry dates.
• Keep one scenario library that every method in use draws on.
• Use qualitative screening for breadth and FAIR only for the scenarios that drive large decisions.
• Never add or multiply ordinal scores as if they were measurements.
• Include service accounts, API keys, tokens and third-party integrations in scenarios with owners.
• Reassess after significant change, not only on the audit calendar.
• Back-test the register against every significant incident.

Standards and references

• The Open Group: Risk Analysis (O-RA) Standard
• NIST: SP 800-30 Rev. 1, Guide for Conducting Risk Assessments
• ISO: ISO/IEC 27005:2022 Guidance on managing information security risks
• Software Engineering Institute: Introducing OCTAVE Allegro (CMU/SEI-2007-TR-012)
• DTIC: Introducing OCTAVE Allegro, full report
• NIST: IR 8286 Rev. 1, Integrating Cybersecurity and Enterprise Risk Management

Related NHI Mgmt Group resources: Risk Management Guide, Cyber Risk Quantification Guide, Risk Assessment vs Risk Analysis vs Risk Management, ISO 31000 Risk Management Guide, GRC and Risk Certifications Compared Guide.