ISO 27005 risk management: implementing it step by step

ISO/IEC 27005 is a guidance document: it contains no requirements and cannot be certified against. Its scope, freely available on the ISO Online Browsing Platform, gives it two objectives. The first is to assist organisations in fulfilling the requirements of ISO/IEC 27001 concerning actions to address information security risks. The second is to help them perform information security risk management activities, specifically risk assessment and treatment.

In other words, ISO/IEC 27001 says what your process must guarantee, and ISO/IEC 27005 explains how to build it. If you are looking for the definition of the standard, its history and what the 2022 edition changed, start with our article ISO 27005: the information security risk management standard explained. This guide does not repeat that overview: it deals with implementation.

One detail of how the standard is built helps when writing your own procedure. From Clause 7 to Clause 10, it presents every activity in the same pattern: the input needed, the action to carry out, what triggers it, what it produces, then implementation guidance. If you can answer these five questions for each of your steps, your process is described.

The structure of the standard follows the process. Clause 6 deals with context establishment, Clause 7 with risk assessment (identification, analysis, evaluation), Clause 8 with risk treatment. Clause 9 covers performing these activities over time, and Clause 10 the management system processes that support them: communication and consultation, documented information, monitoring and review.

Identification, analysis and evaluation together make up risk assessment, the term used by ISO/IEC 27001 and ISO 31000. "Risk analysis" is often used loosely for the whole: our article What is a risk analysis? sets out this vocabulary.

A risk assessment is not a document you write once. The standard presents the process as iterative: you can run it a first time in broad strokes, then come back to go deeper where it is worth it. Two decision points give it its rhythm. After evaluation, you ask whether the assessment provides enough to decide; if not, you go back to the context or the analysis. After treatment, you ask whether the residual risks are acceptable; if not, you extend the treatment.

The standard also distinguishes two rhythms. The strategic cycle is long-term: it reviews the context, the criteria and the main priorities when the organisation or its environment changes. The shorter operational cycle updates the scenarios, the risk levels and the progress of controls. On top of these come updates triggered by an event: an incident, a new system, a change of supplier.

1. Step 1 Establish the context Scope, requirements of interested parties, acceptance criteria and scales, choice of method.
2. Step 2 Identify risks Risk scenarios, event-based or asset-based approach, risk owners.
3. Step 3 Analyse risks Assess consequences and likelihood, determine the level of risk.
4. Step 4 Evaluate risks Compare with the criteria, rank, decide what goes to treatment.
5. Step 5 Treat risks Options, controls, comparison with Annex A, treatment plan, acceptance of residual risks.
6. Step 6 Monitor and review Update triggers, indicators, documented information, management review.
7. Links ISO 27001 and ISO 31000 Which ISO 27001 clauses the standard supports, and what it takes from ISO 31000.
8. Links EBIOS RM How the five workshops of the French ANSSI method map to the steps of the standard.
9. Reference Glossary The terms of the standard, rephrased, with their French equivalent.

Each chapter applies the step to the same fictitious company. Its scales, thresholds and scenarios are examples: the standard does not impose them, and yours will be different.

• Because ISO 27001 certification calls for it, in practice. ISO/IEC 27001 imposes no method, but its clauses 6.1.2 and 6.1.3 set out what the process must guarantee. ISO/IEC 27005 is written to meet them, and its vocabulary is the auditor's.
• Because regulation reasons in terms of risk. The NIS 2 Directive requires the entities concerned to take measures based on an all-hazards approach, including policies on risk analysis (Article 21). A process that follows a recognised standard is easier to justify.
• Because it is a common language. ENISA, the European Union Agency for Cybersecurity, identifies ISO 31000 and ISO/IEC 27005 as the most relevant risk management standards in its analysis of existing frameworks. In the United States, NIST SP 800-30 plays a comparable role for federal agencies.
• Because it leaves the choice of method open. An EBIOS Risk Manager analysis, which ANSSI, the French national cybersecurity agency, states conforms to ISO/IEC 27005:2022, fits within this framework without duplicate work (guide in French).