Search every question across sub-FAQs

ISO/IEC 27005:2022 recognizes two common starting points. The event-based approach identifies strategic scenarios by considering risk sources, events, interested parties, and consequences. It can reach a useful high-level view without first cataloguing every asset. The asset-based approach inspects primary and supporting assets, threats, and vulnerabilities to build detailed operational scenarios and identify asset-specific treatment.

The approaches differ mainly in where analysis starts. Event-based work often drills down from business exposure to contributing assets; asset-based work often builds up from assets to accumulated business consequences. Use either or both, but describe each scenario as a sequence or combination of events leading from an initial cause to an unwanted consequence.

ISO/IEC 27005 is guidance supporting ISO/IEC 27001. It does not require an event-based or asset-based format, complete inventory of every possible asset-threat-vulnerability combination, named threat-modeling technique, or universal scenario template. Another identification approach is acceptable when it produces consistent, valid, and comparable results.

A useful scenario record shows the scope and purpose, affected objectives, initial cause, risk source, events, consequence, relevant assets, threats, vulnerabilities, existing controls, and dependencies. It should also identify the evidence and assumptions used to estimate consequence and likelihood.

For asset-based work, document dependencies between primary and supporting assets so the same propagated risk is not assessed twice. For event-based work, show how the risk source can use the organization's ecosystem or business processes to reach the affected business asset.

For example, flooding, fire, power spikes, and vandalism can all affect one data centre. They may be aggregated for an enterprise exposure view, but ISO/IEC 27005 says they should remain separate for treatment when each hazard needs different controls. Likewise, a personal-data loss can be a specific instance of a broader data-loss scenario when its consequences and controls differ.

Assign each identified risk to a risk owner who can understand the business consequence and direct or escalate treatment. Analysts, architects, asset owners, process owners, suppliers, and control specialists can build the scenario, but contributing evidence does not by itself make them the risk owner. The owner must have both accountability and authority and should be assigned during the assessment, not after a treatment decision is already drafted.

Review a scenario when its path, evidence, or consequence can change. Strategic review addresses changes in objectives, business assets, risk sources, interested parties, or the wider ecosystem. Operational review updates assets, threats, vulnerabilities, dependencies, control effectiveness, and treatment. ISO/IEC 27005 sets no universal annual deadline; use planned intervals appropriate to the ISMS and additional review when significant changes are proposed or occur.

ISO/IEC 27005 defines consequence 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 confidentiality, integrity, or availability.

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.

Keep the scenario, affected objectives and assets, consequence 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.

The risk owner should validate the consequence 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.

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

ISO/IEC 27005:2022 describes inherent risk as the level without considering any controls and current risk as the level allowing for the effectiveness of controls already implemented. It defines residual risk as risk remaining after treatment. These are different assessment bases, so label the basis and control assumptions on every rating.

A no-controls inherent baseline can be useful for prioritization or comparing gross exposure, but it can be unrealistic for a process that has never operated without embedded controls. Current risk is often the more decision-useful starting point for information security treatment. After selecting or implementing treatment, reassess likelihood and consequence with the proposed controls and their effectiveness to determine residual risk.

Keep the scenario, scope, criteria, time horizon, consequence and likelihood evidence, rating basis, included and excluded controls, control effectiveness, uncertainty, owner, date, and rationale together. For residual risk, add the approved treatment plan, follow-up assessment, acceptance decision, conditions, and review trigger.

Keep one accountable risk owner for the same risk across its inherent, current, and residual views unless the risk itself moves to a different organizational owner. Analysts can calculate the ratings and treatment owners can implement controls, but the risk owner approves the plan and decides whether residual risk is acceptable.

Reassess the relevant view when the scenario, criteria, evidence, controls, or treatment changes. Inherent risk changes when the underlying no-controls scenario changes; current risk changes when the operating environment or existing-control effectiveness changes; residual risk changes as treatment is implemented, tested, changed, or fails.

Assess the likelihood of the identified scenario and its consequence with the organization's established criteria. ISO/IEC 27005 permits qualitative, quantitative, and semiquantitative analysis and does not require one universal probability scale or formula.

For deliberate threats, consider capability, motivation, resources, attractiveness, and the cost or benefit of the attack. For accidental or environmental sources, consider human factors, equipment failure, geography, and natural hazards. In every case, consider known weaknesses, compensating controls, and evidence of how effectively existing controls operate.

Keep the scenario, time horizon, scale, evidence, existing controls and effectiveness, dependencies, assumptions, estimate, uncertainty, assessor, and review trigger together. A score without its time period and scale definition is not comparable.

The risk owner remains accountable for the risk decision. Analysts and specialists can estimate likelihood, while system owners, control owners, threat specialists, suppliers, and operational teams provide evidence about exposure, vulnerabilities, control effectiveness, and event frequency.