Risk assessment is the center of ISO/IEC 27001. It is the reason one company includes a control and another excludes it, and the reason an auditor accepts both decisions. It is also the clause where teams most often have the right artifacts and the wrong process behind them.
The standard is specific about the process and silent about the method. It tells you what the risk assessment must achieve and what records it must leave. It does not tell you to use a five-by-five matrix, an asset inventory, or any particular tool.
This article walks through clause 6.1 of ISO/IEC 27001:2022 requirement by requirement, covers the documented information it demands, and ends with the gaps auditors find most often.
What clause 6 covers
Clause 6, "Planning", has three parts.
6.1 Actions to address risks and opportunities. This contains 6.1.1 (general), 6.1.2 (information security risk assessment), and 6.1.3 (information security risk treatment).
6.2 Information security objectives and planning to achieve them.
6.3 Planning of changes, added in the 2022 edition.
Two kinds of risk appear here, and they are easy to confuse. Clause 6.1.1 is about risks and opportunities for the ISMS itself: what could stop the management system achieving its intended outcomes, considering the issues from clause 4.1 and the requirements from clause 4.2. Clauses 6.1.2 and 6.1.3 are about information security risks: what could happen to the confidentiality, integrity, and availability of your information.
Clause 6 defines the process. Clause 8 runs it: 8.2 requires you to perform risk assessments at planned intervals and when significant changes are proposed or occur, and 8.3 requires you to implement the risk treatment plan.
Set the criteria before you assess anything
Clause 6.1.2 a) requires you to establish and maintain information security risk criteria, including:
Risk acceptance criteria. The level of risk the organization will accept without further treatment. Many methods also state who may accept which levels, which the standard does not require but auditors find useful.
Criteria for performing risk assessments. How you rate likelihood and consequence, what scales you use, and how you combine them into a level of risk.
Clause 6.1.2 b) then requires that repeated risk assessments produce consistent, valid, and comparable results. This is the requirement that rules out improvisation. If two people would rate the same risk differently because the scales are vague, or this year's assessment cannot be compared with last year's because the method changed, the process does not conform.
Write the criteria down before the first workshop. Define each point on each scale in words that a non-specialist could apply the same way. The guide to likelihood and impact scoring covers how to build scales that hold up.
Identify risks and their owners
Clause 6.1.2 c) requires you to apply the risk assessment process to identify risks associated with the loss of confidentiality, integrity, and availability for information within the scope of the ISMS. It also requires you to identify the risk owners.
Two points here are commonly misread.
You do not have to start from an asset inventory. Earlier versions of the standard required asset-based risk identification. The current text does not. You can identify risks from assets, from business processes, from threat scenarios, or from a mix. An asset inventory is still useful, and Annex A control 5.9 asks for one, but your risk method is your choice.
A risk owner is a person with accountability and authority. The definition in ISO/IEC 27000 describes the risk owner as the person or entity with the accountability and authority to manage a risk. That is usually a business or system owner, not the security team. If every risk in the register is owned by the CISO, the auditor will question whether ownership means anything.
Analyze and evaluate
Clause 6.1.2 d) requires you to analyze each risk:
Assess the potential consequences if the risk materialized
Assess the realistic likelihood of it occurring
Determine the level of risk
Clause 6.1.2 e) then requires you to evaluate the results: compare them with the criteria you set in a), and prioritize the analyzed risks for treatment.
The word "realistic" is doing work in d). Rating everything as likely, to make the case for budget, produces a register nobody can prioritize. Rating everything as unlikely produces a register that accepts risks the organization would not accept if asked directly.
The output of 6.1.2 is a risk register with each risk, its owner, its rating, and its priority. The guide to building a risk register auditors accept covers the fields and the common mistakes in more depth.
Treat the risks: the six steps of 6.1.3
Clause 6.1.3 defines the risk treatment process. In order, it requires you to:
Select treatment options for each risk, taking account of the assessment results.
Determine all controls necessary to implement the options you chose. A note says you can design controls yourself or identify them from any source.
Compare those controls with Annex A and verify that no necessary control has been omitted. Annex A is described as a list of possible controls, and another note says it is not exhaustive.
Produce a Statement of Applicability containing the necessary controls, the justification for including them, whether they are implemented or not, and the justification for excluding any Annex A controls.
Formulate a risk treatment plan.
Obtain the risk owners' approval of the plan, and their acceptance of the residual information security risks.
Step 2 comes before step 3 on purpose. The intended path is to decide what your risks need, then check Annex A as a safety net. Starting from Annex A and working backward to risks reverses this. Auditors can often tell, because the risk register then reads like a restatement of the control list.
Step 6 is the one most often missing evidence. The risk owner's approval needs to be visible: a signed or recorded approval, dated, by the person named as owner. A note in a meeting that "risks were discussed" does not show that a specific owner accepted a specific residual risk.
The Statement of Applicability and the risk treatment plan each get their own article later in this series.
The documented information clause 6 requires
Auditors will ask for these records. Each is required by the text, not by convention.
- Not done:
Documented information about the risk assessment process (6.1.2)
- Not done:
Documented information about the risk treatment process (6.1.3)
- Not done:
The Statement of Applicability (6.1.3 d)
- Not done:
Documented information on information security objectives (6.2)
- Not done:
Results of the risk assessments performed (8.2)
- Not done:
Results of the risk treatment (8.3)
"Documented information about the process" means the method: criteria, scales, roles, and frequency. "Results" means the outputs each time the process runs. Keep the results of each assessment, rather than overwriting them, so you can show the process ran at planned intervals and that the results are comparable over time.
Where auditors find gaps
The same weaknesses come up across organizations of every size.
No acceptance criteria. The method defines how to score risks but not which levels are acceptable, so nothing connects the score to a decision.
Inconsistent ratings. Similar risks scored differently because the scale definitions are loose.
Assessments that never repeat. One assessment before the certification audit and none since, despite clause 8.2's planned intervals.
No trigger for change. A major change, such as a new product or a new hosting provider, happened without a risk assessment.
Unapproved residual risk. Risks marked accepted with no record of who accepted them.
Missing context. Risks that ignore the issues and interested party requirements from clause 4, such as a contractual obligation no risk mentions.
For the wider set of requirements, see the ISO 27001 framework page.
How TrustLynce helps
TrustLynce keeps your risk register with scoring against your own criteria, named owners, and treatment plans, and records each owner's approval and acceptance of residual risk with a date. Each assessment's results are kept, so you can show repeated assessments over time.