How to conduct an ISO 27001 risk assessment: a step-by-step guide

The risk assessment is the engine of ISO/IEC 27001:2022. Everything else — the controls you select, your Statement of Applicability, your treatment plan — flows from it. This guide explains how to run one in a structured, repeatable way that will stand up to a certification audit.

Why the risk assessment matters

ISO/IEC 27001 requires you to make security decisions based on risk, not guesswork. Rather than implementing every possible control, you identify what could go wrong, judge how serious it would be, and then treat the risks that matter most. Done well, this keeps your ISMS proportionate and defensible. Done poorly, it leaves gaps an auditor will spot straight away.

Step 1: Define your method first

Before assessing anything, document how you will assess. ISO/IEC 27001 requires a defined and repeatable risk assessment methodology so that two people following it would reach broadly the same result. Your method should set out:

• The scale you’ll use for likelihood and impact (for example, 1 to 5).
• How you’ll combine them into a risk level (often likelihood × impact).
• Your risk acceptance criteria — the threshold above which a risk must be treated.
• Whether you assess risks by asset or by scenario.

Agreeing this up front avoids inconsistent scoring later.

Step 2: Establish the context and scope

Your risk assessment only needs to cover what’s inside the scope of your ISMS. Confirm which business areas, systems, locations and types of information are included. Also note the interested parties — clients, regulators, staff — whose requirements shape what “acceptable risk” means for you.

Step 3: Identify your information assets

You can’t protect what you haven’t identified. Build a picture of the information and systems that matter, such as:

• Customer and personal data.
• Intellectual property and source code.
• Financial and HR records.
• Cloud services, servers, laptops and mobile devices.
• Key suppliers and the data you share with them.

Keep it practical. A concise asset register that everyone understands beats an exhaustive list nobody maintains.

Step 4: Identify the risks

For each asset or scenario, ask what could compromise its confidentiality, integrity or availability. Consider threats and vulnerabilities together, for example:

• A phishing email leading to stolen credentials.
• A misconfigured cloud bucket exposing customer data.
• A lost laptop without encryption.
• A supplier breach affecting data you’ve shared.
• Ransomware making systems unavailable.

Step 5: Analyse and evaluate

Using the method from Step 1, score each risk for likelihood and impact, then combine them to produce a risk level. Compare each result against your acceptance criteria to decide which risks need treatment. A simple matrix helps communicate the outcome to leadership.

Likelihood \ Impact	Low (1)	Medium (2)	High (3)
Likely (3)	3 – Medium	6 – High	9 – Critical
Possible (2)	2 – Low	4 – Medium	6 – High
Unlikely (1)	1 – Low	2 – Low	3 – Medium

Anything above your agreed threshold moves into treatment.

Step 6: Decide how to treat each risk

For every risk that exceeds your acceptance level, choose a treatment option:

• Modify — apply controls to reduce likelihood or impact (the most common choice).
• Avoid — stop the activity that creates the risk.
• Share — transfer some of the risk, for example through insurance or a supplier contract.
• Accept — knowingly tolerate the risk, with sign-off, where it’s within appetite.

Where you choose to modify a risk, you’ll select relevant controls from Annex A, plus any others you consider necessary.

Step 7: Build the risk treatment plan

The risk treatment plan records how each significant risk will be handled: the chosen controls, who is responsible, target dates and the expected residual risk once the treatment is in place. This becomes your practical to-do list for implementation and a key document auditors will review.

Step 8: Produce the Statement of Applicability

Your control decisions feed directly into the Statement of Applicability (SoA), which lists every Annex A control, whether it applies, the justification, and its implementation status. The risk assessment, treatment plan and SoA should tell one consistent story.

Step 9: Keep it alive

A risk assessment is not a one-off. ISO/IEC 27001 expects you to review it:

• At planned intervals (at least annually).
• When something significant changes — a new system, a new supplier, a merger, or a new type of data.
• After an incident that reveals a risk you’d missed.

Recording review dates and updates demonstrates that your ISMS is genuinely operating.

Common pitfalls to avoid

• Scoring inconsistently — solved by a clear, documented method.
• Listing controls before understanding risks — controls should answer a risk, not lead it.
• Over-detailing the asset register so it becomes unmaintainable.
• Forgetting residual risk — you need to show what’s left after treatment.
• Treating it as paperwork rather than a decision-making tool.

If any terms are unfamiliar, our glossary explains them in plain English.

How we can help

A well-run first risk assessment sets the tone for your whole certification journey. We provide practical support throughout — helping you design a proportionate method, facilitate the assessment, and produce a treatment plan and SoA that align — through a transparent, fixed-fee engagement with a clear delivery process. Our free ISO 27001 gap assessment tool is a useful first look at where your risks and gaps lie.

To discuss your assessment, explore our ISO 27001 service or get in touch.