ISO/IEC 27005 Information Security Risk Guide: Assessing and Treating Risk

Most ISO/IEC 27001 programmes pass certification with a risk register that nobody uses to make decisions. ISO/IEC 27001 says you must assess and treat information security risk but says little about how; ISO/IEC 27005 is the guidance document that fills that gap. The current fourth edition, ISO/IEC 27005:2022, was rewritten to align with ISO 31000 and with the 2022 edition of ISO/IEC 27001, and it introduced the choice between event-based and asset-based risk identification. This guide explains what the standard covers, how its process works in practice, where non-human identities belong in a risk assessment, how to produce evidence an auditor will accept, and how it maps to NIST SP 800-30 and NIST CSF 2.0. It is written for ISMS managers, GRC leads, CISOs and internal auditors.

Key takeaways

• It is guidance, not a certifiable standard. You certify against ISO/IEC 27001; ISO/IEC 27005 explains how to meet its risk clauses (6.1.2, 6.1.3, 8.2 and 8.3) in a way that holds up.
• The 2022 edition offers two identification approaches. Event-based (start from risk sources and scenarios) and asset-based (start from assets, threats and vulnerabilities) can be combined, and most mature programmes do.
• Risk criteria come before any scoring. Consequence scales, likelihood scales and acceptance criteria must be agreed by management first, or results cannot be compared or accepted.
• Every risk needs an owner who can accept it. Residual risk acceptance by an accountable risk owner, recorded, is what auditors test hardest.
• Machine identities are a risk source, not a footnote. Service accounts, API keys and OAuth grants should appear in scenarios with named owners, because the incidents that hurt most often start there.

What it is and who it applies to

ISO/IEC 27005:2022, titled "Information security, cybersecurity and privacy protection: Guidance on managing information security risks", is published by ISO/IEC JTC 1/SC 27, the same committee that owns ISO/IEC 27001 and 27002. ISO lists it as edition 4, published in October 2022, 62 pages, and it replaced the 2018 edition, which is now withdrawn. The ISO catalogue describes it as guidance to help organisations perform information security risk management in support of an ISMS based on ISO/IEC 27001, and states its alignment with ISO 31000. At the time of writing the catalogue showed no amendment or active revision.

• Who uses it: any organisation running or building an ISMS, of any size or sector. It is equally useful to organisations that are not seeking certification but want a defensible security risk method.
• What it is not: it does not prescribe a scoring method, a tool or a list of controls. It describes activities and outputs, and leaves technique choice to you (IEC 31010:2019 catalogues assessment techniques).
• Relationship to ISO 31000: ISO 31000:2018 gives generic risk management principles, framework and process; ISO/IEC 27005 specialises that process for information security. See the ISO 31000 Risk Management Guide.
• Relationship to ISO/IEC 27001: 27001 sets the requirements (shall statements) and the certification basis; 27005 explains how to meet them. See the ISO 27001 Certification Guide.

Structure and key requirements

Because ISO/IEC 27005 is guidance, it uses "should" rather than "shall". The practical requirements come from ISO/IEC 27001, and 27005 explains how to satisfy them. The table below shows the process stages as the 2022 edition organises them and the 27001 clause each one serves.

Event-based versus asset-based identification

The 2018 edition was strongly associated with asset-based assessment. The 2022 edition presents two approaches on an equal footing:

• Event-based: starts from risk sources (who or what could cause harm) and strategic scenarios (how an event would unfold and what it would affect). It suits management-level assessment, works quickly with limited asset data, and produces scenarios executives recognise, such as "a stolen CI/CD token is used to publish a malicious release".
• Asset-based: starts from an inventory of primary assets (information, business processes) and supporting assets (systems, accounts, networks), then identifies threats and vulnerabilities against each. It is thorough and maps cleanly to controls, but it is slow and can drown in detail.
• Combining them: a common pattern is event-based at the top (10 to 30 strategic scenarios owned by executives) and asset-based beneath it for the systems in scope, so that operational findings roll up into scenarios. NIST SP 800-30 Rev. 1 gives the same advice in its own terms, recommending that threat-oriented, asset/impact-oriented and vulnerability-oriented analysis be combined to reduce blind spots.

Treatment options

ISO/IEC 27005 uses the ISO 31000 treatment vocabulary adapted to security. In practice four options are used:

Retaining risk is a legitimate decision only when it is explicit, time-bound and made by someone with authority. See the Security Exceptions and Risk Acceptance Guide.

Identity and NHI requirements

ISO/IEC 27005 does not mention non-human identities by name; it is technology-neutral. The point is how its method handles them. Two of the most cited intrusions of recent years started with credentials that a risk process should have caught: in the Cloudflare Thanksgiving breach, one service token and three service account credentials were left unrotated after the Okta incident because they were believed to be unused, and in the Microsoft Midnight Blizzard breach a legacy test tenant account without MFA led to a legacy OAuth application with elevated access.

• As supporting assets: in asset-based assessment, treat service accounts, API keys, certificates, OAuth grants and AI agent credentials as supporting assets of the processes they serve, with an owner, privilege level and last-used date. An unowned credential cannot have a risk owner. See the Service Account Inventory Template.
• As risk sources and scenarios: in event-based assessment, write scenarios such as valid account abuse (MITRE ATT&CK T1078.004 Cloud Accounts), secrets in code or configuration (T1552.001 Credentials In Files) and token theft (T1528 Steal Application Access Token). These anchor likelihood estimates in observed attacker behaviour.
• Consequence criteria: make blast radius explicit. A key with read access to one bucket and a key with tenant-wide administrator rights cannot sit in the same consequence band.
• Likelihood criteria: include exposure factors specific to machine credentials: age since rotation, storage location (vault, environment variable, source code), whether MFA or conditional access can apply, and whether usage is monitored. See the NHI Risk Scoring Guide.
• Risk ownership: the owner of an NHI risk should be the business or service owner, not the platform team that issued the credential. See the NHI Ownership Guide.

Implementation steps

1. Set the criteria with management first. Agree a 4 or 5 point consequence scale with concrete anchors (financial loss bands, records exposed, hours of outage, regulatory notification), a likelihood scale with frequency anchors, and acceptance criteria stating which levels need which approver. Have top management approve them; this satisfies 27001 clause 6.1.2 a).
2. Choose the approach per layer. Event-based for the enterprise view, asset-based for in-scope systems. Document the choice and the reason in the methodology.
3. Build the minimum asset and identity inventory. Primary assets (key information and processes), then supporting assets including human and non-human accounts with owners. Do not wait for a perfect CMDB; record known gaps as a risk.
4. Run a pilot on one business unit. Test whether two assessors reach similar ratings for the same scenario. If they do not, the scales need sharper anchors before rollout.
5. Write scenarios and rate them. For each scenario record risk source, event, affected assets, existing controls, consequence, likelihood and level. Use the Risk Register Template as a starting structure.
6. Evaluate and plan treatment. Compare with acceptance criteria, select options, determine controls (from any source), then compare them with ISO/IEC 27001 Annex A to confirm nothing necessary is omitted. Produce the Statement of Applicability and the treatment plan with owners and dates.
7. Get formal acceptance of residual risk. Risk owners approve the plan and accept residual risk in writing, with expiry dates for anything retained above appetite.
8. Operationalise reassessment. Define triggers (major change, new supplier, significant incident, new threat intelligence) as well as an annual cycle. Link change management so that new integrations and service accounts trigger a light assessment.
9. Roll back safely. When changing methodology, keep the old ratings alongside the new for one cycle and reconcile differences, so that a scale change is not mistaken for a change in risk.

Where quantitative estimates are needed, for example for insurance or investment cases, ISO/IEC 27005 permits them. See the Cyber Risk Quantification Guide.

Evidence and assessment

Certification auditors assess the 27001 clauses, not 27005, but a 27005-aligned process produces exactly the documented information they look for.

Metrics that show it is working

• Owner coverage: percentage of risks, and of privileged non-human identities in scope, with a named, current owner (target 100 per cent).
• Treatment timeliness: percentage of treatment actions completed by their due date.
• Expired acceptances: number of retained risks past their acceptance expiry date (target zero).
• Reassessment latency: median days between a significant change or incident and the related risk reassessment.
• Incident traceability: share of significant incidents whose scenario already existed in the register; a low figure means identification is missing real risk.

Mapping to other frameworks

Key differences: NIST SP 800-30 structures assessment at three tiers (organisation, mission and business process, information system) and gives detailed appendices of threat sources, threat events and likelihood and impact scales, which many ISMS teams borrow as inputs to a 27005 process. ISO/IEC 27005 is more concerned with integration into the ISMS and with risk ownership and acceptance. See the NIST SP 800-30 Risk Assessment Guide and the NIST CSF to ISO 27001 Mapping Guide. The UK NCSC risk management collection is a useful complement for choosing techniques, describing component-driven and system-driven approaches and methods such as attack trees and scenarios.

Common pitfalls

• Scoring before criteria: teams fill a 5 by 5 heat map without agreed anchors, so a "4" means different things to different assessors and nothing can be accepted consistently.
• The register as an audit artefact: risks are written once for certification and not revisited after major change. Tie reassessment to change management and incidents.
• Annex A as the starting point: selecting controls from Annex A and then writing risks to justify them reverses the process. 27001 expects necessary controls to be determined from treatment, then compared with Annex A.
• Assumptions instead of evidence: "unused" credentials, "internal only" systems and "test" tenants are rated low without checking. The Cloudflare and Midnight Blizzard incidents above are both examples of this.
• Owners without authority: IT staff sign acceptances for risks that the business carries. Acceptance authority should follow the criteria approved by management. See the Three Lines Model for Cyber Risk Guide.
• No link to appetite: acceptance criteria are invented by the security team rather than derived from the board's appetite. See the Cyber Risk Appetite Statement Template.

Practitioner checklist

• Confirm you hold ISO/IEC 27005:2022 (fourth edition) and that the methodology no longer cites the withdrawn 2018 edition.
• Have top management approve consequence, likelihood and acceptance criteria with concrete anchors.
• Document whether you use event-based, asset-based or combined identification, and why.
• Include service accounts, API keys, OAuth grants and AI agent credentials as supporting assets with owners.
• Write identity scenarios mapped to ATT&CK techniques such as T1078.004, T1552.001 and T1528.
• Derive necessary controls from treatment, then compare with Annex A and justify every SoA entry.
• Record residual risk acceptance with owner, authority level and expiry date.
• Trigger reassessment from change management, new suppliers and significant incidents.
• Report owner coverage, treatment timeliness and expired acceptances to management review.

Standards and references

• ISO: ISO/IEC 27005:2022 Guidance on managing information security risks
• ISO: ISO/IEC 27001:2022 Information security management systems, Requirements
• ISO: ISO 31000:2018 Risk management, Guidelines
• IEC/ISO: IEC 31010:2019 Risk management, Risk assessment techniques
• NIST: SP 800-30 Rev. 1 Guide for Conducting Risk Assessments
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5
• NCSC: Risk management collection

Related NHI Mgmt Group resources: ISO 27001 Certification Guide · ISO 31000 Risk Management Guide · NIST SP 800-30 Risk Assessment Guide · Risk Register Template · Cyber Risk Quantification Guide