Most ISO 27001 projects do not fail on the controls. They fail on the document that is supposed to explain why those controls are there, and that document is the ISO 27001 risk assessment.
An auditor reading a Statement of Applicability can tell within a few minutes whether the risk work behind it was real. If the justifications are generic, the exclusions unargued and the risk levels suspiciously uniform, everything downstream becomes suspect. This article sets out what clause 6.1.2 actually asks of an ISO 27001 risk assessment, the eight steps in order, and the five mistakes that reliably produce a nonconformity.
- Clause 6.1.2 requires a defined, repeatable process, not a spreadsheet of threats.
- Every risk needs an owner, and the owner is a named person who can accept it.
- Annex A is a cross-check at the end, not the starting point. Working backwards from the 93 controls is the classic error.
- The Statement of Applicability is the output an auditor reads first, and it has to trace back to the assessment.
- Residual risk is accepted by the risk owner, in writing. Not by the consultant, and not by IT.
What clause 6.1.2 requires of an ISO 27001 risk assessment
The standard is unusually specific here, and reading it literally saves a lot of rework. It asks you to define and apply a process that does six things.
- Establishes and maintains risk criteria, including the criteria for accepting risk and the criteria for performing assessments.
- Ensures that repeated assessments produce consistent, valid and comparable results.
- Identifies risks associated with the loss of confidentiality, integrity and availability of information within the scope.
- Identifies the risk owners.
- Analyzes the risks: potential consequences, realistic likelihood, and the resulting level of risk.
- Evaluates the risks against the criteria and prioritizes them for treatment.
The second bullet is the one most processes fail. If two people running your method on the same risk would reach different levels, the method is not repeatable. The auditor tests that by asking somebody else to score one.
Assets or scenarios: two ways to run it
The 2022 version does not mandate a method. Both of the common ones are acceptable, and the choice matters more than people expect.
Asset-based. Inventory the assets, attach threats and vulnerabilities to each, score the result. It is thorough and it is familiar to auditors. It also produces an enormous register in any organization with more than a few hundred assets, and that register has to be maintained.
Scenario-based. Start from what could go wrong: ransomware encrypts the file servers, a developer leaks credentials, a supplier is breached. Fewer entries, far more readable, and it maps better onto how a business actually thinks. It needs more discipline to stay complete.
Whichever you pick, write the method down before you start scoring. A method chosen retroactively to explain the scores you already have is visible from the first page.
The ISO 27001 risk assessment, step by step
- 1 Set the criteria. What scale you score consequence and likelihood on, how you combine them, and above all what level of risk you are prepared to accept. Agree the acceptance threshold with management before you score anything, because afterwards it becomes a negotiation.
- 2 Identify the risks. Within the scope, against confidentiality, integrity and availability. Interviews find risks that documents never do.
- 3 Name the owners. One named person per risk, senior enough to accept it. A department is not an owner.
- 4 Analyze. Consequence if it happens, realistic likelihood that it does, and the resulting level. Realistic is the operative word: everything scored as catastrophic and near-certain tells you nothing.
- 5 Evaluate and prioritize. Compare each level against your acceptance criteria and sort what needs treating.
- 6 Choose the treatment. Under clause 6.1.3 there are four options: modify the risk with controls, retain it, avoid the activity, or share it with a third party. Insurance and outsourcing are sharing, not elimination.
- 7 Cross-check against Annex A. Now, and not before. Compare the controls you determined as necessary with the 93 in Annex A, and confirm you have not missed one that your own analysis implies.
- 8 Produce the Statement of Applicability and the treatment plan. Then get the risk owners to approve the plan and accept the residual risk, in writing.
Why the Statement of Applicability carries the weight
It is the document that joins everything together, and the one an auditor opens first. For each of the 93 Annex A controls it has to say whether it applies, why, and whether it is implemented.
Excluding a control is entirely legitimate. Excluding it without a justification that traces back to your own risk assessment is a nonconformity, and it is the most common one there is.
The test is simple: pick any included control and ask which risk it treats. Pick any excluded one and ask which part of the analysis makes it irrelevant. If either question needs improvisation, the document is not finished.
How often, and what triggers a new one
Clause 8.2 settles this: perform the assessment at planned intervals, or when significant changes are proposed or occur. Annually is the usual planned interval, and it is a floor rather than a ceiling.
What counts as a significant change is yours to define, and it should be written down before you need it. A new product line, a cloud migration, a major acquisition, a new category of personal data, a supplier taking over something material. Each of those changes the risk picture enough that last year’s assessment no longer describes the organization.
The five mistakes that produce a nonconformity
- 1 Starting from Annex A. Walking the 93 controls and inventing a risk for each one produces a register that cannot survive a single question.
- 2 Risk owners who are departments. Clause 6.1.3 requires the owner to approve the treatment plan and accept residual risk. A department cannot sign.
- 3 Uniform scoring. Forty risks all rated medium means the scale is not discriminating, which means the prioritization is not real.
- 4 No acceptance criteria. Without a threshold agreed in advance, nothing is above or below the line and the treatment plan has no logic.
- 5 A register that was never opened again. Clause 8.2 asks for repetition, and the evidence is a dated history, not a single file.
Where we fit
The assessment is a one-off piece of work. Keeping it alive between audits is not, and that is where most systems quietly decay. Cybersecurity as a service is built around the second part, so the system is still operating when the surveillance audit arrives.
If you are earlier than that and the question is what the whole certification involves, the real process and how long it takes is here. Of the Annex A controls, the ones that consume the most evidence are logging and monitoring, which rest on managed SIEM. The other is privileged access, which is critical access control. And the risks you accept on paper are the ones worth testing in practice, which is adversary simulation. Talk to the team.
Sources
- ISO, ISO/IEC 27001:2022, clauses 6.1.2, 6.1.3 and 8.2, with its 2024 amendment.
- ISO, ISO/IEC 27005:2022, guidance on managing information security risks.
