If you are working towards ISO 27001 certification, the risk assessment is not just one item on a long to-do list — it is the backbone of the entire standard. Everything from the controls you implement to the evidence you present to your auditor flows directly from a well-executed risk assessment. Get it right and the rest of the implementation falls into place logically. Get it wrong and you will find yourself scrambling to justify decisions that were never properly documented in the first place.
Why Risk Assessment Is Central to ISO 27001
Clause 6.1 of ISO 27001:2022 — Actions to address risks and opportunities — makes it explicit: organisations must establish and maintain an information security risk assessment process. This is not optional, and it is not a one-off exercise. The standard requires you to define your own risk criteria, identify risks systematically, analyse and evaluate them, and document the whole process in a way that can be scrutinised and repeated.
The reason risk assessment sits at the heart of ISO 27001 is that the standard is not prescriptive about which controls you must implement. Instead, it asks you to identify your specific risks and then choose controls proportionate to those risks. That means two organisations in the same sector can legitimately have very different control sets — as long as each can demonstrate their choices are grounded in a documented risk assessment.
What Assets Should You Include?
Before you can assess risk, you need to know what you are protecting. ISO 27001 requires you to identify information assets — anything that holds, processes, or transmits information that has value to your organisation. This includes:
- Information assets: databases, documentation, intellectual property, customer records, contracts, financial data
- Systems and infrastructure: servers, laptops, cloud services, network devices, applications, backup systems
- People: employees, contractors, third-party suppliers with access to your data
- Processes: business procedures, IT operations, incident response workflows
Maintaining an asset inventory (sometimes called an asset register) is a prerequisite for a meaningful risk assessment. Without knowing what you have, you cannot systematically identify what could go wrong with it.
Identifying Threats and Vulnerabilities
For each asset, you work through potential threats — events or actions that could cause harm — and vulnerabilities — weaknesses that could be exploited by those threats. Common threats include ransomware, phishing attacks, accidental data deletion, hardware failure, insider misuse, and physical theft. Vulnerabilities might include unpatched software, weak password policies, lack of encryption, or insufficient access controls.
A practical approach is to work through each asset with a small team — typically involving IT, compliance, and relevant business owners — and ask: what could go wrong here, and why would it go wrong? Use threat libraries or frameworks such as ISO 27005 or NCSC guidance to prompt your thinking rather than starting from a blank page.
Assessing Likelihood and Impact
Once you have identified your threats and vulnerabilities, you assess each risk using two dimensions: likelihood (how probable is it that this threat will be realised?) and impact (what would the consequences be if it were?). Most organisations use a simple scoring scale — commonly 1 to 3 or 1 to 5 — for each dimension.
You will need to define what each score means in plain language so that the process is repeatable and consistent across different reviewers. For example, a likelihood score of 3 might mean “reasonably likely to occur at least once a year given current controls”, while an impact score of 5 might mean “severe financial loss, regulatory sanction, or significant reputational damage”.
Calculating Risk Scores
Your risk score is typically calculated by multiplying likelihood by impact. A risk with a likelihood of 4 and an impact of 5 gives a raw risk score of 20, which would sit in the high-risk band on most scales. This score represents the inherent risk — the level of risk before any controls are applied.
Many risk assessments also calculate a residual risk score — the level of risk that remains after existing or planned controls are taken into account. Auditors will pay close attention to whether your residual risk scores are realistic and whether your rationale for them is documented.
Risk Treatment Options
After scoring your risks, you must decide what to do about each one. ISO 27001 recognises four risk treatment options:
- Mitigate: Implement controls to reduce the likelihood or impact of the risk. This is the most common option and links directly to the controls in Annex A.
- Accept: Formally acknowledge that the risk exists and that you are willing to tolerate it, usually because the cost of mitigation outweighs the potential impact. This must be a documented, conscious decision — not simply inaction.
- Transfer: Shift the risk to a third party, typically through cyber insurance or contractual obligations placed on suppliers.
- Avoid: Stop the activity that gives rise to the risk entirely. For example, ceasing to store a particular category of sensitive data if the risk cannot be adequately managed.
Your chosen treatment for each risk must be recorded, along with the rationale and the name of the person who owns the risk and is accountable for the treatment decision.
Creating and Maintaining a Risk Register
The risk register is the living document that captures all of the above: assets, threats, vulnerabilities, likelihood and impact scores, risk owners, treatment decisions, and the status of mitigating controls. It does not need to be a sophisticated tool — many organisations start with a well-structured spreadsheet — but it does need to be accurate, consistently maintained, and formally reviewed at planned intervals.
ISO 27001 requires the risk register to be reviewed whenever significant changes occur — a new cloud platform, a merger, a major system upgrade — and at least annually as part of your management review process. Auditors will ask to see evidence of these reviews, not just the current version of the register.
The Statement of Applicability and Its Link to Annex A
The Statement of Applicability (SoA) is one of the most important documents in your ISO 27001 implementation. It lists all 93 controls from Annex A of ISO 27001:2022 and records, for each control, whether it is applicable to your organisation, whether it has been implemented, and the justification for including or excluding it.
The SoA must be directly traceable back to your risk assessment. If you have chosen to implement Control 8.12 (Data Leakage Prevention), your risk register should show at least one risk that this control addresses. Conversely, if you have excluded a control, you must be able to explain why — typically because no identified risk necessitates it, or because a risk has been accepted or transferred instead.
Auditors treat the SoA as a key audit artefact. They will compare it against your risk register, your implemented controls, and your operational evidence. Any gap between what the SoA says is implemented and what they find in practice is a finding — often a nonconformity.
What Auditors Actually Check
When your certification auditor reviews your risk assessment, they are looking for several things beyond a tidy spreadsheet:
- A defined methodology: You must be able to explain how you conducted the risk assessment, not just show the output. Your risk criteria, scoring scales, and process must be documented — often in a Risk Assessment Procedure or similar policy document.
- Evidence of review: Version history, meeting minutes, or dated sign-off records showing that the risk register has been reviewed at appropriate intervals.
- Rationale for accepted risks: Any risk you have formally accepted must have a documented justification and a named risk owner who has approved that decision. Auditors are rightly sceptical of risk registers where everything with a high score has been “accepted” without explanation.
- Traceability from risk to control: The chain from identified risk → treatment decision → Annex A control → implemented measure → operational evidence must be followable. If an auditor cannot trace a control back to a risk, they will question whether the control is genuinely risk-driven or simply copied in for appearance.
- Competence of the assessors: Auditors may ask who performed the risk assessment and what their qualifications or experience are. This does not require a formal certification, but you should be prepared to demonstrate that the process was conducted by people with appropriate knowledge of your assets and threat landscape.
Keeping the Risk Register Live
One of the most common weaknesses seen in ISO 27001 audits — particularly at surveillance audits in years two and three — is a risk register that has not materially changed since the initial certification. The threat landscape evolves, your organisation changes, and new vulnerabilities emerge. Your risk register must reflect this.
Build risk review into your existing governance calendar. Tie it to quarterly IT reviews, change management processes, and your annual management review. When a new supplier is onboarded, a new system is deployed, or a security incident occurs, ask explicitly whether the risk register needs updating. This discipline is what separates organisations that are genuinely secure from those that are simply certified.
Summary
ISO 27001 risk assessment is not a box-ticking exercise — it is the process by which you justify every security decision you make. Start by inventorying your assets, identify realistic threats and vulnerabilities, score likelihood and impact consistently, and document your treatment decisions with clear rationale. Build a risk register that is actively maintained rather than filed away, and ensure your Statement of Applicability is always traceable back to the risks it addresses. When an auditor arrives, they are not just checking that you have a risk register — they are checking that it drives your security programme. Done well, a rigorous risk assessment does not just satisfy the standard; it makes your organisation measurably more secure.
