ISO 27001 risk assessment and treatment
A practical UK guide for 2026
This guide explains how to conduct ISO 27001 risk assessments, treat risks effectively, avoid common mistakes, and prepare confidently for certification audits.
Key takeaways
ISO 27001 risk assessment forms the foundation of the ISMS, identifying security risks and guiding control selection to protect organisational information.
A clear, consistent risk methodology is essential. Auditors expect risks, controls, and the Statement of Applicability to be logically connected.
Risk assessment is ongoing. Organisations must review risks regularly, update treatment plans, and ensure controls reflect real operational threats.
Why risk assessment sits at the core of ISO 27001
Risk assessment is the foundation of an Information Security Management System (ISMS) under the International Organisation for Standardisation standard ISO/IEC 27001. The standard requires organisations to identify, analyse, and treat risks that could affect their information assets.
Two key areas of the standard establish this requirement. Clause 6.1.2 requires organisations to define a structured method for assessing information security risks, while Clause 8 requires those risk processes to be implemented and maintained as part of the ISMS.
The goal is simple: protect the confidentiality, integrity, and availability (CIA) of information. A strong risk assessment helps organisations understand what could go wrong, how likely it is, and what controls are needed to reduce the risk.
In practice, many ISO 27001 projects struggle at this stage. A common issue auditors see is inconsistent or poorly defined risk methodologies, where risks are scored differently across teams or not linked clearly to security controls.
In this guide, we explain how ISO 27001 risk assessment and risk treatment work in practice and what organisations should prepare before audit.
Related read - ISO 27001 preparation: A practical guide to audit readiness
What ISO 27001:2022 actually requires
The risk assessment requirements in ISO/IEC 27001 are deliberately flexible. The standard does not prescribe a specific methodology, but it clearly defines what the process must achieve.
This flexibility allows organisations to choose a methodology that fits their size and environment. However, the method must be documented and consistently applied.
Auditor insight: Many audit findings arise not from missing risks but from unclear or inconsistent methodologies.
The 5 mandatory elements (Clause 6.1.2)
ISO 27001 requires the risk assessment procedure to include 5 core elements.
Risk identification - Identify risks linked to the loss of confidentiality, integrity, or availability of information.
Defined risk owners - Assign responsibility for evaluating and managing each risk.
Likelihood and impact criteria - Define scales used to measure how likely a risk is and how severe its consequences could be.
Risk calculation method - Establish how likelihood and impact combine to produce a risk rating.
Risk acceptance criteria - Define which risks are acceptable and which require treatment.
ISO 27001 does not mandate an asset-based methodology. What matters is that the approach produces consistent, traceable results.
Step 1 – Define your risk assessment methodology
Before identifying risks, an organisation must define how risks will be assessed. This step is often overlooked, but it is one of the first things an auditor will examine.
A risk assessment methodology should explain:
How risks will be identified
How likelihood and impact will be scored
How risk levels will be calculated
How decisions about risk treatment will be made
Without a defined methodology, the results of the assessment become difficult to justify or compare.
Qualitative vs quantitative risk assessment
Most UK or European organisations adopt a qualitative risk assessment approach.
This means risks are evaluated using descriptive scales such as:
Low / Medium / High
Or numerical scales such as 1-5
The advantage of qualitative approaches is practicality. SMEs rarely have sufficient historical data to calculate risks in purely financial or statistical terms.
A quantitative approach, which attempts to assign financial values or probability percentages, is more common in highly regulated sectors such as finance.
Risk scales
A simple risk scoring matrix is typically used.
For example:
Impact may be measured using a similar scale, considering factors such as:
Financial loss
Legal or regulatory consequences
Operational disruption
Reputational damage
The combination of likelihood and impact produces the overall risk rating.
Risk appetite and acceptance thresholds
Organisations must also define when a risk becomes unacceptable.
For example:
Scores 1-5 may be considered acceptable
Scores 6-10 may require monitoring
Scores above 10 may require treatment
These thresholds represent the organisation’s risk appetite. They guide decisions about when controls must be implemented.
Ensuring repeatable and comparable results
The most important characteristic of a risk methodology is consistency.
Different teams or departments must be able to apply the methodology and arrive at comparable results. If two similar risks receive very different scores simply because they were assessed by different people, the risk assessment loses credibility.
Step 2 – Identify information assets
Once the methodology is defined, the next step is identifying information assets. An asset is anything that stores, processes, or enables access to important organisational information.
Typical asset categories include:
Customer data - Personal data, financial information, or contractual records.
Intellectual property - Source code, designs, research data, proprietary processes.
IT systems and infrastructure - Servers, networks, databases, internal applications.
SaaS platforms - Cloud services such as CRM, project management, or development platforms.
People - Key staff with privileged system access or operational knowledge.
Suppliers and third parties - Vendors who process, store, or access organisational data.
Identifying assets provides a map of where important information is located, helping organisations understand where security risks may arise.
Asset-based vs scenario-based approaches (Which to choose)
ISO 27001 allows organisations to choose how risks are structured. Two approaches are commonly used.
Asset-Threat-Vulnerability approach
This traditional method evaluates:
An asset
Threats affecting that asset
Vulnerabilities that enable those threats
It provides strong coverage but can produce large and difficult-to-maintain risk registers.
Scenario-based approach
This method evaluates realistic events such as:
Ransomware attacks
Accidental data disclosure
Cloud provider outages
Insider misuse
For SMEs, this often produces a shorter and more practical risk register.
Why the choice matters
For SMEs in particular, the methodology must balance two competing needs:
It must be rigorous enough to satisfy an auditor
It must be practical enough to maintain with limited resources
In practice, many organisations adopt a hybrid approach, using asset categories to guide scenario generation while assessing risks at the scenario level.
Step 3 – Identify threats and vulnerabilities
After assets or scenarios are defined, the next step is identifying credible threats and vulnerabilities.
Threats are events that could cause harm. Vulnerabilities are weaknesses that allow those threats to occur.
Typical examples include:
Phishing attacks targeting employees
Software vulnerabilities in unpatched systems
Misconfigured cloud storage
Insider misuse of privileged access
A useful technique is “reverse engineering” of Annex A controls in ISO/IEC 27001.
For example:
Access control policies address unauthorised access
Backup controls address data loss
Supplier controls address third-party risks
The goal is to identify realistic risks, not to create an exhaustive theoretical list.
In practice:
SMEs often maintain 20-50 meaningful risks
Larger organisations may track 100 or more risks
Auditor warning: Very large risk registers often indicate template copying rather than genuine analysis.
Step 4 – Analyse and evaluate risks
Once risks are identified, they must be analysed and prioritised.
Simple risk assessment (most common)
Most organisations use a likelihood × impact model.
Each risk receives:
A likelihood score
An impact score
These values are combined using a risk matrix. For example, a 5×5 matrix might produce scores ranging from 1 to 25.
Higher scores represent more serious risks and may require treatment. This approach is widely used because it is easy to understand and apply consistently.
Detailed risk assessment (when needed)
In some situations, organisations adopt a more detailed calculation.
This may incorporate factors such as:
Asset value
Threat capability
Vulnerability severity
Such models are sometimes used in complex environments or highly regulated sectors. For most SMEs implementing ISO 27001, a well-defined qualitative approach is sufficient.
Residual risk
After controls are implemented, the organisation reassesses the remaining risk level, known as residual risk.
Key questions include:
Does the remaining risk fall within the organisation’s risk appetite?
Who has the authority to accept that risk?
Typically, senior management or designated risk owners approve residual risk decisions. Transparent documentation is important because auditors will often review how and why risks were accepted rather than treated.
The diagram below illustrates how these four steps typically fit together in a practical ISO 27001 risk assessment process.
Risk treatment options (AART framework)
Once risks have been analysed and prioritised, organisations must decide how those risks will be treated. ISO risk management commonly uses the AART framework, which outlines 4 possible responses.
Avoid - Stop the activity that creates the risk. For example, discontinuing a system or process that exposes sensitive data.
Reduce (modify) - Implement controls to lower the likelihood or impact of the risk. This is the most common approach in ISO 27001.
Share (transfer) - Transfer part of the risk to another party, such as through insurance, outsourcing, or contractual agreements.
Accept (retain) - Formally accept the risk when it falls within the organisation’s defined risk appetite.
These options align with principles described in ISO 31000, although ISO 27001 does not require organisations to follow that framework explicitly. The key requirement is that risk treatment decisions are documented, justified, and approved by appropriate management.
Selecting controls from Annex A (2022 – 93 controls)
When organisations choose to reduce risk, they typically implement security controls listed in Annex A of ISO/IEC 27001.
The 2022 version groups 93 controls into 4 categories:
Organisational controls - Policies, governance, and supplier security management.
People controls - Training, responsibilities, and disciplinary processes.
Physical controls - Access to facilities, equipment protection, and environmental safeguards.
Technological controls - System security, encryption, monitoring, and access management.
Each control selected should address a specific identified risk. These decisions are then recorded in the Statement of Applicability (SoA).
Statement of Applicability (SoA) – What auditors expect
The Statement of Applicability (SoA) is one of the most important documents in an ISO 27001 audit. It acts as the bridge between the risk assessment and the security controls implemented within the ISMS.
Under ISO/IEC 27001, organisations must clearly document:
Which Annex A controls are implemented
Which controls are excluded
The justification for each inclusion or exclusion
The status of implementation
Auditors review the SoA to confirm that risk treatment decisions are logical and traceable. Each control should connect to a specific risk identified in the risk assessment.
Common audit findings related to SoA errors
Auditors frequently encounter issues where the SoA does not properly reflect the organisation’s risk treatment process. Common problems include:
Template-based SoAs that include every control without justification
Controls marked as “not applicable” without explanation
Missing links between identified risks and selected controls
Controls listed as implemented but not actually operating in practice
A well-prepared SoA should clearly show how the organisation moved from risk identification to control selection, creating a transparent and defensible security framework.
Risk Treatment Plan (RTP) – Turning strategy into action
After risks have been evaluated and treatment options selected, organisations must translate those decisions into practical actions. This is the purpose of the Risk Treatment Plan (RTP).
It is important to distinguish between the risk treatment process and the Risk Treatment Plan document. The process refers to the decision about how a risk will be handled (avoid, reduce, share, or accept). The RTP document records how the chosen treatment will actually be implemented.
A typical RTP should include:
The control or action to be implemented
The responsible owner
Any resources required
A target completion date
The method used to monitor progress
Under ISO/IEC 27001, auditors expect the RTP to show real implementation progress, not simply planned controls.
Risk assessment vs gap analysis vs internal audit
These 3 activities are often confused during ISO 27001 projects, but they serve different purposes at different stages of implementation.
Understanding the distinction helps organisations prepare for audit more effectively.
Simply put,
Risk assessment is future-focused. It evaluates potential threats to information and helps determine which security controls are needed under ISO/IEC 27001.
Gap analysis examines the current state of the organisation and compares it to ISO 27001 requirements.
Internal audit occurs after the ISMS is implemented. It verifies that processes are operating effectively and that the organisation complies with both its own ISMS and ISO 27001 requirements.
Risk assessment and business continuity
Risks identified in an ISMS often overlap with scenarios considered in business continuity planning, such as system outages, ransomware attacks, or supplier disruptions.
However, the two processes serve different purposes.
Risk assessment under ISO/IEC 27001 identifies threats to the confidentiality, integrity, and availability of information.
A Business Impact Analysis (BIA) under ISO 22301 focuses on understanding the operational impact of disruptions, including recovery priorities, downtime tolerance, and resource dependencies.
The processes should not be combined into a single exercise.
In practice, the most effective sequence is:
Conduct the ISO 27001 risk assessment to identify security risks.
Perform the Business Impact Analysis to understand operational impact.
Use both outputs to inform business continuity and disaster recovery planning.
6 common mistakes UK or European SMEs make
From an audit perspective, most ISO 27001 risk assessment issues are not caused by missing documents. They usually arise because the risk process is poorly connected or inconsistently applied.
Overcomplicating the methodology - Some SMEs adopt overly complex risk models designed for large enterprises. The result is a methodology that looks impressive on paper but is too difficult for a small team to maintain.
No clear link between the risk assessment and the SoA - The risk register and Statement of Applicability often exist as separate documents with no visible connection. Auditors expect controls selected in the SoA to be traceable to specific risks.
Treating risk assessment as a one-off exercise - Risk assessments are sometimes completed during implementation and then never updated. Under ISO/IEC 27001, they must be reviewed regularly and when major changes occur.
Methodology defined but not applied - Many organisations document scoring criteria but then apply them inconsistently when populating the risk register.
Ignoring residual risk decisions - Risks that remain after controls are implemented are sometimes left undocumented. Residual risks must be reviewed and formally accepted by management.
Using tools that dictate the methodology - The methodology should be defined by the organisation first, and any software used should support that approach rather than dictate it.
How often should you review risk assessments?
Risk assessments should be reviewed at least annually under ISO/IEC 27001. Additional reviews are recommended after major system or organisational changes, security incidents, or during management reviews.
Regular updates ensure risks remain accurate and support the ISMS requirement for continual improvement.
How Tempo Audits supports ISO 27001 risk assessments
Tempo Audits approaches ISO 27001 risk assessments from an independent audit perspective, rather than a consultancy-led implementation model.
This distinction is important because certification auditors must remain separate from the organisations and systems they assess.
Our role is to evaluate whether your ISMS and risk assessment meet the requirements of ISO/IEC 27001, not to design or implement them.
Our support includes:
Pre-certification reviews and gap analysis to identify areas that may prevent successful certification.
Internal audit services to test whether the risk assessment and controls are operating as intended (but only where we do not act as the external auditor)
Stage 1 audit, where risk methodology, risk registers, and documentation are reviewed in detail.
Clear feedback on gaps in methodology, coverage, or control alignment.
Between Stage 1 and Stage 2, organisations address any findings with their implementation partners. At Stage 2, Tempo Audits assesses whether the ISMS, including the risk assessment, is implemented, operating effectively, and ready for certification.
Ready to achieve ISO 27001 certification?
If your ISMS is implemented and you’re preparing for audit, the next step is choosing a trusted certification body. Tempo Audits conducts UKAS-accredited ISO 27001 certification audits, guiding organisations through Stage 1 readiness review and the Stage 2 certification audit.
Request a quote today to start your ISO 27001 certification journey.
FAQs
-
Yes. ISO 27001 does not require complex models. A basic assessment can pass if the methodology is defined, applied consistently, and risks clearly link to control decisions.
-
No. ISO 27001 does not require specialist software. Many organisations manage risk assessments using spreadsheets or simple tools, provided the methodology, scoring, and decisions are clearly documented.
-
Risk acceptance decisions should be approved by senior management or designated risk owners. This ensures accountability and confirms the organisation formally accepts remaining risk after controls are implemented.