ISO/IEC 27005: ISO/IEC 27005 – Tutorial (about 60 minutes)

ISO/IEC 27005 is the international guidance document on information security risk management: how an organisation sets up the context for managing risk, finds and analyses the things that could go wrong with its information, decides what to do about them, and keeps those decisions current. It is used mainly by organisations that run, or are building, an information security management system (ISMS) under ISO/IEC 27001, but its method works for any security risk programme. After this tutorial you will be able to explain the risk management process the standard describes, run a basic risk assessment and treatment exercise, and recognise the mistakes that make risk registers useless.

Free tutorial · about 60 minutes · 7 lessons · 4 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: The current edition is ISO/IEC 27005:2022, the fourth edition, titled "Information security, cybersecurity and privacy protection — Guidance on managing information security risks". It was published in October 2022 by ISO and IEC through their joint committee ISO/IEC JTC 1/SC 27, and it replaced the 2018 third edition (earlier editions appeared in 2008 and 2011). No newer edition or amendment has been published. The committee working group is discussing options for a future revision, possibly as a multi-part document, but no revision project with a defined scope had been set at the time of checking. Verified 2026-10-29.

Who this is for: security engineers, IT and cloud operations staff, developers, ISMS managers, internal auditors, compliance and privacy professionals, and project managers who have been asked to "do the risk assessment" and want to understand what a good one looks like. It is equally useful if you will be the person who owns a risk and has to approve how it is treated.

Prerequisites: none. Some familiarity with ISO/IEC 27001 helps, because ISO/IEC 27005 is written to support it, but every term used here is explained on first use.

By the end of this tutorial:

You will be able to explain what ISO/IEC 27005 is for, why it gives guidance rather than requirements, and how it supports ISO/IEC 27001.
You will be able to use the core vocabulary correctly: risk, risk source, event, consequence, likelihood, level of risk, risk owner, risk criteria, residual risk and risk scenario.
You will be able to describe the structure of the 2022 edition, including the strategic and operational cycles and the purpose of its Annex A.
You will be able to walk through context establishment, risk identification, analysis, evaluation, treatment and acceptance, and explain the difference between event-based and asset-based identification.
You will be able to explain how the work is checked in practice, including what certification auditors look for and why there is no organisational certificate against ISO/IEC 27005 itself.
You will be able to apply the method to a realistic organisation and produce defensible risk decisions.
You will be able to compare ISO/IEC 27005 with ISO 31000, ISO/IEC 27001, NIST SP 800-30 and other risk methods.

Lesson 1 – Origins, purpose and scope

Why risk sits at the centre of information security

No organisation can protect everything equally well. Budgets, people and time are limited, and attackers, accidents and failures do not hit every system with the same frequency or the same damage. Security therefore has to be a series of choices: which information matters most, what could realistically happen to it, how bad that would be, and which protections are worth their cost. Risk management is the discipline that makes those choices explicit, consistent and repeatable instead of leaving them to whoever shouts loudest or to the latest vendor presentation.

ISO/IEC 27001, the requirements standard for an information security management system, puts risk at its heart. It requires an organisation to define a risk assessment process, apply it, decide how to treat the risks it finds, and record those decisions. But ISO/IEC 27001 says what must be achieved in only a few short clauses. It does not explain how to build risk criteria, how to describe a risk so that people can analyse it, or how to connect the risk work to the rest of the management system. That is the gap ISO/IEC 27005 fills.

A short history

The first edition of ISO/IEC 27005 appeared in 2008, shortly after the first edition of ISO/IEC 27001, and drew on older national and international guidance on managing IT security. A second edition followed in 2011 to align with the then-new ISO 31000 risk management standard. The third edition in 2018 was a modest update for the 2013 version of ISO/IEC 27001. The fourth edition in 2022 was a substantial rewrite: it was aligned with ISO/IEC 27001:2022 and ISO 31000:2018, introduced the idea of two management cycles (strategic and operational), added the concept of risk scenarios built in two complementary ways, and replaced the older informative annexes with a single annex of example techniques.

Guidance, not requirements

The most important thing to understand about ISO/IEC 27005 is its nature. It is a guidance document. Its recommendations are written as "should" statements, and it contains no "shall" requirements that an organisation could be audited against. You cannot be certified to ISO/IEC 27005. Instead, you use it to design and run the risk activities that ISO/IEC 27001 does require, and that a certification auditor will check against ISO/IEC 27001.

The standard is also method-neutral. It does not prescribe one scoring formula, one risk matrix or one software tool. It describes the activities and the decisions they must support, and then offers examples. An organisation is free to use a simple qualitative matrix, a quantitative model that estimates financial loss, a scenario workshop, or a combination, as long as the results are consistent and useful for decisions.

Scope

ISO/IEC 27005 applies to every kind of organisation, whatever its size, sector or legal form. It covers risks to the confidentiality, integrity and availability of information in any form: data in systems and the cloud, paper records, and information held in people's heads. Although written with ISO/IEC 27001 in mind, its approach can support other frameworks that call for security risk assessment, such as the NIST Cybersecurity Framework, regulatory regimes that demand risk-based security, or customer assurance reports. It does not cover risk management for other domains such as financial or safety risk in depth, though the logic is similar and can be adapted.

Lesson 2 – Key concepts and vocabulary

Risk management fails quietly when people use the same words to mean different things. One person's "risk" is another person's "threat", and a register full of entries such as "ransomware" or "cloud" cannot be analysed. ISO/IEC 27005 relies on the vocabulary of ISO/IEC 27000 and ISO 31000. The definitions below are paraphrased explanations, not the official text.

Risk – the effect of uncertainty on objectives (the short ISO 31000 wording). In information security this is usually expressed as a combination of a possible event and its consequences, together with how likely it is. A risk is a statement about the future, not something that has already happened.
Information security risk – a risk associated with the potential loss of confidentiality, integrity or availability of information within the scope of the management system.
Risk source – anything that, alone or in combination, has the potential to give rise to risk. A criminal group, a careless insider, a storm or a software defect can all be risk sources.
Event – an occurrence or change of circumstances, such as a successful phishing attack, a power cut or a mistaken deletion. An event can have several causes and several consequences.
Consequence – the outcome of an event affecting objectives, for example a regulatory fine, lost revenue, harm to customers, or damage to reputation. Consequences can be direct or knock-on.
Likelihood – the chance of something happening, however it is measured: qualitatively ("unlikely"), as a frequency ("once in ten years") or as a probability.
Level of risk – the magnitude of a risk, obtained by combining its consequences and their likelihood according to the organisation's chosen method.
Risk scenario – a description of a sequence of events that leads from a risk source to consequences. Scenarios turn vague worries into something that can be analysed and treated. The 2022 edition puts scenarios at the centre of risk identification.
Risk criteria – the terms of reference against which the significance of a risk is judged: the scales for consequence and likelihood, how they combine, and which levels are acceptable.
Risk acceptance criteria – the part of the risk criteria that states when a risk may be accepted without further treatment, and by whom.
Risk owner – the person or entity with the accountability and authority to manage a particular risk. Typically a business or service manager, not the security team.
Risk treatment – the process of modifying a risk, for example by adding controls, stopping an activity, sharing the risk or deciding to retain it.
Control – a measure that maintains or modifies risk, such as a policy, a procedure, a technical safeguard or a physical barrier.
Residual risk – the risk that remains after treatment. It is never zero, and it must be consciously accepted by the risk owner.
Asset – anything that has value to the organisation. ISO/IEC 27005 distinguishes primary assets (information and business processes) from supporting assets (hardware, software, networks, people, sites and suppliers that the primary assets depend on).
Threat and vulnerability – a threat is a potential cause of an unwanted incident; a vulnerability is a weakness of an asset or control that a threat can exploit. Both are ingredients of a scenario, not risks on their own.

Putting the words together

A well-formed risk statement links these ingredients. Compare "ransomware" with "an organised criminal group (risk source) gains access through a phishing email to a staff laptop (event), exploits missing segmentation (vulnerability) to encrypt the order database (supporting asset), stopping customer orders for several days (consequence to a primary asset)". The second version tells you whom to involve, which controls might help and how to estimate likelihood and impact. That is the habit ISO/IEC 27005 is trying to build.

Uncertainty cuts both ways

ISO 31000 notes that the effect of uncertainty can be positive or negative. ISO/IEC 27005 focuses on negative effects on information security, but a good risk process also notices opportunities, such as a new cloud service that would remove a fragile in-house system. Treat the process as a way to make better decisions, not as a way to say no.

Lesson 3 – Structure of the standard

The 2022 edition is organised into ten clauses and one informative annex. Clauses 1 to 4 are the usual front matter: scope, normative references, terms and definitions, and an explanation of how the document is structured. The substance is in clauses 5 to 10.

Clause 5 – Information security risk management

Clause 5 introduces the overall process and the idea that risk management runs in cycles. It shows how the activities described in the later clauses fit together and how they relate to ISO 31000. The process has a familiar shape: establish the context, assess risks (identify, analyse, evaluate), treat them, and decide whether the remaining risk is acceptable. Communication and consultation, and monitoring and review, run alongside every step rather than happening once at the end.

Figure 1 – The information security risk management process: context, assessment, treatment and acceptance, with communication and monitoring running throughout.

Clause 5 also explains the two cycles that are new in the 2022 edition. The strategic cycle looks at the organisation as a whole over a longer period. It revisits the business context, the objectives, the risk criteria and the overall approach, and it considers broad scenarios driven by risk sources and their goals. The operational cycle runs more often and in more detail. It applies the criteria set in the strategic cycle to specific systems, services and changes, and it treats the risks it finds. The operational cycle feeds what it learns back into the strategic one, for example when incidents show that the criteria are unrealistic. Changes, incidents or new threats can also trigger an assessment outside either schedule.

Figure 2 – The strategic cycle sets direction and criteria; the faster operational cycle applies them and feeds lessons back.

Clause 6 – Context establishment

Clause 6 covers everything that has to be decided before anyone scores a risk: the organisational considerations (who is involved and with what authority), the requirements of interested parties such as customers, regulators and shareholders, how risk assessment will be applied (where, how often, at what depth), the risk criteria, and the choice of a suitable method. Many of the problems seen in practice trace back to skipping this clause.

Clause 7 – Information security risk assessment process

Clause 7 describes the three assessment activities. Identification finds and describes risks, and identifies a risk owner for each. Analysis assesses the potential consequences and the likelihood, then determines the level of risk. Evaluation compares those levels with the risk criteria and prioritises the risks for treatment.

Clause 8 – Information security risk treatment process

Clause 8 deals with choosing treatment options, determining all the controls needed to implement them, comparing those controls with the reference list in Annex A of ISO/IEC 27001, producing a Statement of Applicability, and formulating a risk treatment plan that the risk owners approve, including their acceptance of residual risks.

Clause 9 – Operation

Clause 9 is about doing the work in real life: performing assessments and treatments at planned intervals and whenever significant changes are proposed or occur, and keeping the results as documented information.

Clause 10 – Leveraging related ISMS processes

Clause 10 links risk management to the rest of the management system. It shows how the risk work connects to understanding the organisation's context, leadership commitment, communication, documented information, monitoring and measurement, management review, corrective action and continual improvement. In other words, risk management is not a separate project; it is woven into the ISMS.

Annex A – Example techniques

The informative annex offers examples that support the assessment process. It shows how consequence and likelihood scales and risk acceptance criteria might be built, and how risk matrices can combine them. It then gives practical techniques: how to describe assets, how to describe risk sources and what they are trying to achieve, how to build scenarios with the event-based and asset-based approaches, typical examples of threats and vulnerabilities, and how to monitor events that signal a change in risk. These are examples to adapt, not a mandatory catalogue. Do not confuse this annex with Annex A of ISO/IEC 27001, which is the list of reference controls.

Lesson 4 – How it works in practice

This lesson follows the process from start to finish, with the practical decisions at each step. Think of it as a recipe you can adapt to the size of your organisation.

Step 1 – Establish the context and the criteria

Start by agreeing the scope: which parts of the organisation, which services and which locations the risk work covers. In an ISMS this is the same as the ISMS scope. Identify the interested parties and what they require: contractual security clauses, data protection law, sector rules, customer expectations. Identify who will own risks and who has authority to accept them.

Next, build the risk criteria. A typical qualitative design has a consequence scale of four or five levels, each described in business terms (money, customers affected, legal exposure, service downtime, reputation), and a likelihood scale of the same size described as frequencies or probabilities. A matrix combines them into a level of risk. Finally, write the acceptance criteria: for example, low risks may be accepted by the service owner, medium risks need a treatment plan or an explicit decision by a senior manager, and high risks must be treated unless an executive accepts them in writing. Good criteria are calibrated to the organisation's real appetite and capacity for loss. A consequence called "severe" should mean the same thing to the finance director and to an engineer.

Step 2 – Identify risks

ISO/IEC 27005 describes two complementary ways to identify risks, both producing risk scenarios.

The event-based approach starts from the top. It asks which risk sources could target the organisation, what they would want to achieve, and which routes they might take, including through partners and suppliers in the wider ecosystem. It produces a smaller number of broad, strategic scenarios, such as "a competitor obtains our product designs through a compromised design agency". This approach is fast, involves business leaders, and suits the strategic cycle. It is closely related to the French national agency ANSSI's EBIOS Risk Manager method.

The asset-based approach starts from the bottom. It inventories primary assets and the supporting assets they depend on, then looks for the threats that could affect each supporting asset and the vulnerabilities those threats could exploit. It produces many detailed, operational scenarios, such as "an unpatched remote-access gateway lets an attacker into the payment network". This approach is thorough, suits the operational cycle, and links naturally to technical controls, but it can become slow and mechanical if applied to every laptop and cable.

Figure 3 – Event-based identification works top-down from risk sources, asset-based works bottom-up from assets; both feed the same scenario analysis.

The two are not rivals. A common pattern is to use the event-based approach to find what matters most to the business, then use the asset-based approach to examine the systems that support those scenarios. For every identified risk, record a risk owner. ISO/IEC 27001 explicitly requires risk owners to be identified, because a risk without an owner never gets decided.

Step 3 – Analyse risks

Analysis estimates two things for each scenario. First, the consequences: what would happen to the organisation's objectives if the scenario occurred, taking into account the controls already in place. Consider all relevant impact types, not only the IT outage. Second, the likelihood: how plausible the scenario is, given the motivation and capability of the risk source, how exposed the asset is, the weaknesses that exist, and how effective current controls are. Evidence helps: incident history, threat intelligence, vulnerability scan results, audit findings and industry reports. Then combine consequence and likelihood using the method chosen in step 1 to get the level of risk.

Qualitative methods use descriptive scales and are quick and easy to explain. Quantitative methods express likelihood as frequencies and consequences as monetary ranges, and can support cost-benefit decisions, but they need data and skill. Semi-quantitative methods assign numbers to qualitative levels. ISO/IEC 27005 accepts all of them; the test is whether different assessors would reach comparable answers and whether the results help people decide.

Step 4 – Evaluate and prioritise

Evaluation compares each level of risk with the acceptance criteria. Risks within the criteria can be accepted; the others need treatment. Evaluation also sets priorities, because treatment capacity is limited. Priority usually follows the level of risk, but other factors can matter, such as legal obligations, dependencies between risks, or a scenario that would affect many services at once.

Step 5 – Treat the risks

For each risk that needs treatment, choose one or more options. Risk modification changes likelihood or consequence by introducing, removing or changing controls. Risk retention means deciding to keep the risk as it is, on the basis of an informed decision. Risk avoidance means not starting, or stopping, the activity that gives rise to the risk. Risk sharing means sharing part of the risk with another party, for example through insurance or outsourcing, while remembering that accountability for the organisation's information is not handed over.

Next, determine all the controls needed to implement the chosen options. Controls can come from anywhere: ISO/IEC 27002, industry frameworks, vendor guidance, or the organisation's own design. Then compare the controls you have chosen with the list in Annex A of ISO/IEC 27001 to check that nothing necessary has been overlooked. Annex A is a cross-check, not a shopping list and not a complete set. The result of this comparison is recorded in the Statement of Applicability, which lists the necessary controls, why they are included, whether they are implemented, and why any Annex A controls are excluded.

Figure 4 – Risk treatment turns priorities into controls, a Statement of Applicability and a treatment plan that the risk owners approve.

The risk treatment plan says what will be done, who is responsible, what resources are needed, when actions will be completed and how results will be evaluated. The risk owners approve the plan and accept the residual risks that remain once it is implemented. If a residual risk is still above the acceptance criteria, the owner can ask for more treatment, or a person with sufficient authority can accept it with a recorded justification.

Step 6 – Communicate, monitor and review

Communication and consultation keep the right people informed and involved throughout: business owners provide consequence estimates, engineers provide vulnerability knowledge, and leaders receive clear summaries for decisions. Monitoring and review keep the picture current. Risks change when the business changes, when new threats appear, when controls weaken or when incidents reveal something new. Useful triggers for reassessment include a new product, a major architecture change, a merger, a new supplier, a serious incident and changes in law.

Roles and records

Typical roles are a risk management lead or ISMS manager who maintains the method and facilitates assessments, risk owners who decide, control owners who operate the controls, and top management who set the risk appetite and review the overall picture. Typical records are the documented method and criteria, a risk register describing each scenario with its owner, analysis and evaluation, the treatment plan, the Statement of Applicability, and evidence of approvals and reviews. Keep records proportionate: the goal is decisions you can explain and repeat, not paperwork for its own sake.

Lesson 5 – Assessment, certification and compliance

No organisational certificate against ISO/IEC 27005

Because ISO/IEC 27005 contains guidance rather than requirements, there is no accredited certification of organisations to it. A company that claims to be "certified to ISO/IEC 27005" is either confused or describing something else. Organisations are certified to ISO/IEC 27001 by independent certification bodies, which are themselves accredited by national accreditation bodies. ISO and IEC write standards; they do not audit or certify anyone.

How auditors look at risk work

During an ISO/IEC 27001 certification audit, auditors do not ask "did you follow ISO/IEC 27005?". They ask whether the organisation meets the risk requirements of ISO/IEC 27001, and an organisation that has followed ISO/IEC 27005 sensibly usually meets them. Auditors commonly check:

that a risk assessment process is defined, with risk criteria including acceptance criteria;
that the process produces consistent, valid and comparable results when repeated;
that risks to confidentiality, integrity and availability within the ISMS scope are identified and each has an owner;
that risks are analysed and evaluated against the criteria and prioritised;
that treatment options and necessary controls were determined from the risks, and compared with Annex A of ISO/IEC 27001;
that the Statement of Applicability is consistent with the risk register and with what is actually in place;
that risk owners approved the treatment plan and accepted residual risks;
that assessments are repeated at planned intervals and when significant changes occur, and that results are kept as documented information.

Auditors also test the links in both directions. They may pick a control in the Statement of Applicability and ask which risk it treats, or pick a high risk in the register and ask to see the treatment actions and evidence that they were done. Gaps in that traceability make it hard to show that controls were determined from the risk treatment decisions, which is what ISO/IEC 27001 asks for, so auditors probe it early.

Internal assessment of the risk process

Internal audit and management review are the organisation's own checks. A useful internal review asks practical questions: are the criteria still calibrated, do assessors score similar scenarios similarly, are treatment actions overdue, and did recent incidents correspond to risks already in the register? If a serious incident came from a scenario nobody had considered, the identification step needs attention. If incidents happened to risks that were rated low, the analysis or the criteria need attention.

Personal credentials

Several training and certification bodies offer personal credentials based on ISO/IEC 27005, typically for risk managers. These certify an individual's knowledge after training and an exam. They are useful for learning and for career signalling, but they say nothing about whether a particular organisation manages its risks well, and they are schemes run by those bodies, not by ISO or IEC.

Regulatory use

Many laws and regulations require organisations to manage security risk "appropriately" or on a "risk-based" footing, without naming a method. ISO/IEC 27005 offers a widely recognised way to show that this was done systematically. It does not by itself prove compliance with any law; the organisation still needs to map its legal requirements into its context and criteria.

Lesson 6 – Worked example

To bring the steps together, follow a fictional company, Harbour Pay, a 250-person payment services provider that processes card payments for small online shops. It is preparing for ISO/IEC 27001 certification and uses ISO/IEC 27005 to design its risk process.

Context and criteria

The ISMS scope covers the payment platform, the merchant portal, customer support and the supporting cloud infrastructure. Interested parties include merchants (who need availability and correct settlement), card schemes (with strict data security rules), the financial regulator, and the company's investors. The chief operating officer chairs a risk committee; service owners are designated as risk owners for their services; the head of security facilitates the method.

The committee sets a five-level consequence scale. Level 1 means negligible effect; level 3 means a loss in the low hundreds of thousands, up to a day of service disruption, or a reportable incident affecting a few merchants; level 5 means a loss that threatens the company's survival, loss of a key licence, or a public breach affecting most customers. The five-level likelihood scale ranges from "less than once in 20 years" to "several times a year". Multiplying the two gives a score from 1 to 25. Scores up to 4 are low and may be accepted by the service owner; 5 to 9 are medium and need a plan or a recorded decision by the chief operating officer; 10 and above are high and must be treated unless the chief executive accepts them in writing.

Strategic cycle: event-based identification

In a half-day workshop, executives and the security lead list risk sources and what they would want: organised criminals seeking card data or money, a disgruntled insider seeking revenge, a nation-state group seeking disruption of financial services, and accidental sources such as a cloud region failure. They consider routes through the ecosystem, including the software agency that builds the merchant portal and the cloud provider. Five strategic scenarios emerge. One of them is "criminals compromise the portal agency's build pipeline and insert code that captures merchant credentials, then use the credentials to redirect payouts". Its owner is the head of merchant services.

Operational cycle: asset-based identification

For the payment platform, the team lists primary assets (card data, settlement instructions, the authorisation process) and supporting assets (the database cluster, the container platform, the remote administration gateway, the on-call engineers, the cloud account). For each supporting asset they consider relevant threats and known weaknesses. A recent scan shows that the remote administration gateway is two patch releases behind and that administrator access uses passwords without a second factor. They write a scenario: "an attacker uses stolen administrator credentials on the gateway, which lacks multi-factor authentication, and alters settlement instructions, diverting merchant funds." The owner is the head of payment operations.

Analysis and evaluation

For the gateway scenario, the team estimates consequence 5: diverted funds, regulatory reporting, merchant losses and severe reputational damage. Considering phishing rates in the sector and the missing second factor, they estimate likelihood 3 (about once in three to five years). The score is 15: high. The portal agency scenario is rated consequence 4 and likelihood 2, a score of 8: medium. A scenario about a single cloud zone outage is rated consequence 2 and likelihood 2, a score of 4: low, because the platform already runs across three zones.

Treatment

For the gateway scenario, the owner chooses risk modification. The necessary controls are: multi-factor authentication for all administrative access, removing the gateway in favour of an identity-aware access proxy within three months, patching within the agreed window meanwhile, alerts on changes to settlement instructions, and a four-eyes approval rule for changes above a threshold. The team compares these with Annex A of ISO/IEC 27001 and confirms that they correspond to controls on authentication, privileged access, technical vulnerabilities, logging and monitoring, and segregation of duties. The comparison also reminds them that they had no control for reviewing privileged access rights, so they add one.

For the portal agency scenario, the owner combines modification and sharing: contract clauses requiring signed builds and timely breach notification, code review of every release before deployment, and an update to the company's cyber insurance. The owner records that insurance shares part of the financial consequence but not the responsibility towards merchants. The cloud zone scenario is retained: it is within the acceptance criteria, and the service owner signs it off.

Approval and acceptance

The treatment plan lists each action with an owner, budget, due date and success measure. The heads of payment operations and merchant services approve their parts. After treatment, the gateway scenario is re-rated: consequence remains 5, but likelihood falls to 1, giving a residual score of 5, which is medium. Because medium risks need a decision at chief operating officer level, the chief operating officer formally accepts the residual risk with a note to review it after the access proxy is in place. The Statement of Applicability is updated to show the new controls, why they are included and their implementation status.

Monitoring

Harbour Pay reviews the operational register quarterly and the strategic scenarios yearly. It also defines triggers: a new major merchant, a new supplier with access to production, a significant incident in the payments sector, or a change in card scheme rules. Six months later a phishing attack against the support team succeeds but is stopped by the second factor; the post-incident review records this as evidence that the treatment works and raises the likelihood estimate for credential theft in other scenarios. The finding is also carried into the next yearly strategic review of scenarios and criteria. This is the feedback loop from the operational to the strategic cycle that the standard describes.

What the example shows

Notice what made the decisions defensible: criteria written in business terms before scoring started, scenarios specific enough to estimate, named owners who made the decisions, controls derived from risks and then checked against Annex A, and a record of residual risk acceptance at the right level of authority. None of it required expensive tools.

Lesson 7 – Relationship to other standards and frameworks

ISO/IEC 27005 sits in a family of documents. Understanding what each one does prevents duplication and confusion.

ISO/IEC 27001 sets the requirements for the ISMS, including the risk requirements. ISO/IEC 27005 explains how to meet them. ISO/IEC 27002 gives guidance on implementing the security controls that come out of risk treatment. ISO/IEC 27003 gives guidance on implementing the ISMS as a whole; clause 10 of ISO/IEC 27005 follows a similar style for the risk-related parts. ISO 31000 provides the generic principles, framework and process for managing any kind of risk; ISO/IEC 27005 applies that process to information security. IEC 31010 describes a wide range of risk assessment techniques, such as bow-tie analysis and scenario analysis, that can be used inside the ISO/IEC 27005 process.

Outside ISO, NIST SP 800-30 Revision 1 is the US guide for conducting risk assessments, with a strong focus on threat sources, threat events and vulnerabilities. The NIST Cybersecurity Framework expects risk assessment as part of its Identify function and leaves the method open, so ISO/IEC 27005 can serve there. EBIOS Risk Manager, from the French cybersecurity agency ANSSI, is a detailed scenario-based method; ANSSI states that its 2024 version 1.5 is fully consistent with ISO/IEC 27005:2022. FAIR (Factor Analysis of Information Risk), standardised by The Open Group as Open FAIR, is a quantitative model that expresses risk in financial terms and can be used as the analysis technique within the process.

Standard or framework	Owner	Nature	Relationship to ISO/IEC 27005
ISO/IEC 27001	ISO/IEC	Requirements for an ISMS; certifiable	Defines the risk requirements that ISO/IEC 27005 helps to meet
ISO/IEC 27002	ISO/IEC	Guidance on information security controls	Source of controls chosen during risk treatment
ISO 31000	ISO	Generic risk management guidelines	Parent process and principles; ISO/IEC 27005 is the security-specific application
IEC 31010	IEC/ISO	Catalogue of risk assessment techniques	Techniques that can be used inside the assessment steps
NIST SP 800-30 Rev. 1	NIST (US)	Guide for conducting risk assessments	Alternative or complementary assessment method, threat-focused
EBIOS Risk Manager	ANSSI (France)	Scenario-based risk method	Detailed method close to the event-based approach
FAIR (Open FAIR)	The Open Group	Quantitative risk analysis model	Can serve as the analysis technique for monetary estimates

A practical way to combine them: use ISO 31000 and ISO/IEC 27005 to define the overall process and criteria, choose techniques from IEC 31010 or a quantitative model where data allows, take candidate controls from ISO/IEC 27002 and other catalogues, and evidence everything for ISO/IEC 27001 certification. Organisations that also report against NIST frameworks can usually reuse the same risk register.

Common pitfalls and best practices

Pitfalls seen again and again:

Starting with the spreadsheet. Teams score risks before agreeing criteria, so a "4" means something different to every assessor and the results cannot be compared.
Listing threats instead of risks. Entries such as "malware" or "insider" cannot be analysed or treated; they need to be turned into scenarios with consequences.
Treating Annex A of ISO/IEC 27001 as the starting point. Copying the control list and then inventing risks to justify it reverses the logic and produces a Statement of Applicability nobody can defend.
Security owns every risk. When the security team is named owner of all risks, business managers never make or accept decisions, and treatment stalls for lack of authority and budget.
Asset inventories that never end. Applying the asset-based approach to every device creates thousands of near-identical rows and hides the scenarios that matter.
A once-a-year ritual. A register updated only before the audit misses changes, incidents and new suppliers, and quickly stops reflecting reality.
Forgetting residual risk. Plans are approved, but nobody records what risk remains and who accepted it.

Best practices that work:

Write consequence scales in business language with concrete examples, and test them on a few sample scenarios before rolling them out.
Combine approaches: a short event-based workshop with leaders to find what matters, then asset-based depth on the systems behind the top scenarios.
Assign each risk to a business owner with real authority, and let the security team facilitate and advise.
Derive controls from risks first, then use ISO/IEC 27001 Annex A as a completeness check, and keep two-way traceability between risks and controls.
Define triggers for reassessment, such as major changes, new suppliers and significant incidents, in addition to the planned schedule.
Use incident and near-miss data to calibrate likelihood estimates and to test whether the register predicted what actually happened.
Keep the method as simple as possible while still giving consistent results; sophistication is only useful if people can repeat it.

Summary and key takeaways

ISO/IEC 27005:2022 is guidance on managing information security risks; it has "should" statements only and cannot be certified against.
It supports the risk requirements of ISO/IEC 27001 and applies the generic ISO 31000 process to information security.
The process runs from context establishment through identification, analysis, evaluation and treatment to acceptance, with communication and monitoring throughout.
A strategic cycle sets criteria and looks at broad scenarios; a faster operational cycle assesses and treats detailed scenarios and feeds lessons back.
Risks are best described as scenarios; the event-based approach finds them top-down from risk sources, the asset-based approach bottom-up from assets, threats and vulnerabilities.
Treatment options are modification, retention, avoidance and sharing; controls are determined from risks and then checked against ISO/IEC 27001 Annex A.
Risk owners approve treatment plans and accept residual risk, which must be recorded.
Good risk management is proportionate, repeatable, owned by the business and kept current by triggers and incident feedback.

Reflection questions

Think of a service you know well. Write one risk as a full scenario, naming the risk source, the event, the weakness exploited and the business consequence. Who should own it, and why?
How would you describe the top level of a consequence scale for your organisation so that a finance director and an engineer would agree on what it means?
Where in your organisation would the event-based approach add the most value, and where would the asset-based approach be more useful? How would you combine them without duplicating effort?
Pick a control that your organisation already operates. Can you trace it back to a specific risk it treats? If not, what does that tell you about the control or the register?
Which events in the past year (incidents, changes, new suppliers, new laws) should have triggered a risk reassessment, and did they?