Use ISO/IEC 27005 to govern the full information-security risk cycle. Use FAIR inside that cycle when a defined loss scenario needs factor-based quantitative analysis, usually in financial terms.
FAIR does not replace context, risk criteria, treatment, owner acceptance, communication, or review. Neither publication is itself a universal legal requirement or a standalone organizational certification.
Structured answer sets in this page tree.
Cited legal and guidance references.
ISO/IEC 27005:2022 and solve different parts of the problem. ISO/IEC 27005 governs context, assessment, treatment, acceptance, communication, recording, monitoring, and review. FAIR decomposes a defined loss scenario into factors so an analyst can estimate the probable frequency and magnitude of loss, commonly in financial terms. Most teams do not need to choose one exclusively: keep ISO/IEC 27005 as the governing process and use FAIR for decisions that benefit from quantified loss ranges.
Compare purpose, scope, method, records, review, and reuse without treating voluntary guidance as a legal or standalone certification requirement.
Guidance for managing information-security risk across context, assessment, treatment, acceptance, communication, recording, monitoring, and review.
A factor model and taxonomy commonly used to estimate the probable frequency and magnitude of loss, often in financial terms.
| Dimension | ISO/IEC 27005 | FAIR | Operational implication |
|---|---|---|---|
| Purpose and scope | Information-security risk management for organizations of any type or size, aligned with ISO/IEC 27001 and based on ISO 31000. | A defined loss scenario that benefits from factor-based estimates of probable loss frequency and magnitude, commonly expressed in economic terms. | Use ISO/IEC 27005 for governance; add only where quantification improves a defined decision. |
| Ownership and decision authority | Risk owners need accountability and authority; contributors can include management, process, functional, department, and asset owners plus business and technical specialists. | Analysts build the model with people who understand the asset, threat, controls, operations, and loss exposure; the accountable risk owner uses the result. | Map analyst, treatment owner, risk owner, approver, and escalation roles instead of copying job titles between methods. |
| When to use it | Use for planned and change-driven information-security risk decisions, including ISMS planning, operations, treatment, and review. | Use where investment, prioritization, insurance, or acceptance decisions need defensible financial ranges rather than ordinal labels alone. | Apply the method when it improves a defined decision, not merely to produce another score or report. |
| Process | Establish context and criteria; identify, analyse and evaluate risks; treat them; obtain owner approval and residual-risk acceptance; communicate, record, monitor, and review. | Define the threat, asset, method, effect, stakeholder, and time horizon; estimate the factors that drive loss-event frequency and primary and secondary loss magnitude; calculate a range of outcomes; and test which inputs drive the result. | Place the analysis inside the ISO/IEC 27005 assessment step, then return the result to evaluation, treatment, acceptance, and review. |
| Evidence and records | Context, criteria, method, scenarios, owners, analysis rationale, evaluation, treatment, necessary controls, approvals, residual-risk acceptance, communication, monitoring, and review. | Scenario and time horizon, factor definitions, data sources, elicited estimates, ranges or distributions, assumptions, calculation settings, sensitivity, uncertainty, and decision use. | Reuse source evidence, but label the method, assumptions, criteria, and decision each record actually supports. |
| Review cycle | Longer strategic cycles address context changes; shorter operational cycles update scenarios and treatment, with additional reviews after material change. | Re-run when exposure, controls, threat frequency, loss data, business value, assumptions, or the decision materially changes. | Use planned and event-driven review rather than assuming one universal annual deadline. |
| Certification and assurance limits | Guidance, not a standalone certification. ISO/IEC 27001 is the certifiable ISMS requirements standard; adopted 27005 practices can be examined as supporting evidence. | A risk-analysis model, not an organizational certification or a universal legal compliance scheme. Confidence depends on scenario quality, transparent assumptions, suitable data, and review. | State the source of any binding, contractual, or certification requirement separately. |
| What can be reused | Context, risk statements, evidence, owners, criteria inputs, treatment records, and monitoring can be mapped where definitions remain clear. | Use results as one analysis method inside an ISO/IEC 27005-governed process, then evaluate them against criteria and route treatment and acceptance through risk owners. | Reuse facts and evidence; do not imply equivalence of methods, scores, or conformity claims without a documented mapping. |
| Decision rule | Use ISO/IEC 27005 when the objective is a complete information-security risk cycle integrated with an ISMS. | Use for a well-scoped loss scenario when quantified frequency and magnitude will change or clarify the decision. | Keep ISO/IEC 27005 as the governing cycle and use selectively for analysis; neither has to displace the other. |
Information-security risk management for organizations of any type or size, aligned with ISO/IEC 27001 and based on ISO 31000.
A defined loss scenario that benefits from factor-based estimates of probable loss frequency and magnitude, commonly expressed in economic terms.
Use ISO/IEC 27005 for governance; add only where quantification improves a defined decision.
Risk owners need accountability and authority; contributors can include management, process, functional, department, and asset owners plus business and technical specialists.
Analysts build the model with people who understand the asset, threat, controls, operations, and loss exposure; the accountable risk owner uses the result.
Map analyst, treatment owner, risk owner, approver, and escalation roles instead of copying job titles between methods.
Use for planned and change-driven information-security risk decisions, including ISMS planning, operations, treatment, and review.
Use where investment, prioritization, insurance, or acceptance decisions need defensible financial ranges rather than ordinal labels alone.
Apply the method when it improves a defined decision, not merely to produce another score or report.
Establish context and criteria; identify, analyse and evaluate risks; treat them; obtain owner approval and residual-risk acceptance; communicate, record, monitor, and review.
Define the threat, asset, method, effect, stakeholder, and time horizon; estimate the factors that drive loss-event frequency and primary and secondary loss magnitude; calculate a range of outcomes; and test which inputs drive the result.
Place the analysis inside the ISO/IEC 27005 assessment step, then return the result to evaluation, treatment, acceptance, and review.
Context, criteria, method, scenarios, owners, analysis rationale, evaluation, treatment, necessary controls, approvals, residual-risk acceptance, communication, monitoring, and review.
Scenario and time horizon, factor definitions, data sources, elicited estimates, ranges or distributions, assumptions, calculation settings, sensitivity, uncertainty, and decision use.
Reuse source evidence, but label the method, assumptions, criteria, and decision each record actually supports.
Longer strategic cycles address context changes; shorter operational cycles update scenarios and treatment, with additional reviews after material change.
Re-run when exposure, controls, threat frequency, loss data, business value, assumptions, or the decision materially changes.
Use planned and event-driven review rather than assuming one universal annual deadline.
Guidance, not a standalone certification. ISO/IEC 27001 is the certifiable ISMS requirements standard; adopted 27005 practices can be examined as supporting evidence.
A risk-analysis model, not an organizational certification or a universal legal compliance scheme. Confidence depends on scenario quality, transparent assumptions, suitable data, and review.
State the source of any binding, contractual, or certification requirement separately.
Context, risk statements, evidence, owners, criteria inputs, treatment records, and monitoring can be mapped where definitions remain clear.
Use results as one analysis method inside an ISO/IEC 27005-governed process, then evaluate them against criteria and route treatment and acceptance through risk owners.
Reuse facts and evidence; do not imply equivalence of methods, scores, or conformity claims without a documented mapping.
Use ISO/IEC 27005 when the objective is a complete information-security risk cycle integrated with an ISMS.
Use for a well-scoped loss scenario when quantified frequency and magnitude will change or clarify the decision.
Keep ISO/IEC 27005 as the governing cycle and use selectively for analysis; neither has to displace the other.
ISO/IEC 27005:2022 is guidance for managing information-security risk in support of an ISO/IEC 27001 information security management system. Its process covers more than analysis: the organization establishes context and criteria, identifies owners, assesses and treats risks, decides whether residual risk is acceptable, records and communicates results, and monitors change.
is a risk-analysis model and taxonomy. It breaks a scoped loss scenario into related frequency and magnitude factors and is commonly used to express results in economic terms. The Open FAIR body of knowledge currently identifies Risk Analysis (O-RA) Version 2.0.1 and Risk Taxonomy (O-RT) Version 3.0.1 as its two standards. It can strengthen an ISO/IEC 27005 analysis, but it does not supply the surrounding ISMS governance or establish ISO/IEC 27001 conformity.
Keep one decision record that connects the ISO/IEC 27005 process to the analysis. Record the scope, purpose, risk criteria, owner, scenario, time horizon, treatment options, approval, residual-risk decision, and review trigger. For FAIR, also retain factor definitions, source data, elicited estimates, ranges or distributions, assumptions, calculation or simulation settings, sensitivity results, and uncertainty.
A financial output is not self-validating. Reviewers need to see why the scenario was scoped as it was, which inputs came from data or expert judgment, how controls affected the factors, and whether the result is precise enough for the stated decision.
Record the scenario, inputs, uncertainty, risk criteria, treatment decision, owner approval, and next review date.
Assign the analysis, evidence requests, treatment records, owner decision, and review checkpoints.
Review your current scope, evidence gaps, and next implementation steps.
Start with the ISO/IEC 27005 context, scope, risk criteria, and named risk owner. Define a specific loss scenario with the threat, asset, method, and effect that can produce loss, then apply to estimate loss-event frequency and loss magnitude over a stated period. Compare the resulting range with the organization's risk criteria and the cost and effect of treatment options.
Return the result to the ISO/IEC 27005 process. The risk owner decides whether to treat, avoid, share, or retain the risk under the organization's authority rules. Record the selected controls, treatment plan, residual-risk acceptance, communication, and monitoring conditions.
Do not treat a estimate as the complete risk-management process or as evidence of ISO/IEC 27001 conformity. Do not turn ordinal labels such as 1-to-5 ratings into money by arithmetic alone. Quantification needs defined units, a time horizon, defensible inputs, and an explicit account of uncertainty.
Financial estimates can make unlike treatment options comparable, but some consequences may need separate non-financial measures or decision constraints. Record what the model excludes instead of forcing every effect into an unsupported monetary value.
ISO/IEC 27005 calls for regular and change-driven updates rather than one universal annual deadline. Re-scope or re-run the analysis when the asset, threat community, control effectiveness, loss data, business value, assumptions, decision threshold, time horizon, or treatment option changes enough to affect the decision. Review the standards mapping when either the ISO/IEC 27005 edition or the O-RA or O-RT version changes.
"Factor Analysis of Information Risk"
"Information security management systems — Requirements"
"Guidance on managing information security risks"