FAQGlobalISO/IEC 27005

ISO/IEC 27005 FAQ Impact

Assess the outcome of each scenario against organizational objectives and approved . Start with the loss of , then trace the operational disruption, loss, recovery cost, and other direct, indirect, cascading, or cumulative effects.

The standard supplies guidance rather than a mandatory scoring model, legal rule, or standalone certification scheme.

Author
Sorena AI
Published
May 9, 2026
Updated
Oct 15, 2026
Overview

Impact in a risk matrix should represent the to objectives, not the technical severity of a vulnerability. For each scenario, identify the failure, trace its business effects, and rate them with the organization's approved and units.

Search this module

Find a question or answer quickly

4 of 4 questions
Question 1

How should teams approach impact under ISO/IEC 27005?

ISO/IEC 27005 defines as the outcome of an event affecting objectives. Consequences can be certain or uncertain, direct or indirect, positive or negative, qualitative or quantitative, and can escalate through cascading or cumulative effects. Information security analysis normally focuses on negative effects from a failure to preserve .

Describe what happens to the affected business process or objective if the scenario occurs. Estimate lost time or data, disruption, severity, and recovery cost. Add legal, regulatory, contractual, safety, financial, customer, supplier, or reputational effects only when they are relevant to the defined context and supported by evidence.

  • Use defined categories with observable anchors, such as downtime, records affected, financial loss, recovery effort, or safety effect.
  • State how multiple types are combined and how the method handles a rare extreme consequence.
  • Keep vulnerability severity separate: a technically severe weakness can have limited business in one context and serious consequence in another.
  • Example: loss of confidentiality in a personal-data scenario can cause information loss and privacy harm, then create a separate legal or regulatory . Rate the supported consequence chain, not the vulnerability label.
  • Example: for a monetary scale, the organization's tolerable annual write-off and a loss that would threaten its survival can anchor the lower and upper ends. Intermediate bands should fit its context; ISO/IEC 27005 does not prescribe universal amounts.

What does impact mean in an ISO/IEC 27005 risk assessment?

ISO/IEC 27005 uses the term for the outcome of an event affecting objectives. On this page, impact means that consequence, not a vulnerability's technical severity. Start with the relevant loss of , trace the direct, indirect, cascading, and cumulative effects on the defined business objectives, then apply the organization's approved .

Does ISO/IEC 27005 prescribe a universal impact scale?

No. ISO/IEC 27005:2022 allows qualitative or quantitative and says the categories should fit the organization's internal and external context. Define the categories and their observable anchors clearly. Where different domains use different units, it is useful to cross-reference them to a common anchoring scale so equivalent consequences can be compared.

Should a Common Vulnerability Scoring System (CVSS) score or another vulnerability severity score determine impact?

No. A vulnerability score can inform the scenario, but impact depends on the to objectives in the assessed context. The same weakness can have limited consequence in an isolated test service and severe consequence in a safety-critical or regulated production process.

Question 2

What evidence should support the impact decision?

Keep the scenario, affected objectives and assets, chain, existing controls, units or scale, evidence, assumptions, uncertainty, rating rationale, and risk-owner input together. The record should explain why the chosen category fits the evidence rather than showing only a number.

  • Use business impact analyses, service targets, incident and loss data, data-classification records, contracts, regulatory requirements, recovery tests, supplier dependencies, and cost estimates that match the scenario.
  • Distinguish the immediate information security effect from later business effects and identify any dependency that can amplify the loss.
  • If evidence supports a range, record the range and the rule used to select a rating instead of presenting false precision.
Question 3

Who owns and approves impact decisions?

The risk owner should validate the to business objectives. Process owners, data owners, service owners, finance, legal, safety, privacy, resilience, and technical specialists can supply evidence for the consequence categories they understand. Their input does not replace the risk owner's accountable decision.

  • Identify who owns each affected objective and who can validate cost, downtime, legal, contractual, or safety assumptions.
  • Escalate consequences that cross business units or exceed the risk owner's delegated authority.
  • Record material disagreement or uncertainty when contributors cannot support one estimate.
Question 4

When should impact be reviewed?

Review impact when the affected objective, business process, asset value, , dependency, or recovery capability changes. A new vulnerability does not automatically change impact, but it can reveal a different scenario or path that needs assessment.

  • Trigger review after material business or system change, revised legal or contractual duties, new loss data, an incident, recovery-test results, or a change in units.
  • Reassess cascading effects when suppliers, shared services, locations, or data flows change.
  • Record the previous and new rationale and whether treatment priorities or acceptance changed.
Primary sources

References and citations

iso.org5 citations
Referenced sections
  • Official listing for ISO/IEC 27005:2022; its definitions and Clause 7.3.2 govern the consequence analysis summarized here.
  • ISO/IEC 27005:2022 definitions and Clause 7.3.2 support consequence analysis against objectives, including confidentiality, integrity, availability, operational loss, severity, and recovery cost.
  • ISO/IEC 27005:2022 Clause 7.3.2 identifies the scenario, affected objectives, consequence criteria, existing-control status, operational loss, severity, and recovery cost as inputs to consequence assessment.
Show 2 more
  • ISO/IEC 27005:2022 Clauses 7.2.2 and 7.3.2 assign risks to accountable owners and note that the risk owner typically estimates consequence with relevant inputs.
  • ISO/IEC 27005:2022 Clauses 7.3.2 and 10.5.2 identify changed scope, context, consequence units, asset values, and other risk factors as reasons to reassess consequences.
"Guidance on managing information security risks"
iso.org
Referenced sections
  • Official listing for ISO/IEC 27001:2022, which requires organizations to assess potential consequences for identified information security risks.
"Information security management systems — Requirements"
Show all related guides (21)

ISO/IEC 27005 Treatment Options FAQ

ISO/IEC 27005:2022 risk treatment options, how to choose controls, approve the plan, assess residual risk, and review effectiveness.

ISO/IEC 27005 Residual Risk Approval Guide

How ISO/IEC 27005 risk owners approve treatment plans and decide whether residual information security risk is acceptable, conditional, or needs more treatment.

ISO/IEC 27005 Residual Risk Approval Workflow

Decide whether residual information security risk can be accepted, who approves it, what evidence the decision needs, and when ISO/IEC 27005 calls for reassessment.

ISO/IEC 27005 Risk Assessment Template and Workflow

Create an ISO/IEC 27005 risk assessment record with the scenario, owner, consequence, likelihood, risk level, criteria result, evidence, uncertainty, and treatment priority.

ISO/IEC 27005 Risk Criteria Guide

How to define ISO/IEC 27005 risk acceptance and assessment criteria, including consequence, likelihood, thresholds, authority, evidence, and review.

ISO/IEC 27005 Risk Criteria Setup Workflow

Set ISO/IEC 27005 risk assessment and acceptance criteria, define decision authority, calibrate the scales, approve the method, and control later changes.

ISO/IEC 27005 Risk Management FAQ

Answers to common ISO/IEC 27005:2022 questions about risk assessment, treatment, acceptance, ownership, records, and review.

ISO/IEC 27005 Risk Register Workflow

Build a traceable ISO/IEC 27005 risk register that connects each scenario to its owner, assessment, treatment, residual-risk decision, evidence, and review status.

ISO/IEC 27005 Risk Treatment Plan Template

Create an ISO/IEC 27005 risk treatment plan with selected options, necessary controls, owners, resources, milestones, measures, residual risk, approval, and review.

ISO/IEC 27005 Scenario Library Guide

How to build and maintain an ISO/IEC 27005 risk scenario library using event-based and asset-based identification without turning generic prompts into assessed risks.

ISO/IEC 27005 vs FAIR Comparison

Use ISO/IEC 27005 for the information-security risk-management cycle and FAIR when a defined loss scenario needs quantitative, often financial, analysis.

ISO/IEC 27005 vs ISO 31000 Comparison

Use ISO 31000 for organization-wide risk principles and governance, and ISO/IEC 27005 for information-security risk decisions within an ISMS.

ISO/IEC 27005 vs NIST SP 800-30 Comparison

Compare ISO/IEC 27005:2022's full information-security risk cycle with NIST SP 800-30 Rev. 1's detailed risk-assessment guidance.

ISO/IEC 27005: Qualitative vs Quantitative Risk Analysis

Choose qualitative, quantitative, semiquantitative, or combined risk analysis under ISO/IEC 27005 based on the decision, data, uncertainty, and required comparability.

Using ISO/IEC 27005 in an ISO/IEC 27001 ISMS

How to use ISO/IEC 27005:2022 to operate the risk requirements of an ISO/IEC 27001 ISMS, including criteria, assessment, treatment, records, and review.