ISO/IEC 27005 Lead Risk Manager cheat sheet

Risk is the effect of uncertainty on objectives; information security risk is usually expressed as a combination of the likelihood of a threat event and its consequence (impact) on information assets and business processes.

ISO/IEC 27000 vocabulary distinguishes asset, threat, vulnerability, likelihood, consequence, risk, residual risk, and risk owner; risk is not the same as vulnerability or threat.

Risk = f(likelihood, consequence). Qualitative scales use ordinal labels, semi-quantitative scales use ranked numeric bands, quantitative analysis uses monetary or frequency values.

Inherent risk is assessed before controls; residual risk is assessed after controls; target risk is the level the organization is willing to pursue.

Risk management principles include creating value, being integral to processes, supporting decision-making, explicitly addressing uncertainty, being systematic and structured, based on best available information, tailored, inclusive of stakeholders, dynamic and iterative, and transparent.

Risk appetite is the amount and type of risk an organization is willing to pursue or retain; risk tolerance is the acceptable deviation from appetite for a specific objective; risk capacity is the maximum risk it can bear.

Risk owner is accountable for managing a risk; risk assessor analyses it; control owner operates the control; these roles must not be conflated.

Risk treatment options are modify (mitigate), retain (accept), avoid, and share; ISO/IEC 27005 also references pursuing an opportunity when risk creates upside.

ISO/IEC 27005 is guidance for information security risk management supporting ISO/IEC 27001; it does not itself specify certifiable requirements.

The standard follows a process structure: context establishment, risk identification, risk analysis, risk evaluation, risk treatment, risk acceptance, plus communication/consultation and monitoring/review throughout.

ISO/IEC 27005:2022 restructured earlier editions toward alignment with ISO 31000 and ISO/IEC 27001:2022, using risk identification, analysis, evaluation, treatment, and monitoring/review activities.

It references ISO/IEC 27001 Annex A controls (organizational, people, physical, technological) as a control catalogue for treatment, not as a mandatory one-to-one mapping.

The standard supports both asset-based and event-based (scenario-based) risk identification approaches; organizations may combine them.

Risk criteria are defined during context establishment and include scales, impact types, risk acceptance criteria, and criteria for deciding whether risk needs treatment.

ISO/IEC 27005 complements ISO/IEC 27001 clause 6.1 (risk-based planning) and clause 8 (operation); it is not a substitute for ISO/IEC 27001 requirements.

The framework is iterative: monitoring and review outputs feed back into context establishment and risk identification.

ISO/IEC 27001 clause 6.1.1 requires planning actions to address risks and opportunities; 6.1.2 requires an information security risk assessment process with defined criteria and repeatable results; 6.1.3 requires a risk treatment process and Statement of Applicability.

Clause 6.1.2 requires defining and applying risk assessment criteria and ensuring assessments produce consistent, valid, comparable results.

Clause 6.1.3 requires selecting treatment options, determining necessary controls, comparing with Annex A, producing a Statement of Applicability, and obtaining risk owner approval.

Clause 6.1.3 also requires approval of residual risk by risk owners and documentation of the risk treatment plan.

Clause 8.2 requires performing risk assessments at planned intervals or when significant change occurs; clause 8.3 requires implementing the risk treatment plan.

Clause 9.1 requires monitoring, measurement, analysis and evaluation, including risk assessment effectiveness; clause 10 requires improvement.

The Statement of Applicability records each Annex A control, whether it is applicable, justification, and implementation status; exclusions require justification.

Risk assessment output must feed management review (clause 9.3) and the risk treatment plan must be tracked as part of operational planning and control (clause 8.1).

Context establishment defines external and internal issues relevant to the organization's purpose and affects the information security risk management process (ISO/IEC 27001 clause 4).

External context includes legal, regulatory, contractual, market, competitive, and threat environment factors; internal context includes governance, structure, capabilities, culture, and information systems.

Scope definition identifies organizational units, locations, business processes, information assets, and system boundaries covered by the risk assessment.

Risk criteria are established here: impact categories (confidentiality, integrity, availability, legal, financial, reputational, safety), likelihood scales, risk matrix, and acceptance thresholds.

Basic risk criteria include risk evaluation criteria, impact criteria, likelihood criteria, and risk acceptance criteria; these must be documented and consistently applied.

Stakeholder identification determines interested parties and their risk-related requirements, including regulators, customers, suppliers, and employees.

Constraints such as budget, time, legal requirements, and resource availability are recorded because they affect treatment decisions.

The output is a documented risk management context that makes subsequent identification, analysis, and evaluation repeatable and comparable.

Risk identification finds sources of risk, events, their causes and potential consequences; it should be systematic and repeatable.

Asset-based identification inventories information assets, their owners, and their value; scenario/event-based identification starts from threat events and traces affected assets and processes.

Common techniques include workshops, interviews, checklists, brainstorming, Delphi, structured what-if (SWIFT), HAZOP, FMEA, fault tree analysis, and attack trees.

Risk analysis determines consequences, likelihood, and level of risk; it may be qualitative, semi-quantitative, or quantitative, depending on data quality and decision needs.

Qualitative analysis uses scales such as low/medium/high; semi-quantitative assigns numeric values to scales; quantitative uses monetary values, annualized loss expectancy, or probability distributions.

Annualized loss expectancy (ALE) = single loss expectancy (SLE) × annualized rate of occurrence (ARO); SLE = asset value × exposure factor.

Uncertainty and sensitivity must be considered; analysis should record assumptions, data sources, and confidence levels.

Analysis outputs feed risk evaluation; if results are insufficient for decisions, analysis is repeated with more detail or better data.

Risk evaluation compares analysis results against risk criteria to determine whether risk is acceptable and whether treatment is required.

Evaluation outputs are typically: accept the risk, treat the risk, or re-analyse if information is insufficient.

Risk prioritization ranks risks by level, considering risk criteria and business impact, not only by raw score.

Risk criteria include risk acceptance thresholds defined during context establishment; risk above threshold requires treatment or explicit acceptance by the risk owner.

Evaluation should consider aggregated and cumulative risk across assets and processes, not only individual risks in isolation.

Evaluation results are documented in a risk register with risk level, criteria applied, and rationale for the decision.

Risk evaluation is not a one-time activity; it is repeated when context, criteria, or risk changes.

Treatment options: modify (reduce likelihood or consequence through controls), retain (accept), avoid (eliminate the activity), share (transfer via insurance or contracts).

Control selection should reference ISO/IEC 27001 Annex A and consider cost, effectiveness, and residual risk.

Residual risk must be compared with risk criteria; if it remains above acceptable levels, further treatment is required or the risk owner formally accepts it.

Risk acceptance must be documented with the risk owner's approval, rationale, and date; acceptance is a management decision, not a technical one.

The risk treatment plan defines actions, responsibilities, resources, timelines, and expected residual risk.

Controls should be proportionate and consider defence in depth; over-control creates cost and usability issues.

Treatment must be monitored for effectiveness; ineffective controls require reassessment and possible re-treatment.

Risk sharing does not remove accountability; the organization retains responsibility for outsourced or insured risks.

Communication and consultation are continuous activities that involve stakeholders in understanding risk, decisions, and treatment status.

Communication should be planned: who needs what information, in what form, and when; it should be timely, accurate, and tailored to the audience.

Consultation seeks stakeholder input to improve risk identification and analysis and to build ownership of treatment decisions.

Monitoring and review track changes in context, risk levels, control effectiveness, and treatment progress; they feed back into the process.

Key performance indicators for risk management include number of risks above threshold, treatment completion rate, and risk assessment coverage.

Recording and reporting must maintain the risk register, treatment plans, acceptance records, and assessment results as documented information.

Records support audit, management review, and traceability from risk to control to evidence.

Review triggers include significant change, incidents, new threats, regulatory change, and scheduled intervals defined in the risk management process.