ISO/IEC 27005: Information Security Risk Management Guidance

ISO/IEC 27005 is the international guidance standard for managing information security risks. It explains how to establish risk criteria, identify and analyse risks, decide how to treat them and keep the process running. It is not certifiable on its own, but it is the most widely used reference for the risk assessment and treatment process that ISO/IEC 27001 requires, so anyone pursuing ISO 27001 certification will meet it.

The current version, ISO/IEC 27005:2022, was rewritten to align with ISO/IEC 27001:2022 and ISO 31000:2018. It introduced event-based risk identification alongside the traditional asset-based approach, and gives more practical guidance on risk scenarios. This guide explains the process, the two approaches, risk criteria, treatment, documentation and how small software teams can apply it without excess paperwork.

What is ISO/IEC 27005?

ISO/IEC 27005 is published by ISO and IEC through joint committee JTC 1/SC 27, which also maintains ISO/IEC 27001 and ISO/IEC 27002. Its purpose is to help organisations fulfil the risk-related requirements of ISO/IEC 27001, specifically clause 6.1.2 (information security risk assessment), clause 6.1.3 (risk treatment), clause 8.2 (performing risk assessments) and clause 8.3 (implementing the risk treatment plan). It can also be used on its own by any organisation that wants a structured way to manage security risk.

As a guidance document, it uses "should" rather than "shall". It describes good practice and offers options, rather than prescribing one method.

History and current edition

The first edition was published in 2008, followed by revisions in 2011 and 2018. The 2022 edition, the fourth, was a substantial rewrite. Its main changes were:

• Alignment of terms and structure with ISO/IEC 27001:2022 and ISO 31000:2018.
• Introduction of risk scenarios as a central concept.
• Recognition of two approaches to identifying risks: event-based and asset-based.
• Restructured content, with an operational process clause and guidance on documentation.
• Reworked annexes with examples of criteria, scales and techniques.

Who should use it?

• Organisations implementing or maintaining ISO/IEC 27001, which need a documented risk method that produces consistent, valid and comparable results.
• Risk owners and security managers responsible for deciding on treatments and accepting residual risk.
• SaaS and IT service providers that must answer customer questions about how they assess security risk, including for SOC 2 risk assessment criteria.
• Consultants and auditors who assess risk processes.

Is it mandatory or voluntary?

Voluntary. ISO/IEC 27001 requires an organisation to define and apply a risk assessment process, but it does not require ISO/IEC 27005 specifically. Organisations can use other methods, such as ISO 31000, NIST SP 800-30, OCTAVE or FAIR, provided they meet ISO 27001's requirements. Using ISO/IEC 27005 simply makes alignment easier because the terms match.

The risk management process

ISO/IEC 27005 describes an iterative process with these elements:

1. Context establishment: understand the organisation, interested parties and their requirements, define scope, and set risk criteria.
2. Risk assessment, made up of:
   • Risk identification: find and describe risks, often as risk scenarios.
   • Risk analysis: understand the nature of each risk and determine its level from likelihood and consequences.
   • Risk evaluation: compare results with risk acceptance criteria and prioritise.
3. Risk treatment: choose options, determine necessary controls, compare them with ISO/IEC 27001 Annex A, produce a statement of applicability and a risk treatment plan, and obtain risk owners' approval and acceptance of residual risk.
4. Communication and consultation with stakeholders throughout.
5. Monitoring and review of risks, criteria and the process itself.
6. Recording and reporting as documented information.

The process runs in cycles. A first high-level assessment may be followed by detailed assessments of the highest risks, and the whole process is repeated at planned intervals and when significant changes occur.

Risk criteria

Before assessing risks, the organisation sets two kinds of criteria:

• Risk acceptance criteria: the level of risk the organisation is willing to accept, which can vary by risk type, and who can accept risks at different levels.
• Criteria for performing assessments: scales and methods for likelihood and consequences, and how they combine into a risk level.

Consequence scales usually cover impacts such as financial loss, legal and regulatory consequences, reputation, operational disruption, and harm to customers or individuals. Likelihood scales can be qualitative (rare to almost certain), semi-quantitative (1 to 5) or quantitative (probability per year). The 2022 edition stresses that criteria must produce consistent, valid and comparable results, which is also an ISO 27001 requirement.

Example scales for a small software company

The standard leaves scales to the organisation. A simple illustrative set might look like this, with a risk level calculated as likelihood multiplied by consequence:

Level	Likelihood	Consequence
1	Not expected in the next five years	Minor inconvenience, no customer impact
2	Could happen once in five years	Short internal disruption or small cost
3	Could happen once in two years	Customer-visible outage of hours, or limited data exposure
4	Likely within a year	Breach of customer data requiring notification, or a day-long outage
5	Expected several times a year	Large breach, regulatory action or loss of major customers

Acceptance criteria might then say that risks scoring 1 to 6 can be accepted by the system owner, 8 to 12 need a treatment plan approved by the head of engineering, and 15 or above need leadership approval and treatment within a set time. These are examples only; the right scales depend on the organisation's size, customers and obligations.

Event-based and asset-based approaches

The 2022 edition describes two ways to identify risks:

Approach	How it works	Best suited for
Event-based	Identifies strategic scenarios by considering risk sources and how they could use or affect the organisation's ecosystem and objectives, often at a high level.	Initial assessments, leadership discussions, smaller organisations, fast-changing environments.
Asset-based	Identifies assets, then threats to them and vulnerabilities, producing operational scenarios for each asset or asset group.	Detailed assessments of specific systems, technical teams, mature ISMS programs.

The approaches can be combined: an event-based assessment to identify the most important scenarios, followed by asset-based analysis of the systems involved. Many organisations previously thought ISO 27001 required an asset-based method; the 2022 editions of both standards make clear that it does not.

Risk scenarios

A risk scenario describes a sequence of events leading to an outcome that affects objectives. For example: "A threat actor uses stolen developer credentials to access the source code repository, inserts malicious code that is deployed to production, and exposes customer data, leading to regulatory penalties and loss of customers." Writing risks as scenarios makes them understandable to business owners and helps identify where controls can break the chain, such as MFA, code review, signed builds and anomaly detection.

Risk analysis and evaluation

Risk analysis estimates the likelihood of each scenario and its consequences, considering existing controls. The result is a risk level, usually from a matrix combining the two scales. Evaluation compares risk levels against acceptance criteria to decide which risks need treatment and in what order. Quantitative methods such as FAIR can be used for important risks where better estimates justify the effort. ISO/IEC 27005 does not require any particular technique; Annex A gives examples.

Risk treatment

The four treatment options are:

• Modify the risk by applying controls that reduce likelihood or consequence.
• Retain the risk, accepting it based on the criteria.
• Avoid the risk by stopping the activity or changing how it is done.
• Share the risk with other parties, for example through insurance or outsourcing, while recognising that accountability usually stays with the organisation.

For ISO 27001, the organisation determines all controls needed to implement the chosen options, compares them with Annex A to check nothing necessary is missed, and produces a statement of applicability. The risk treatment plan lists actions, owners, resources, deadlines and how results will be evaluated. Risk owners approve the plan and accept residual risks.

Applying it to cloud and SaaS environments

In cloud-hosted products, many traditional assets such as servers and networks are managed by the provider, so asset-based analysis shifts towards identities, configurations, data stores, pipelines and third-party services. Useful scenario sources include the shared responsibility model of each cloud provider, cloud security benchmarks, and incident reports from similar companies. Supplier risks deserve explicit scenarios, since outages or breaches at identity providers, payment processors or monitoring tools can affect customers directly. Infrastructure as code and automated configuration checks help keep the risk picture current between formal reviews.

Monitoring, review and documentation

Risks change with new products, suppliers, threats and incidents. The standard recommends monitoring risk factors, reviewing risk assessments at planned intervals and after significant change, and reviewing the risk process itself. Documented information typically includes the risk assessment process description, criteria, risk register, assessment results, risk treatment plan, statement of applicability and evidence of risk owner approvals.

How to apply it, step by step

1. Define scope and context, including interested parties and requirements.
2. Set risk criteria with simple likelihood and consequence scales and clear acceptance thresholds.
3. Run an event-based workshop with leadership to identify strategic scenarios.
4. Add asset-based analysis for critical systems, such as production, source code and customer data stores.
5. Analyse and evaluate each scenario, recording existing controls.
6. Choose treatments, check against Annex A and write the statement of applicability.
7. Create the risk treatment plan with owners and dates.
8. Get approvals and acceptance of residual risk.
9. Review quarterly or after major changes, and fully at least annually.

Documentation you will need

• Risk management methodology document.
• Risk criteria with scales and acceptance thresholds.
• Risk register with scenarios, owners, levels and treatments.
• Risk treatment plan and progress tracking.
• Statement of applicability.
• Risk owner approvals and residual risk acceptance.
• Review records.

Timeline and cost considerations

For a software company with 20 to 200 staff, designing a method and completing a first assessment usually takes two to six weeks. The standard itself is inexpensive to buy; the main cost is staff time. Spreadsheets work for small organisations; governance, risk and compliance (GRC) tools help larger ones link risks, controls, assets and evidence.

Benefits and limitations

• Benefits: consistent decisions on security spending; clear language for leadership; direct alignment with ISO 27001 audits; flexibility to use simple or advanced techniques.
• Limitations: it is guidance, so it does not give ready-made threat lists or scales; poorly calibrated scales produce misleading results; and overly detailed asset registers can become unmanageable.

Common mistakes

• Listing hundreds of assets with generic threats copied from templates.
• Risk scores that never change because assessments are not revisited.
• No real risk owners, with the security team accepting all risks.
• Ignoring suppliers and cloud services in scenarios.
• Treating Annex A as the starting point instead of a check.
• Acceptance criteria that are never defined, so evaluation is arbitrary.

Best practices, tools and technologies

• Keep scales simple, usually five levels, with clear descriptions tied to your business.
• Write risks as scenarios that business owners recognise.
• Use threat intelligence and incident data to inform likelihood.
• Link risks to controls and evidence in a GRC tool or structured register.
• Review risks whenever architecture changes, using threat modelling for new systems.
• Combine with ISO 31000 for enterprise risk alignment.

Most treatment plans call for engineering work such as MFA, encryption, logging and secure development. We build these into products through our web application development and maintenance and support services.

How ISO/IEC 27005 relates to other frameworks

Framework	Relationship
ISO/IEC 27001	Requires risk assessment and treatment; ISO 27005 explains how to do it.
ISO 31000	Generic risk management guidelines that ISO 27005 applies to information security.
ISO/IEC 27002	Control guidance used when selecting treatments.
NIST RMF and SP 800-30	US federal equivalents for risk management and assessment.
NIST CSF	Outcome framework whose Govern and Identify functions include risk assessment.

Real-world example

A 60-person Indian SaaS company preparing for ISO 27001 holds a half-day event-based workshop with its founders and engineering leads. They identify 15 strategic scenarios, including credential theft from developers, ransomware on office systems, a cloud misconfiguration exposing customer data and a key supplier outage. For the top five, they analyse the systems involved, record existing controls and choose treatments such as phishing-resistant MFA, infrastructure-as-code scanning and a second cloud region for backups. The risk register has 40 entries rather than 400, owners sign off, and the register is reviewed each quarter. The auditor accepts it because it is consistent, documented and used.

Next steps

1. Write a short risk methodology with criteria.
2. Run an event-based workshop.
3. Analyse critical systems in more detail.
4. Build the treatment plan and statement of applicability.
5. Schedule reviews.

Frequently asked questions

What is ISO/IEC 27005?

International guidance on managing information security risks, supporting the risk requirements of ISO/IEC 27001.

Is ISO/IEC 27005 certifiable?

No. Organisations certify to ISO/IEC 27001; ISO 27005 is guidance.

Is ISO 27005 required for ISO 27001 certification?

No. ISO 27001 requires a risk process but any method that meets its requirements is acceptable.

What is the current version?

ISO/IEC 27005:2022, the fourth edition.

What is the difference between event-based and asset-based approaches?

Event-based starts from risk sources and strategic scenarios; asset-based starts from assets, threats and vulnerabilities.

How is ISO 27005 different from ISO 31000?

ISO 31000 is generic risk management guidance for any risk; ISO 27005 applies it specifically to information security.

What are the risk treatment options?

Modify, retain, avoid or share the risk.

How often should risks be assessed?

At planned intervals, commonly annually, and whenever significant changes occur.

Can I use FAIR or NIST SP 800-30 instead?

Yes, if the method meets ISO 27001 requirements; they can also be combined with ISO 27005.

Who should accept residual risk?

Risk owners with the authority to manage the risk, not the security team alone.

How many risks should a register contain?

There is no fixed number. A small company may have 20 to 50 meaningful scenarios; quality and regular review matter more than volume.