The risk assessment is the engine of your ISMS (Information Security Management System). It is the very heart of ISO 27001. Everything else (your controls, your Statement of Applicability, your risk treatment plan) flows from it. Get it right, and the rest of the implementation becomes much clearer. Get it wrong, and you’ll find yourself implementing controls without really knowing why, and unable to explain it in an audit.
This guide walks you through the entire ISO 27001 risk assessment process, from choosing a methodology to producing the documentation auditors want to see.
What Is an ISO 27001 Risk Assessment?
A risk assessment under ISO 27001 is the process of identifying risks to your information assets, analysing their likelihood and the severity of the impact, and deciding what to do about them.
Every organisation has a different risk profile (for example, the level of risk associated with the data it handles) and risk appetite (how risk-averse it is).
A risk methodology is required by Clause 6.1.2 of the standard, which sets out specific requirements for conducting the risk assessment. The output of the risk assessment feeds directly into your risk treatment plan and your Statement of Applicability.
The standard gives you significant flexibility in how you conduct the assessment — you can choose your own methodology as long as it produces consistent, comparable, and repeatable results.
What Does ISO 27001 Actually Require?
The standard requires you to:
- Define and apply a risk assessment process that produces consistent, comparable, and repeatable results
- Identify the risks associated with the loss of confidentiality, integrity, and availability of information
- Analyse the risks (assess likelihood and impact)
- Evaluate the risks against your risk acceptance criteria to determine which require treatment
- Document the results of the risk assessment
Note what’s not required: a specific methodology, a specific scoring scale, or a specific format. ISO 27001 is outcome-focused, not prescriptive about method. So, if you already have something in your organisation, then use that. There’s no need to reinvent the wheel.
Choosing a Risk Assessment Methodology
The most common approach used by small and medium-sized organisations is a qualitative risk matrix using likelihood and impact scores. This is straightforward, easy to explain to auditors, and produces results that are easy to prioritise.
The basic approach:
Step 1: Identify your information assets (from your asset register)
Step 2: Identify the threats to each asset and the vulnerabilities that could be exploited
Step 3: Score each risk for likelihood (how likely is this to happen?) and impact (how bad would it be?)
Step 4: Calculate a risk score (likelihood × impact, or using a matrix)
Step 5: Compare each risk score against your risk acceptance criteria to decide what needs treating
A typical 3×3 or 5×5 scoring matrix works well. For example:
| Likelihood | Low Impact (1) | Medium Impact (2) | High Impact (3) |
|---|---|---|---|
| Low Likelihood (1) | 1 | 2 | 3 |
| Medium Likelihood (2) | 2 | 4 | 6 |
| High Likelihood (3) | 3 | 6 | 9 |
Risks scoring 6 or above require treatment. Risks scoring 3–5 require a decision. Risks scoring 1–2 may be accepted.
In a moment I’ll show you my preferred model, but the above is entirely ok.
Your risk acceptance criteria (what score is “acceptable”) should be agreed by senior management and documented before you conduct the assessment — not set retrospectively to make the numbers work.
Step-by-Step: How to Conduct the Assessment
The ISO 27001 Risk Assessment Process
A step-by-step overview aligned to ISO/IEC 27001:2022 Clause 6.1
Define the Risk Assessment Methodology
Establish your approach before you start: how you'll identify risks, how you'll score likelihood and impact, what your risk appetite is, and how you'll document decisions. This methodology must be consistent and repeatable.
Identify Information Assets
Start with your asset register. For each asset in scope, consider what information it holds, how it's used, and who relies on it. Assets are the starting point for every risk you'll identify.
Identify Threats & Vulnerabilities
For each asset, identify what could go wrong. Threats are external events (ransomware, phishing, hardware failure). Vulnerabilities are internal weaknesses (no MFA, unpatched systems, no offboarding process) that threats can exploit.
Assess Likelihood & Impact
Score each risk using your defined methodology — typically a 1–5 scale for both likelihood (how probable is this?) and impact (how damaging would it be?). Multiply the scores to get a risk rating. Apply scores consistently across all risks.
Evaluate & Prioritise Risks
Plot risks on your heat map and compare scores against your risk appetite. Risks above your acceptable threshold require treatment. Risks below it may be accepted. This step tells you where to focus your limited resources.
Select Risk Treatment Options
For each risk requiring treatment, decide: Mitigate (implement controls to reduce it), Transfer (insure or outsource), Avoid (stop the activity), or Accept (document the decision). Link each treatment decision to the relevant Annex A controls in your Statement of Applicability.
Document in the Risk Register & Review
Record every risk, its score, its owner, the treatment decision, and the target review date in your risk register. Review the register at least annually and after significant changes. Risk assessment is not a one-time exercise — it's a continuous process.
How to score each risk
I said earlier you don’t have to have a specific methodology, and you don’t, but a common approach is to define a scoring scale to assess and prioritise risk.
For each threat-vulnerability combination, score:
Likelihood
How likely is this to occur, given your current controls? Here’s the scale I use;
| Likelihood | Description | Score |
|---|---|---|
| Remote | The risk is improbable to occur under normal circumstances. There may be no known instances or only a few rare cases in similar organisations or environments. This category is typically reserved for risks considered negligible or theoretical. | 1 |
| Unlikely | The risk has a low chance of occurring.It might happen in exceptional circumstances but is not expected to occur regularly. This level is for recognised risks uncommon in your industry or operational environment. | 2 |
| Possible | The risk has a moderate likelihood of occurring. There is an equal chance of the risk occurring or not occurring. It’s a realistic possibility in your current environment and should be given a fair amount of attention. | 3 |
| Probable | The risk is more likely to occur than not. There have been instances of this risk materialising in similar contexts, or there are factors in your environment that increase its likelihood. It requires proactive management and monitoring. | 4 |
| Highly Probable | The risk is almost certain to occur. Strong evidence or historical data suggests this risk is frequent in your setting. This level indicates a high-priority risk that demands immediate and effective mitigation measures. | 5 |
Impact
How bad would the consequences be if this risk materialised?
| Impact | Description | Score |
|---|---|---|
| Insignificant | The impact is negligible, with no notable consequences on operations, reputation, or finances. It would not cause any interruption to normal business activities or require significant effort to address. | 1 |
| Minor | The impact causes a minor inconvenience that can be easily managed or resolved through routine procedures. It may result in a slight delay or minor costs, but it does not significantly affect business operations or objectives. | 2 |
| Moderate | The impact is noticeable and may cause some disruption but can be managed or worked around without significant difficulty. This level might involve moderate financial costs, a temporary reduction in productivity, or some strain on resources. It requires management attention but is within the organisation’s capacity to handle effectively. | 3 |
| Major | The impact causes significant disruption to services or operations. It may result in substantial financial loss, severe damage to reputation, or considerable resource allocation to address. Recovery from this level of impact requires significant effort and may affect the organisation’s strategic objectives or long-term plans. | 4 |
| Catastrophic | The impact is so severe that it threatens the existence and continued operation of the organisation. It could lead to long-term or permanent damage to the organisation’s reputation, financial stability, or market position. This impact may involve legal ramifications, significant financial losses, and critical damage to organisational assets or stakeholder relationships. | 5 |
Calculate the risk score (likelihood × impact) and note whether it falls above or below your acceptance threshold.
ISO 27001 Risk Heat Map
Likelihood × Impact matrix — used to score and prioritise information security risks
Example risks plotted ●
The Risk Register
The risk register is the primary output of the risk assessment. At minimum, each row in your risk register should capture:
- Risk ID (a reference number)
- Asset affected
- Threat and vulnerability
- Likelihood score
- Impact score
- Risk score
- Risk owner (who is responsible for managing this risk)
- Risk treatment decision (see below)
- Controls applied (references to Annex A controls or other measures)
- Residual risk score (after controls)
- Review date
A well-structured risk register in a spreadsheet is perfectly acceptable for ISO 27001 purposes. You don’t need specialist software, though there are tools available if you prefer.
Risk Treatment Options
For each risk above your acceptance threshold, you have four options:
ISO 27001 Risk Treatment Options
Once a risk is identified and scored, you must decide how to respond. There are four options.
- The risk is above your appetite threshold
- Controls exist that are practical to implement
- The cost of controls is proportionate to the risk
- The risk cannot be fully mitigated internally
- Insurance provides cost-effective coverage
- A specialist third party manages the activity better
- The risk is too high to accept or mitigate
- The activity is not critical to the business
- No practical controls exist to reduce the risk
- The risk score falls within your risk appetite
- Treatment costs outweigh potential impact
- A conscious, documented decision is made
Your treatment decisions feed into your risk treatment plan and your Statement of Applicability.
How Often Should You Review the Risk Assessment?
ISO 27001 requires the risk assessment to be reviewed at planned intervals and when significant changes occur. In practice:
- Annual review as a minimum — aligned with your management review cycle
- Ad-hoc reviews when significant things change: new systems, new suppliers, new data types, major incidents, or changes to the regulatory environment
Each review should be documented and approved by the appropriate person. Don’t just update the scores silently — record that the review happened, who conducted it, and what changed.
Common Mistakes
Conducting the assessment alone, without involving asset owners. Risk owners need to be engaged — they understand the business context of their assets better than the ISO 27001 project lead.
Setting acceptance criteria after scoring. This is circular. Define what’s “acceptable” before you start, not after you see the results.
Treating every risk as unique. Many risks are similar across different assets. Group them where appropriate to make the register manageable.
Never reviewing it. A risk assessment from two years ago that’s never been touched is a significant audit finding. Build reviews into your annual calendar.
Focusing only on technical risks. ISO 27001 is about information security, not just IT security. Physical risks, people risks, and process risks belong in the assessment too.
Getting Started
The ISO 27001 toolkit includes a pre-built risk assessment template with a pre-populated methodology document, risk register, and risk treatment plan — all linked together and ready to adapt. It’s the fastest way to produce a risk assessment that passes audit without starting from scratch.
For the full picture on what to do with your risk assessment outputs, read the guide to creating a risk treatment plan and the Statement of Applicability.
ISO 27001 Full Document Toolkit
Every document your auditor
expects to see.
130 Word & Excel templates, ready to edit. Policies, risk register, Statement of Applicability, audit pack, staff communications — all updated for ISO 27001:2022.
130 templates
Instant download
Written by practising consultant
ISO 27001:2022
FAQs
What’s the difference between a threat and a vulnerability in ISO 27001?
A threat is something that could cause harm — ransomware, a disgruntled employee, a fire. A vulnerability is a weakness that a threat can exploit — unpatched software, no offboarding process, an unsecured server room. The risk exists where a threat meets a vulnerability. This distinction matters because your controls should target the vulnerability, not the threat — you can’t stop ransomware from existing, but you can close the gaps that let it in.
How many risks should an ISO 27001 risk register contain?
There’s no required number, but a register with fewer than 15–20 risks usually signals that the assessment hasn’t been thorough enough, while one with 300+ risks is often unmanageable and suggests the organisation has gone too granular. For most small and medium-sized businesses, a well-considered register of 30–60 risks covers the realistic threat landscape without becoming a document nobody reads. Quality and consistency matter more than volume.
Do we need to reassess every risk from scratch each year?
No — the annual review is about confirming whether existing risks have changed and identifying any new ones, not rebuilding the register from zero. Walk through each risk and ask: has the likelihood or impact changed? Have the controls changed? Has the business context changed? Update what needs updating, document that the review happened, and get it signed off. A clean, dated review record is what auditors want to see.
Can we use a 3×3 risk matrix instead of 5×5?
Yes. None of the above is mandated. ISO 27001 doesn’t specify the scale — it requires a consistent, comparable, and repeatable methodology. A 3×3 matrix (Low/Medium/High for both likelihood and impact) is simpler to apply and often more appropriate for smaller organisations. The risk is that it gives you less differentiation between risks at the middle scores, making prioritisation harder. A 5×5 matrix provides more granularity but requires more careful calibration of what each score means. Pick the scale that your team can apply consistently, and define each level clearly before you start.
Does the risk assessment need to be done by a qualified person?
No formal qualification is required — ISO 27001 doesn’t specify one. What the standard does require is that the process is documented, consistent, and produces repeatable results. In practice, the assessment is usually led by the person driving the ISO 27001 project, with input from asset owners across the business. If you’re conducting it for the first time without prior experience, using a structured template with pre-defined criteria and a clear methodology will help ensure the output holds up under auditor scrutiny.
