CyphrQ
Menu

ISO/IEC 27005 Risk Management Explained: Process and Approaches

ISO/IEC 27005:2022 is guidance, not a certificate. What its risk process covers, event-based vs asset-based approaches, and how it supports ISO 27001.

By CyphrQ.ai

Written with AI assistance and human editorial review. Every figure linked to its source.

9 min read

ISO/IEC 27005:2022 is ISO's guidance on managing information security risk. It does not set requirements you can be certified against. It explains how to run the risk assessment and risk treatment work that ISO/IEC 27001 asks of an organisation: set the context, find and judge risks, decide what to do about them, then monitor and review. Think of it as the how-to behind 27001's risk requirements.

This piece belongs to the ISO standards subtopic and deals with a single standard. For the certifiable standard it supports, see the ISO/IEC 27001 explainer.

What is ISO/IEC 27005 and who publishes it?

ISO/IEC 27005 is published jointly by ISO and the IEC, and it is listed on the official ISO page. The same catalogue record is also available through two other routes: ISO's committee mirror of the entry and the Finnish Standards Association store, a national standards body.

What those pages show:

  • Edition 4, published October 2022 (the life cycle lists 25 October 2022).
  • Status: published, current (stage 60.60).
  • It replaces ISO/IEC 27005:2018, which is withdrawn, along with the 2011 and 2008 versions.
  • The scope says it guides organisations in meeting ISO/IEC 27001 requirements for addressing information security risks, and that it is "applicable to all organizations, regardless of type, size or sector."

The ISO committee entry also describes it as adapting the general principles of ISO 31000 to information security. If you want the generic risk framework first, the ISO 31000 explainer covers it.

What does ISO/IEC 27005 risk management cover?

It covers the full information security risk cycle: assessment, treatment, communication, monitoring and review. Because the standard is sold, not free, what follows is my paraphrase rather than its text.

The ISO27k Forum, an independent practitioner community, summarises the 2022 structure as a run of clauses covering risk management in general, establishing context, risk assessment, risk treatment, operation, and leveraging related ISMS processes, plus an annex of example techniques such as risk matrices. That is a community summary, not ISO's own wording, so check the standard for the exact layout.

In plain terms, the process looks like this:

  1. Set the context. Who are the stakeholders and risk owners? What is your risk appetite, meaning how much risk you will live with? Which method will you use, and what are the scope and criteria?
  2. Assess risk. Identify risks, analyse how likely and how serious they are, then evaluate them against your criteria to decide which need action.
  3. Treat risk. Choose options, write a treatment plan, and implement it.
  4. Communicate, monitor and review. Share results with decision makers, and revisit risks as things change.

The standard does not prescribe one scoring method. You choose a method that fits your organisation and apply it consistently.

What is the difference between event-based and asset-based risk approaches in ISO/IEC 27005?

The 2022 edition describes two ways to identify risk scenarios. A risk scenario is a short story of how something could go wrong: a cause, an event and a consequence.

Event-based approach Asset-based approach
Direction Top down: start from what could happen to the organisation Bottom up: start from what you own
Starting point Risk sources and the events they could cause Assets, the threats against them and their weaknesses
Typical question "What would a ransomware outage do to our business?" "What can go wrong with this database server?"
Strength Fast, board-level view of impact Detailed, specific treatment choices
Weakness Can stay vague about which systems matter Slow, and can drown you in asset lists

The ISO27k Forum page lists these approaches alongside scenario-based and controls-based perspectives, but does not explain them, and training providers describe the event-based approach as more strategic and the asset-based one as more detailed. The standard's own wording was not checked here, so treat the table as a practitioner reading, not a quotation.

The practical point is that they are complementary. Event-based thinking tells you which scenarios matter to the business. Asset-based thinking tells you which systems and data sit in those scenarios and what to fix.

Who uses ISO/IEC 27005, and can you be certified against it?

You cannot be certified against ISO/IEC 27005. It is guidance, not a requirements standard. No certificate says "27005 compliant" in the way an ISO/IEC 27001 certificate says an ISMS was audited. The ISO committee page for 27001 presents certification as optional and tied to that standard, and says certificates from an accredited body add confidence because an accreditation body has independently confirmed the certification body's competence.

Who uses 27005:

  • Organisations building or running a 27001 ISMS. It is the main reference for designing the risk process.
  • Risk managers, security leads and consultants who need a defensible method.
  • Organisations that are not certified at all but want a structured way to explain their security priorities. The ISO27k Forum notes the approach is generic enough to support other frameworks.

People can, however, be certified as individuals. PECB, a professional certification body, runs a three-day ISO/IEC 27005 Risk Manager course with an exam leading to a personal credential. That is a training credential, not an organisation certificate.

How does ISO/IEC 27005 relate to ISO/IEC 27001 and ISO 31000?

  • ISO/IEC 27001 is the certifiable requirements standard for an information security management system. It tells you that you must assess and treat risk. ISO/IEC 27005 tells you one good way to do it. To see an ISO audit from the customer's side, read the SOC 2 vs ISO 27001 comparison.
  • ISO 31000 is the generic risk management guideline for any kind of risk. ISO/IEC 27005 applies that thinking to information security alone.
  • ISO/IEC 42001, the AI management system standard, has its own risk and impact assessment needs; the ISO/IEC 42001 explainer covers it.

Two citable facts about the alignment. The ISO catalogue entry says the 2022 edition supports an ISMS based on ISO/IEC 27001. And the ISO27k Forum page says the standard is intended to help you interpret 27001's risk requirements and that the fourth edition addresses how to use 27001's Annex A, which that page describes as an incomplete set of possible controls to check against your identified risks. The same page notes the standard concentrates on reducing risk through controls while paying less attention to avoiding, sharing or accepting risk. Good practice is to weigh all four options.

How does adopting ISO/IEC 27005 work in practice?

There is no audit of 27005 itself. Instead, you adopt its process and an auditor tests the result as part of a 27001 audit, or a customer reads your risk register. A realistic path:

  1. Write a short risk method. One or two pages: scales for likelihood and impact, the risk appetite, who approves treatment, and how often you review.
  2. Pick your starting approach. Many teams start event-based with leadership to agree the five or ten scenarios that would hurt most, then go asset-based on the systems involved.
  3. Run the first assessment and keep records. Dates, owners, decisions.
  4. Treat and track. Assign each treatment an owner and a date.
  5. Review on a schedule and after changes. A new supplier, a breach, a cloud migration.

The ISO27k Forum page reports that earlier editions appeared in 2008, 2011 and 2018, and that the standards working group is considering a revision, possibly as a multi-part standard. If that happens the layout may change, so check the edition when you cite it.

Going deeper: for security and IT teams

Where it plugs into 27001. Your auditor will not ask "do you follow 27005". They will ask for evidence that you defined a risk assessment process, applied it, kept results, and chose treatment from the outcome. 27005 is one way to structure that evidence. Cite it in your risk method so the link is explicit, and state the edition.

Evidence an auditor asks for. Keep these ready:

  • A documented risk method with criteria for acceptable risk and for performing an assessment, approved by management.
  • A risk register with scenario descriptions, an owner for each risk, the assessed level, and the decision (modify, retain, avoid or share).
  • A risk treatment plan with owners, dates and status.
  • Proof the assessment was repeated: dated versions, or minutes of reviews after significant change.
  • Records showing risk owners accepted residual risk, not just the security team.
  • The mapping from risks to the Annex A controls you selected, so your Statement of Applicability (the list of controls you apply and why) is traceable to your risks.

Scenario writing. A usable scenario names a source, an event, the affected asset or process, and a consequence. "Credential stuffing against the customer portal leads to account takeover and data exposure" is testable. "Cyber attack" is not. For each scenario record the existing controls and why they are or are not enough. For attack-technique detail, many teams pair scenarios with MITRE ATT&CK, but that is a team choice and not something 27005 requires.

Likelihood and impact scales. Use defined bands, not adjectives. Express impact in business terms such as hours of downtime, records exposed or regulatory exposure, and agree these with finance and legal. A common nonconformity is a method that is written but not followed: the register shows scores that cannot be reproduced from the criteria.

Common nonconformities, described generally.

  • The risk register was built once and never reviewed.
  • Treatment decisions have no owner or date.
  • Exclusions in the Statement of Applicability have no link to a risk.
  • The person who accepted a risk had no authority to own it.
  • The assessment covers servers but ignores suppliers, SaaS and people.

Monitoring. The ISO27k Forum summary mentions an operation clause on regular review of risks and treatments. Turn that into signals: vulnerability scanner output, incident trends, supplier changes and audit findings feeding the register. For vulnerability inputs, see how CVSS, EPSS and KEV can inform likelihood.

Combining with regulation. If NIS2 applies to you, a documented risk process helps as evidence; the NIS2 explainer covers what the law itself requires. Ask your legal adviser what a 27005-based process does and does not show.

Questions to ask. Which approach did we use and why? Can a second assessor reproduce our scores? Who owns each residual risk? When was the method last reviewed against the current edition?

What this post did not verify. The standard's text was not checked here, so clause numbers, exact definitions and the standard's own description of event-based and asset-based approaches should be checked against a licensed copy.

Learn more

Key takeaways

  • ISO/IEC 27005:2022 (edition 4, October 2022) is guidance for information security risk management. It is not certifiable.
  • It supports ISO/IEC 27001's risk assessment and treatment requirements and adapts ISO 31000 to information security.
  • The event-based approach starts from scenarios and impact; the asset-based approach starts from assets, threats and weaknesses. Use both.
  • Auditors test your risk records, not your citation of 27005.
  • Keep a risk method, a reviewed register, owned treatment decisions and accepted residual risk.

Sources