ISO 27001 Risk Assessment: A Complete Methodology Guide

Introduction

Risk assessment is not just a requirement of ISO 27001 — it is the engine that drives the entire standard. Every control you implement, every policy you write, and every audit finding you address should connect back to a risk in your risk register.

Yet risk assessment is also the area where organizations most commonly struggle. Many perform a superficial assessment using generic templates, which leads to a Statement of Applicability that cannot be justified during an audit. This guide provides a practical, step-by-step methodology to conduct a rigorous risk assessment that satisfies ISO 27001 requirements and produces genuinely useful results.

Why Risk Assessment Is Central to ISO 27001

Clause 6.1 of ISO 27001 requires organizations to plan actions to address risks and opportunities. Clause 8.2 requires the risk assessment to be performed at planned intervals or when significant changes occur.

The risk assessment informs: - Which Annex A controls are applicable (documented in your Statement of Applicability) - What priority to assign to implementation activities - How to justify control selections to auditors and stakeholders - How to demonstrate continual improvement over successive audit cycles

An auditor reviewing your ISMS will trace a clear line from identified risks to implemented controls to documented evidence. If that line is broken, you have a non-conformity.

Step 1: Define the Risk Assessment Methodology

Before assessing any risks, document your methodology. ISO 27001 does not prescribe a specific approach, but it does require consistency. Your methodology document should define:

Risk Identification Approach: How you identify assets, threats, and vulnerabilities. Will you use asset-based, scenario-based, or process-based identification?

Likelihood Scale: How you measure the probability of a risk materializing. A common approach uses a 1–5 scale (Very Unlikely to Almost Certain) with defined criteria for each level.

Impact Scale: How you measure the consequence of a risk occurring. Typically a 1–5 scale considering confidentiality, integrity, and availability impacts.

Risk Level Calculation: How likelihood and impact combine to produce a risk score. A simple multiplication (likelihood × impact = risk score, 1–25) is common and auditor-friendly.

Risk Acceptance Criteria: Define what risk level is acceptable without treatment. Risks below this threshold can be accepted; those above require treatment.

This methodology document is reviewed during Stage 1 of your certification audit.

Step 2: Identify Information Assets

Information assets are anything that has value to your organization and could be affected by an information security incident. They fall into several categories:

Information: Customer data, intellectual property, financial records, employee data, contracts.

Software: Business applications, databases, operating systems, source code.

Physical Assets: Servers, laptops, mobile devices, network equipment, office infrastructure.

Services: Cloud platforms, internet connectivity, utilities, third-party SaaS.

People: Staff, contractors, and their associated knowledge and access.

For each asset, document: the asset name, its owner (accountable person), its classification (e.g., Confidential, Internal, Public), and where it is stored or processed. This becomes your asset register — a living document that should be reviewed at least annually.

Step 3: Identify Threats and Vulnerabilities

For each significant information asset (or group of related assets), identify the relevant threats and vulnerabilities:

Threats are potential events or actions that could cause harm. Examples include: malicious insider access, ransomware attack, accidental data deletion, hardware failure, phishing attack, natural disaster.

Vulnerabilities are weaknesses that could be exploited by a threat. Examples include: weak password policy, unpatched software, lack of encryption, insufficient access controls, inadequate backup testing.

A practical approach is to work through each asset with a cross-functional team (IT, HR, Operations) and use a standard threat catalog (such as those provided by ENISA or NIST) as a prompt. Focus on threats that are plausible given your environment and industry — you do not need to catalog every conceivable threat.

Step 4: Evaluate and Score Risks

For each threat-vulnerability combination, evaluate the risk using your documented methodology:

1. Assign a Likelihood score (1–5): How likely is this threat to exploit this vulnerability given existing controls? 2. Assign an Impact score (1–5): What is the worst-case consequence if this risk materializes, considering confidentiality, integrity, and availability? 3. Calculate a Risk Score (Likelihood × Impact): Scores range from 1 (minimal) to 25 (critical). 4. Compare to acceptance criteria: Risks above your acceptance threshold require treatment.

Document everything in a risk register — typically a spreadsheet or GRC tool with columns for: Asset, Threat, Vulnerability, Existing Controls, Likelihood, Impact, Risk Score, Treatment Decision, and Residual Risk.

The risk register is a central artifact in your ISMS and will be reviewed at every internal audit and management review.

Step 5: Risk Treatment Options

For each risk above your acceptance threshold, you must decide how to treat it. ISO 27001 recognizes four treatment options:

Modify (Mitigate): Implement controls to reduce the likelihood or impact of the risk. This is the most common option. Controls are selected from Annex A or other sources.

Retain (Accept): Accept the risk without further action. This is valid for low-residual risks where the cost of treatment outweighs the benefit. Must be formally approved and documented.

Avoid: Eliminate the activity or process that gives rise to the risk. For example, stop storing certain data if the risk of holding it outweighs the business value.

Transfer (Share): Shift the risk to a third party through insurance, outsourcing, or contractual obligation. Note that accountability cannot be transferred — only financial consequence.

Document your treatment decisions in the Risk Treatment Plan (RTP). The RTP links each risk to a treatment option, the controls selected, the owner responsible, and the target date for implementation.

Linking the Risk Register to the SoA

The Statement of Applicability (SoA) is the critical link between your risk assessment and your Annex A controls. For each of the 93 Annex A controls, your SoA must state:

1. Whether the control is applicable (yes/no) 2. The justification for inclusion or exclusion — this must reference your risk assessment 3. The current implementation status (planned, in progress, implemented) 4. How it is implemented (reference to policies, procedures, or technical measures)

Controls are typically included because they mitigate an identified risk, or because they are required by legal/regulatory obligations. Controls are excluded when they are genuinely not applicable — for example, physical server controls for a fully cloud-based organization with no on-premises infrastructure.

Keep the SoA current — it should be updated whenever the risk assessment is revised.

Key Takeaways

A rigorous risk assessment is the most valuable investment you can make in your ISO 27001 journey. It ensures that your ISMS addresses real threats, not theoretical ones, and gives you a defensible basis for every control decision.

Treat the risk register as a living document. Review and update it at least annually and whenever significant changes occur — new systems, new threats, new business activities. The quality of your risk assessment will be the defining factor in whether your ISMS creates genuine security value or remains a compliance exercise.