ISO 27001

ISO 27001 Risk Assessment and Treatment Explained

By Samaksh·2026-10-05·11 min read

Short answer: The ISO 27001 risk assessment and treatment process, required by Clause 6.1, involves establishing a risk assessment methodology, identifying information security risks against that methodology, analysing and evaluating each risk against defined criteria, and then treating each risk through a documented plan that selects controls from Annex A (among other options). The outcome feeds the Statement of Applicability and drives all control implementation decisions.

TL;DR: Risk assessment is not a checkbox — it is the analytical engine that drives every control decision in your ISMS. If your risk register does not reflect your organisation's actual threat landscape, every control selection built on top of it is on a shaky foundation. The standard gives you methodology freedom; what it requires is rigour, documentation, and a direct line from risk to treatment.

Key Takeaways - ISO 27001:2022 does not prescribe a risk assessment method — you define your own, then apply it consistently. - Risks must be identified, analysed (likelihood × impact), evaluated against acceptance criteria, and treated — in that order. - The four treatment options are: modify (apply controls), accept, avoid, or transfer (e.g., to a third party via contract or insurance). - The Statement of Applicability (SoA) documents which Annex A controls apply, why, and their implementation status — it is the direct output of treatment decisions. - The risk assessment must be repeated at planned intervals and whenever significant changes occur — it is not a one-time activity.

Why risk assessment is the core of ISO 27001

Every information security management system must start with an honest answer to the question: what are the information security risks we face? Without that, control selection is arbitrary — organisations implement controls because they sound sensible, not because they address identified threats to specific assets.

Clause 6.1 of ISO 27001:2022 formalises this requirement. It mandates a documented risk assessment process that produces consistent, comparable results. The risk treatment plan and Statement of Applicability are the direct outputs. Every control your organisation implements should trace back to a risk in the register.

The organisations that get the most value from the standard, beyond the certificate itself, are those that treat risk assessment as an ongoing management discipline rather than a compliance formality. Established risk-management guidance such as the NIST SP 800-30 Guide for Conducting Risk Assessments reinforces the same principle: credible control decisions depend on a repeatable, evidence-based assessment of threats to specific assets.

Setting up the risk assessment methodology

Before you assess any specific risks, Clause 6.1.2 requires you to document the criteria for performing information security risk assessments. These criteria cover:

Risk acceptance criteria

Define the threshold above which a risk must be treated. This is typically expressed as a risk level (e.g., any risk scoring above 12 on a 25-point scale must be treated). The threshold should reflect your organisation's risk appetite.

Risk assessment criteria

Define how you will assess risks. Two primary approaches exist:

Asset-based approach: identify information assets → identify threats and vulnerabilities for each → assess likelihood and impact for each threat–vulnerability pair → calculate risk level.

Event-based (scenario) approach: identify scenarios in which information security objectives could be compromised → assess the likelihood of each scenario → assess the consequence → calculate risk level.

Both are acceptable under ISO 27001. The asset-based approach is more granular; the scenario-based approach is often more practical for complex or cloud-heavy environments. The critical requirement is that you apply whichever method you choose consistently across all assessments.

Likelihood and impact scales

Define your scales before you start assessing risks. A common approach is a 1–5 scale for both:

Score	Likelihood	Impact
1	Rare — could happen but very unlikely	Negligible — no material effect
2	Unlikely — might happen in some circumstances	Minor — limited operational impact
3	Possible — could happen at some point	Moderate — significant operational disruption
4	Likely — will probably happen at some point	Major — significant financial or reputational damage
5	Almost certain — expected to happen regularly	Critical — existential threat to operations

Risk level = likelihood × impact. A 5×5 grid produces levels from 1 to 25. Define acceptance criteria (e.g., levels 1–8 acceptable, 9–15 moderate, 16+ high and must be treated).

Risk identification

With your methodology defined, identify information security risks. Each risk is a combination of a threat exploiting a vulnerability to cause harm to an information asset or process.

Information assets and processes

For an asset-based approach, your starting point is the information asset register (Annex A control A.5.9 requires assets associated with information and processing facilities to be identified). Assets include:

Information (databases, files, contracts, personal data, intellectual property)
Software (applications, operating systems, development tools)
Hardware (servers, workstations, network equipment, mobile devices)
Services (cloud services, utilities, communications)
People (skills, knowledge, roles)
Facilities (offices, data centres)

Threats and vulnerabilities

For each asset, identify relevant threats (what could go wrong) and vulnerabilities (weaknesses that the threat could exploit). Common threats include:

Malware and ransomware
Phishing and social engineering
Insider threat (accidental or deliberate)
Unauthorised access (external or internal)
System failure and data loss
Physical theft or damage
Third-party breach

Common vulnerabilities include: unpatched systems, weak access controls, inadequate staff training, absent backup procedures, poor physical security, unmanaged third-party access.

Risk analysis and evaluation

Calculating risk levels

For each threat–vulnerability–asset combination, assign likelihood and impact scores and calculate the risk level using your defined methodology. Document the rationale — an auditor will want to understand why you scored a particular risk as you did.

Evaluating against acceptance criteria

Compare each risk level against your risk acceptance criteria. Risks above the acceptance threshold must enter the treatment process. Risks at or below the threshold may be accepted — but acceptance must be documented and authorised by risk owners.

Figure 1. Example 5×5 risk matrix for ISO 27001. Risk level = likelihood × impact. Risks scoring 16+ (red zone) must be treated; 9–15 (amber) require a treatment decision; 1–8 (green) may be accepted. Define your own thresholds in your methodology document.

Risk treatment

For each risk above the acceptance threshold, Clause 6.1.3 requires you to select one or more treatment options:

Treatment option 1 — Modify (apply controls)

The most common treatment: implement controls from Annex A (or elsewhere) that reduce the likelihood of the threat occurring, reduce the impact if it does, or both. Controls must be selected based on their effectiveness against the identified risk — not based on convenience or industry practice alone.

Treatment option 2 — Accept

Acknowledge that the risk exists and decide not to take additional action. Acceptance is appropriate when the cost of treatment exceeds the expected loss, or when the risk is below your acceptance threshold. Accepted risks must be documented and approved by the risk owner.

Treatment option 3 — Avoid

Eliminate the activity that creates the risk. If a particular business process creates an unacceptable risk and the process is not essential, the risk can be avoided by discontinuing the process. In practice, avoidance is limited — most risks arise from necessary business activities.

Treatment option 4 — Transfer

Shift the risk to a third party — through insurance, contracts that impose liability on suppliers, or outsourcing. Transfer does not eliminate the risk; it creates a mechanism for sharing or compensating for the consequence. Note that under GDPR, data controllers cannot transfer their compliance obligations to a processor — transfer in a legal sense is limited.

The risk treatment plan

The risk treatment plan (Clause 6.1.3) documents the decisions made for each risk:

Column	Content
Risk ID	Unique reference from the risk register
Risk description	Asset/threat/vulnerability combination
Current risk level	Score before treatment
Treatment option	Modify / accept / avoid / transfer
Controls selected	Specific Annex A controls (or other controls)
Risk owner	Person responsible for implementing treatment
Target date	When treatment will be complete
Residual risk level	Expected score after treatment
Approval	Sign-off by risk owner and ISMS owner

The Statement of Applicability

The SoA is produced from the treatment plan. For each of the 93 Annex A controls, it states whether the control applies, why (linked to specific risks, legal requirements, or business requirements), and the implementation status.

Exclusions must be justified. A control excluded without justification is a potential nonconformity if an auditor believes it should apply to your risk profile.

For organisations that process personal data, the ISO 27001 risk assessment process directly supports GDPR Article 32 compliance (technical and organisational security measures). The same risk register and treatment plan that drives your ISMS also provides evidence that you have assessed the risks to personal data and implemented appropriate controls. EU guidance on security of personal data processing takes the same risk-based approach to selecting measures (ENISA).

The DPIA process required for high-risk processing under GDPR Article 35 follows the same logic as the ISO 27001 risk assessment — both identify threats to data subjects, assess likelihood and severity, and define mitigations. Organisations running both processes should integrate them to avoid duplication. See our post on the data privacy impact assessment guide for how the two connect.

For broader governance integration, see GRC in cybersecurity and the ISO 27001:2022 implementation roadmap.

Frequently asked questions

Does ISO 27001 require a specific risk assessment method?

No. ISO 27001:2022 requires that you define and document your own methodology and apply it consistently. Asset-based and scenario-based approaches are both acceptable. What the standard requires is that results are consistent, comparable, and reproducible.

How often must the risk assessment be repeated?

Clause 8.2 requires risk assessments to be conducted at planned intervals and whenever significant changes occur. Most organisations conduct a full review annually and trigger ad-hoc assessments for major changes: new systems, new business lines, significant incidents, or changes in the threat landscape.

What is the difference between inherent risk and residual risk?

Inherent risk is the level of risk before any controls are applied. Residual risk is the level remaining after controls are in place. The risk treatment plan should show both, and residual risk should fall within your risk acceptance criteria. Accepted risks — even those below the threshold — should be formally acknowledged.

Can I use quantitative risk assessment for ISO 27001?

Yes. ISO 27001 does not prescribe qualitative versus quantitative methods. Quantitative approaches (assigning monetary values to assets and calculating expected annual loss) are more rigorous but more resource-intensive. For most organisations, a well-calibrated qualitative matrix is sufficient and auditor-acceptable.

ThreatBlock's ISO 27001:2022 Readiness course includes hands-on risk assessment exercises with real-world scenarios, helping you build a risk register and treatment plan that will withstand certification audit scrutiny.

About the author: Samaksh is Lead Instructor at ThreatBlock and holds the OSCP, CRTP, CRTO, and CEH certifications, with expertise in cybersecurity compliance and risk management. Read more on the author page · Editorial policy.