ISO/IEC 27005 (Information Security Risk Management)

Introduction: Why ISO/IEC 27005 Matters

ISO/IEC 27005 is the international standard that provides guidance on information security risk management (ISRM) within the context of an Information Security Management System (ISMS). Where ISO/IEC 27001 mandates that an organisation shall establish, implement and maintain an information security risk assessment and risk treatment process, ISO/IEC 27005 tells you how to actually do it. It is the connective tissue between the high-level 'shall' statements of ISO 27001 Clauses 6.1.2 and 6.1.3 and the operational reality of identifying, analysing, evaluating and treating risk on the ground.

The current edition, ISO/IEC 27005:2022, was substantially rewritten to align with ISO/IEC 27001:2022 and the general risk-management vocabulary and process of ISO 31000:2018. It replaced the 2018 edition and reframed the guidance around two lenses: an event-based approach (starting from strategic scenarios and threat sources) and an asset-based approach (starting from assets, threats and vulnerabilities). Crucially, ISO 27005 is a guidance standard — it is not a certifiable standard in its own right. You do not get 'certified to ISO 27005'; rather, you demonstrate conformance to it as the methodology underpinning your certifiable ISO 27001 ISMS. This distinction shapes every audit and every implementation decision in this guide.

For CyberSigma clients across India, the GCC and global markets, ISO 27005 is the practical engine that makes an ISMS defensible. Regulators (RBI, SEBI, IRDAI, SAMA, DPDP-driven data-protection expectations), customers running third-party risk programmes, and CERT-In empanelled auditors all want to see that risk decisions are repeatable, evidence-backed and traceable — which is exactly what a well-run ISO 27005 process delivers.

What is ISO/IEC 27005?

ISO/IEC 27005 is a guidance document that describes how to perform information security risk management aligned with the requirements of an ISO/IEC 27001 ISMS. It defines a structured, iterative and repeatable process for handling the risks to the confidentiality, integrity and availability (and related properties such as authenticity, non-repudiation and reliability) of information and information systems.

The standard deliberately does not prescribe a single method, tool or quantitative formula. Instead it provides a framework of activities, inputs, actions and outputs that an organisation tailors to its context, sector, risk appetite and maturity. This flexibility is a strength for practitioners but a challenge for auditors, because conformance is assessed against the organisation's own documented method and against the process discipline described in the standard, not against a rigid checklist of controls.

Core purpose and scope of the standard

• Provides guidance to support the ISMS risk requirements of ISO/IEC 27001 (Clauses 6.1.2 risk assessment and 6.1.3 risk treatment, plus 8.2 and 8.3 for operational execution).
• Describes the ISRM process: context establishment, risk assessment (identification, analysis, evaluation), risk treatment, acceptance, and the continual activities of communication/consultation and monitoring/review.
• Supports both the event-based approach (top-down, scenario and threat-source driven, useful for strategic and cyber-threat risk) and the asset-based approach (bottom-up, asset-threat-vulnerability driven, useful for operational granularity).
• Aligns terminology and process with ISO 31000:2018 so that information security risk integrates into enterprise risk management (ERM).
• Is applicable to all organisations regardless of type, size or sector — governmental, commercial, not-for-profit.

What ISO 27005 is NOT

• It is NOT a certifiable standard — there is no accredited certification against ISO 27005 itself.
• It is NOT a controls catalogue — that is the role of ISO/IEC 27002 and Annex A of ISO/IEC 27001.
• It is NOT a prescriptive quantitative methodology — it does not mandate FAIR, OCTAVE, EBIOS or any single technique, though these can all be used to implement it.
• It does NOT replace ISO 31000 — it specialises ISO 31000's generic risk management for the information security domain.

Who Must Comply / Who Should Use ISO 27005

Because ISO 27005 is guidance rather than a mandate, 'compliance' means adopting it as the methodology behind an ISMS risk process. The following table sets out who typically needs it and why.

Structure of ISO/IEC 27005:2022

ISO/IEC 27005:2022 is organised as a set of clauses that mirror the risk management process of ISO 31000, specialised for information security. The core normative guidance sits in Clauses 5 to 12, supported by annexes offering examples of assessment techniques, asset and threat catalogues, and vulnerability examples. The table below maps the clause structure so that both auditors and implementers can navigate the standard.

The six process activities at a glance

1. Context establishment — define scope, boundaries, risk criteria, roles and the organisation.
2. Risk identification — find what could go wrong (events/scenarios or assets/threats/vulnerabilities).
3. Risk analysis — estimate likelihood and consequence to produce a level of risk.
4. Risk evaluation — compare against risk criteria and prioritise for treatment.
5. Risk treatment — select options (modify, retain, avoid, share) and controls; build the treatment plan.
6. Communication & consultation and Monitoring & review — continual activities that wrap the entire process.

Master Assessment Checklist — Every Process Area & Requirement

This is the operational heart of the guide. Each subsection below corresponds to a clause/activity of ISO/IEC 27005:2022. For each, we enumerate exactly what an auditor should verify and the typical evidence an implementer must be able to produce. Do not skip any activity — a conforming ISRM process must demonstrate all of them, iteratively, and keep them synchronised with the ISO 27001 ISMS artefacts (risk assessment, risk treatment plan and Statement of Applicability).

1. Context Establishment (Clause 6)

2. Risk Assessment Overview (Clause 7.1)

3. Risk Identification (Clause 7.2)

4. Risk Analysis (Clause 7.3)

5. Risk Evaluation (Clause 7.4)

6. Risk Treatment (Clause 8)

7. Risk Acceptance (Clause 8.6)

8. Operation (Clause 9)

9. Communication & Consultation (Clause 10)

10. Monitoring & Review (Clause 10)

Scoping the Risk Management Programme

Scoping in ISO 27005 must be consistent with the ISMS scope defined for ISO 27001 — but it can be applied at multiple granularities: whole organisation, a single business unit, a product line, a specific system, or a project. A poorly scoped risk assessment is the most common root cause of certification findings, because it produces registers that either miss material risk or drown assessors in irrelevant detail.

Scoping dimensions to define

• Organisational scope: which legal entities, business units, departments and third parties are included.
• Geographic scope: which sites, data centres, cloud regions and jurisdictions.
• Information scope: which information assets and classifications (e.g., PII, PHI, cardholder data, IP).
• Technology scope: applications, infrastructure, networks, OT/ICS, endpoints, SaaS.
• Process scope: which business processes and their supporting assets.
• Approach scope: whether event-based, asset-based or hybrid, and the depth of analysis per tier.

Scoping decisions and their consequences

Implementation Approach (Phased)

A defensible ISO 27005 implementation is built in phases, each producing concrete deliverables that feed the next. The phasing below is CyberSigma's recommended path for a first full cycle, after which the process becomes iterative and continual.

Phase 1 — Establish Context & Governance

• Activities: confirm ISMS scope; define ISRM policy and methodology; set risk criteria (impact, likelihood, evaluation, acceptance); assign risk owners and RACI; select event/asset/hybrid approach.
• Deliverables: ISRM Methodology document, Risk Criteria matrix, Roles & Responsibilities RACI, approved scope statement.

Phase 2 — Identify Risks

• Activities: build/refresh asset inventory and classification; identify threats and threat sources; identify vulnerabilities via VA/PT and control-gap review; identify consequences; run scenario workshops for event-based risks.
• Deliverables: Asset register, Threat catalogue, Vulnerability register, initial risk scenario list.

Phase 3 — Analyse & Evaluate Risks

• Activities: assign likelihood and consequence using defined scales; compute inherent risk; compare against criteria; prioritise and record treat/retain/avoid/share decisions.
• Deliverables: populated Risk Register, risk heat map, prioritised treatment candidate list.

Phase 4 — Treat Risks

• Activities: select treatment options and controls; map controls to ISO 27001 Annex A; build the Statement of Applicability; produce the Risk Treatment Plan with owners and timelines; estimate residual risk.
• Deliverables: Statement of Applicability, Risk Treatment Plan, residual risk register, control implementation backlog.

Phase 5 — Accept, Communicate & Operationalise

• Activities: obtain risk-owner acceptance of residual risk; brief management and committees; embed treatment actions into projects and BAU; set up dashboards and reporting.
• Deliverables: signed risk acceptances, management risk report, operational tracking of treatment actions.

Phase 6 — Monitor, Review & Improve

• Activities: monitor threats/vulnerabilities/assets for change; review risks after incidents and changes; feed control effectiveness back into analysis; conduct internal audit and management review; plan the next iteration.
• Deliverables: updated register, management review minutes, internal audit report, continual improvement actions.

Maturity / Capability Model for ISRM

ISO 27005 does not define a maturity model, but assessing the capability of an organisation's risk process is essential for prioritising improvement. CyberSigma uses a five-level capability model (aligned to ISO/IEC 33000 / CMMI style scales) to benchmark ISRM maturity.

Using the maturity model

• Level 2 is the practical minimum to pass an ISO 27001 certification audit.
• Level 3 is the target for regulated organisations and mature vendor programmes.
• Levels 4-5 suit financial services, critical infrastructure and organisations reporting risk to boards.
• Assess each process activity (context, identification, analysis, evaluation, treatment, monitoring) separately — maturity is rarely uniform.

Assessment & Audit Approach

When CyberSigma assesses an organisation's conformance to ISO 27005 (typically as part of an ISO 27001 readiness or certification support engagement), we follow a structured lifecycle. Because ISO 27005 is guidance, the audit tests process discipline and traceability rather than a fixed control set.

1. Define audit scope and objectives — confirm which ISMS scope and which risk registers are under review.
2. Review documentation — ISRM methodology, risk criteria, scope, RACI, register, RTP, SoA and acceptance records.
3. Verify context establishment — confirm criteria are defined, approved and consistently applied.
4. Trace a sample of risks end-to-end — from identification through analysis, evaluation, treatment, control mapping and acceptance.
5. Test consistency — confirm scales, criteria and scoring are applied uniformly across the register.
6. Verify linkage to ISO 27001 artefacts — every SoA control justified by risk; every risk treatment reflected in the RTP.
7. Interview risk owners and assessors — confirm understanding of their responsibilities and of accepted residual risk.
8. Examine monitoring and review evidence — schedules, change-triggered updates, incident-driven updates, management review.
9. Assess maturity and identify gaps — score each activity against the capability model.
10. Report findings and remediation roadmap — nonconformities, observations, opportunities for improvement with priorities.

Evidence Request List

The following categorised evidence list is what CyberSigma requests at the start of an ISO 27005 conformance assessment. Assembling these in advance dramatically shortens the engagement.

Governance & methodology evidence

• ISRM policy and documented methodology (event/asset/hybrid).
• Risk criteria: impact scale, likelihood scale, evaluation criteria, acceptance criteria.
• ISMS scope statement and boundaries.
• Roles & responsibilities / RACI and risk owner assignments.

Assessment evidence

• Asset inventory and classification.
• Threat catalogue and threat intelligence inputs.
• Vulnerability register, VA/PT reports and control-gap analyses.
• Populated risk register with likelihood, consequence and inherent risk scores.
• Risk scenario library (for event-based approach).

Treatment & acceptance evidence

• Statement of Applicability with inclusion/exclusion justification.
• Risk Treatment Plan with owners, timelines and status.
• Residual risk register.
• Signed risk acceptance records and exception log.

Monitoring & assurance evidence

• Assessment and review schedules.
• Change- and incident-triggered risk update records.
• Control effectiveness metrics and test results.
• Management review minutes and internal audit reports covering ISRM.

Roles & Responsibilities

KPIs to Track

• Percentage of in-scope assets covered by a current risk assessment.
• Number of open risks above the acceptance threshold (and trend over time).
• Percentage of risks with an assigned, accountable risk owner.
• Risk treatment plan completion rate and on-time delivery percentage.
• Average age of overdue treatment actions.
• Residual risk trend (aggregate score) quarter over quarter.
• Percentage of accepted risks reviewed within their scheduled review date.
• Number of risks updated following incidents or significant changes.
• Control effectiveness pass rate for treatment controls.
• Time from risk identification to treatment decision.
• Percentage of SoA controls traceable to a documented risk.
• Maturity level score per process activity vs target.

Readiness Checklist

• ISRM methodology documented and approved by management.
• Risk criteria (impact, likelihood, evaluation, acceptance) defined and applied consistently.
• ISMS scope and risk management boundaries clearly defined.
• Risk owners assigned for every material risk.
• Asset inventory current, classified and owner-mapped.
• Threats and vulnerabilities identified with credible sources.
• Risk register populated with likelihood, consequence and risk levels.
• Risks evaluated against criteria and prioritised.
• Treatment options selected and controls mapped to ISO 27001 Annex A.
• Statement of Applicability complete with justifications.
• Risk Treatment Plan produced with owners and timelines.
• Residual risk calculated and formally accepted by risk owners.
• Communication and escalation paths established and used.
• Monitoring, review and change-triggered update processes operating.
• ISRM covered by internal audit and management review.
• Every SoA control traceable back to a documented risk.

Common Gaps We See

• Risk register exists but is disconnected from the Statement of Applicability — controls cannot be traced to risks.
• Risk criteria (especially acceptance criteria) are undefined, so acceptance decisions are inconsistent and undocumented.
• Assessment is a one-off certification exercise, never refreshed after changes or incidents.
• Likelihood and consequence scales are applied subjectively without documented definitions.
• Residual risk is not calculated or not formally accepted by an accountable risk owner.
• Asset inventory is incomplete, so whole categories of risk (SaaS, OT, shadow IT) are missed.
• Event-based strategic risks are ignored in favour of a purely asset-based checklist, missing systemic threats.
• Treatment plans lack owners, timelines or tracking, so actions stall silently.
• Threat identification relies on stale catalogues with no current threat intelligence.
• No monitoring of control effectiveness feeding back into re-analysis.
• Confusion between ISO 27005 (method) and ISO 27002 (controls), leading to a controls-first rather than risk-first approach.
• Attempting to 'get certified to ISO 27005' — a misunderstanding that surfaces in RFPs and vendor questionnaires.

ISO 27005 Mapped to Other Frameworks

ISO 27005 is the risk-methodology hub that connects to many other frameworks. Understanding these mappings helps organisations reuse a single risk process across multiple compliance obligations.

Frequently asked questions

Need help with ISO 27005?

CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.