Every control in an ISO/IEC 27001 information security management system should exist because a risk assessment said it was needed. That makes the risk assessment the single most important piece of work in implementation — and the area where auditors find the most problems. This article explains what the standard requires, how to choose a method that will survive an audit, and how the results flow into risk treatment and the Statement of Applicability.
What the standard requires
Clause 6.1.2 of ISO/IEC 27001:2022 requires a defined information security risk assessment process. It must:
- Establish and maintain risk criteria, including risk acceptance criteria and criteria for performing assessments
- Produce consistent, valid and comparable results when repeated
- Identify risks associated with the loss of confidentiality, integrity and availability of information within the scope
- Identify a risk owner for each risk
- Analyse the potential consequences and the realistic likelihood of each risk, and determine its level
- Evaluate the risks against the criteria and prioritise them for treatment
The process and its results must be kept as documented information. Clause 8.2 then requires the assessment to be performed at planned intervals and whenever significant changes are proposed or occur.
Choosing a method
The standard does not prescribe a method. ISO/IEC 27005 gives detailed guidance and describes two broad approaches. An asset-based approach starts from information assets — systems, data sets, services, people — and asks what threats and vulnerabilities apply to each. An event-based approach starts from scenarios — a ransomware outbreak, a supplier breach, the loss of a key person — and works out their causes and consequences. Many organisations use a mix: event-based for strategic risks, asset-based for operational detail.
Whichever you choose, the test is the one in the standard: would two competent people applying your method to the same situation reach broadly the same result? Clear definitions for each likelihood and consequence level are what make that possible.
A simple, auditable scoring scheme
A common approach is to rate likelihood and consequence on a defined scale and combine them. The example below is illustrative — your own definitions should reflect your business, contracts and regulatory exposure.
| Level | Likelihood (example definition) | Consequence (example definition) |
|---|---|---|
| 1 — Low | Not expected within the next few years | Minor internal disruption, no client or regulatory impact |
| 2 — Medium | Could occur within the next year or two | Noticeable client impact or contractual breach |
| 3 — High | Expected to occur within the year | Serious client, legal, regulatory or financial impact |
Risk treatment
Clause 6.1.3 requires you to choose a treatment option for each risk that needs one — modify it with controls, avoid it by changing the activity, share it (for example through contracts or insurance) or retain it with an informed decision. You then determine the controls needed to implement those options. Controls can come from any source: your own design, industry frameworks or ISO/IEC 27002.
Only after that do you compare your controls with Annex A, which lists 93 controls in four themes: organisational, people, physical and technological. The comparison is a completeness check, to make sure no necessary control has been overlooked — it is not a list to implement from the top down.
The Statement of Applicability
The Statement of Applicability (SoA) is one of the documents certification auditors read first. For every Annex A control it must record:
- Whether the control is necessary, with the justification for including it
- Whether it is implemented
- The justification for excluding any Annex A control
- Any other necessary controls you have added beyond Annex A
Finally, a risk treatment plan sets out who will implement which controls by when, and the risk owners must approve the plan and formally accept the residual risks. Clause 8.3 requires the plan to be implemented and the results kept.
Common audit findings
- A risk register that does not connect to the SoA — controls marked applicable with no risk that needs them
- Annex A copied straight into the SoA with every control "applicable" and generic justifications
- No named risk owners, or residual risk never formally accepted
- Likelihood and consequence scales with no definitions, giving inconsistent results
- A risk assessment done once at implementation and never repeated after significant changes — a new cloud platform, an acquisition, a new client contract
Keeping it alive
The risk assessment is meant to be a living process. Review it at planned intervals, after incidents and whenever the business changes, and feed the results into management review. Surveillance auditors will ask what changed since last year and how the risk assessment reflected it.
If you are implementing ISO 27001 or transitioning to the 2022 edition, request a quote from GMSCPL with your scope, locations and headcount, and we will explain how the certification audit would examine your risk assessment and SoA.
