ISO/IEC 27001 tells you that you must assess and treat information security risks, and what records the process must leave. It says very little about how. Teams writing their first risk method usually discover this when they sit down to define a likelihood scale and find the standard offers no help.
ISO/IEC 27005 is the companion that fills the gap. It is guidance on managing information security risks, written to support the requirements in ISO 27001. It is also long, abstract in places, and easy to over-apply.
This article covers what the current edition, ISO/IEC 27005:2022, gives you, how it fits beside clause 6 of ISO 27001, and which parts are worth adopting for a small or mid-sized ISMS.
What ISO 27005 is, and what it is not
ISO/IEC 27005 is a guidance document. Its recommendations are written as "should", not "shall". You cannot be certified against it, and an ISO 27001 certification body does not audit you against it.
That has a practical consequence. Writing in your risk method that you "follow ISO 27005" does not satisfy any requirement on its own. Your auditor tests whether your documented method meets clauses 6.1.2 and 6.1.3 of ISO 27001, and whether you ran it the way you wrote it. If you cite ISO 27005 and then deviate from it, the citation becomes something you have to explain.
The 2022 edition is the fourth. It replaced the 2018 edition and was revised to align with ISO/IEC 27001:2022 and with the vocabulary of ISO 31000:2018, the general risk management standard. If your method still quotes an older edition, check the language against the current text, because the structure and some of the emphasis changed.
How it sits beside ISO 27001 clause 6
Think of the relationship as requirement and explanation. Clause 6.1.2 requires you to set risk criteria, identify risks and their owners, analyze them, and evaluate them. ISO 27005 explains how each of those steps can be done, and offers options.
We cover the clause requirements themselves in ISO 27001 clause 6: risk assessment and treatment. The short version is that clause 6 is mandatory and method-neutral. ISO 27005 is where you go when you have to choose a method and want one an auditor will recognize as sound.
It helps most in three areas:
Risk criteria. It discusses consequence criteria, likelihood criteria and risk acceptance criteria in far more depth than the requirements do.
Identification approaches. It describes two distinct ways to find risks, covered below.
The ongoing process. It treats communication, monitoring and review as part of risk management, not as something added after the assessment.
The process in outline
ISO 27005 describes a cycle. In order:
Establish the context. Define the scope, the internal and external issues and interested party requirements that bear on risk, and your risk criteria. This draws directly on clause 4 of ISO 27001.
Identify risks. Find the scenarios that could affect the confidentiality, integrity and availability of information in scope, and name an owner for each.
Analyze risks. Assess the consequences and likelihood of each scenario, and determine a level of risk.
Evaluate risks. Compare each level against your criteria and decide which risks need treatment, and in what order.
Treat risks. Choose treatment options, determine the controls needed, and plan their implementation.
Accept residual risk. Risk owners decide whether what remains is acceptable.
Communicate, monitor and review. Keep stakeholders informed, watch for changes in the risks and in the context, and reassess when either changes.
The guidance also describes an iterative approach. You can run a high-level assessment first, then a detailed one only where the first pass shows it is worth the effort. For a small team this is the most useful idea in the document, because it gives you permission not to model everything at the same depth.
Two ways to identify risks
The 2022 edition describes two approaches to risk identification. You can use either, or combine them.
The event-based approach
You start from what could happen and who or what would cause it. You consider risk sources, such as a financially motivated attacker, a careless insider or a regional power failure, and the events they could bring about. The output is a set of scenarios at a level the business recognizes: "an attacker uses a stolen employee credential to export customer data".
This approach is fast, works well in workshops with business stakeholders, and stays close to what leadership actually worries about. Its weakness is coverage. It finds the risks people already think of and can miss the unglamorous ones.
The asset-based approach
You start from what you have. You list assets, then the threats to each and the vulnerabilities those threats could exploit. The output is more granular: "the production database is exposed to SQL injection through an unpatched application component".
This approach gives better coverage and connects naturally to an asset inventory, which Annex A control 5.9 of ISO 27001 asks for anyway. Its weakness is volume. A full matrix of assets, threats and vulnerabilities grows quickly and is hard to keep current.
Choosing between them
For most organizations a combination works. Use event-based scenarios at the top to capture what matters to the business, and asset-based analysis underneath for the systems that hold customer data or run production. ISO 27001 accepts either: it stopped requiring asset-based identification in its 2013 edition. Whichever you choose, write it into the method so the next assessment uses the same approach.
Turning scenarios into ratings
Identification produces scenarios. Analysis has to turn each one into a level of risk you can compare with the others, and this is where consistency matters. Clause 6.1.2 b) of ISO 27001 requires repeated assessments to produce consistent, valid and comparable results.
ISO 27005 discusses qualitative, quantitative and mixed approaches. For most teams the realistic choice is qualitative or semi-quantitative: defined scales for consequence and likelihood, each point described in words, combined through a matrix or a simple formula. The guide to likelihood and impact scoring covers how to write scales that two people would apply the same way.
Two habits are worth building into your method:
Rate the scenario, not the asset. A database is not high risk. A specific event affecting it, through a specific path, has a likelihood and a consequence.
Record the controls you rated against. If the rating assumes MFA is enforced, say so. When that control later fails, you know which ratings are now wrong.
Treatment and acceptance
ISO 27005 discusses the familiar treatment choices, which come down to changing the risk with controls, retaining it, avoiding it, or sharing it with another party. Our article on risk treatment options works through each one.
What the guidance adds is weight on residual risk. Treatment is not finished when a control is chosen. It is finished when the risk has been reassessed with the control in place and the risk owner either accepts what remains or sends it back for more treatment. That acceptance is the step clause 6.1.3 f) of ISO 27001 requires evidence for, and the one teams most often record poorly.
What to adopt, and what to leave
ISO 27005 is written for organizations of every size, so not all of it will fit yours. A pragmatic reading:
Adopt:
Defined consequence and likelihood scales, written in words
Risk acceptance criteria tied to your risk appetite
Named risk owners outside the security team
An iterative approach: broad first, deep where it matters
Reassessment triggers for significant change
Leave, at least at first:
Full asset, threat and vulnerability matrices across the whole estate
Quantitative modeling, unless you have reliable loss data to feed it
Heavy terminology in documents that business owners have to read
The test for anything you take from the guidance is whether you will do it every time. A simple method run consistently passes audit. An elaborate method run once does not. Write the method down, cite ISO 27005 where it informed a choice, and keep the results of each run in a risk register an auditor can follow. The ISO 27001 framework page covers the wider set of requirements.
How TrustLynce helps
TrustLynce keeps your risk register with scoring against the criteria you define, named owners, treatment plans, and a recorded acceptance of residual risk. The results of each assessment are retained, so you can show your method running at planned intervals.