What ISO 27001 requires from a risk assessment
The risk assessment is the centre of an ISO 27001 information security management system. Almost every other decision in the system, from which Annex A controls apply to what goes in the treatment plan, depends on it. That is why auditors spend so much time on it, and why a weak assessment undermines everything built on top.
ISO 27001:2022 sets out what the process must achieve rather than how to do it. The requirements sit in three clauses: 6.1.2 for the assessment itself, 6.1.3 for treatment, and 8.2 for carrying it out over time. Read together, they describe a cycle, not a document.
Clause 6.1.2: assessment
In summary, clause 6.1.2 requires the organisation to define and apply a risk assessment process. That process must establish risk criteria, including acceptance criteria and criteria for performing assessments; produce consistent, valid and comparable results when repeated; identify risks to the confidentiality, integrity and availability of information within the scope; identify a risk owner for each; analyse the potential consequences and realistic likelihood of each risk; determine levels of risk; and evaluate those results against the criteria to prioritise risks for treatment.
The organisation must also keep documented information about the process. In practice, that means a written methodology that someone else could pick up and apply in the same way, not only the output. An auditor who finds a risk register but no description of how the scores were reached will raise it.
Clause 6.1.3: treatment
In summary, clause 6.1.3 takes the evaluated risks and requires the organisation to choose treatment options, determine the controls needed to carry them out, and compare those controls with Annex A to check that nothing necessary has been left out. The standard notes that Annex A is not exhaustive, so controls beyond it can be added where the risks call for them.
The same clause requires the Statement of Applicability, a risk treatment plan, and approval from risk owners for both the plan and the residual risks that remain afterwards. That last requirement is often missed. Residual risk has to be explicitly accepted by the people accountable for it, and that acceptance has to be recorded.
Clause 8.2: performing it at planned intervals
Clause 8.2 moves the process from planning into operation. In summary, it requires risk assessments to be performed at planned intervals, and also when significant changes are proposed or occur, using the criteria set under 6.1.2. Results must be kept as documented information.
Clause 8.3 then requires the treatment plan to be implemented, with results retained. Between them, 8.2 and 8.3 are what auditors use to test whether the assessment is alive. A first assessment written for stage 1 of the certification audit and never touched again will meet 6.1.2 on paper and fail 8.2 at the first surveillance audit.
How to set risk criteria before you start
Most assessments go wrong before the first risk is written down, because the criteria were never agreed. Without criteria, two people scoring the same risk produce different results, scores drift between assessments, and nobody can say which risks are acceptable. Clause 6.1.2 asks for criteria first for exactly this reason.
Acceptance criteria
Acceptance criteria define the level of risk the organisation is prepared to live with without further treatment. A common form is a threshold on the risk matrix: anything scored at or below a given level can be accepted by the risk owner; anything above must be treated or escalated to management for a decision.
The criteria should reflect the business, not a template. A company whose product is a customer facing platform may accept very little availability risk; one handling health or financial data may set a stricter line for confidentiality. Whatever the choice, it must be approved by management and written down, because every acceptance decision later in the cycle refers back to it.
Criteria for performing the assessment consistently
The second set of criteria defines how the assessment is done: the likelihood scale, the consequence scale, how they combine into a risk level, who participates and how often. A five point scale for each, multiplied into a matrix, is a common choice. What matters is that each point on each scale is defined in terms people can apply, such as "could happen within a year" or "loss of a key customer contract", rather than "medium".
These definitions are what make clause 6.1.2 b) achievable: repeated assessments that produce consistent and comparable results. If last year's "high" and this year's "high" mean different things, the organisation cannot show whether its risk position improved, and the auditor will notice.
How to identify risks and assign owners
Identification is where scope becomes concrete. The question is which events could compromise the confidentiality, integrity or availability of information within the scope of the management system, and the answer needs to cover technology, people, suppliers and physical locations, not only the IT stack.
Event based and asset based approaches
ISO 27001 does not prescribe how to identify risks. ISO 27005:2022, the guidance standard for information security risk management, describes two complementary approaches. An event based approach starts from risk sources and scenarios: what could happen, who or what could cause it, and what the consequences would be. An asset based approach starts from information assets and the threats and vulnerabilities affecting each one.
Both are valid, and many organisations combine them. An event based view keeps the assessment readable for management and captures business level scenarios, such as a ransomware attack stopping operations or a supplier breach exposing customer data. An asset based view adds operational detail, such as a former employee's account still active in a SaaS tool, or an unpatched server facing the internet. The risk of relying on one alone is missing what the other would have caught.
Why every risk needs a named owner
Clause 6.1.2 requires a risk owner for every identified risk. ISO's vocabulary defines the owner as the person or entity with the accountability and authority to manage the risk. That is a business role, not automatically the IT lead: the owner of a risk to customer data in the CRM is often the head of sales or customer operations, because they decide how that system is used.
Ownership is what turns the register into decisions. The owner approves the treatment, accepts the residual risk, and answers when the auditor asks why a control was chosen. A register where every risk is owned by "IT" or by nobody is one of the clearest signs, to an auditor, that the assessment was produced rather than operated.
How to analyse and evaluate each risk
Analysis puts numbers or levels on each risk; evaluation compares them with the acceptance criteria. Both steps depend on the criteria set at the start, which is why skipping that work shows up here as inconsistent scores.
Likelihood and consequence scales
For each risk, the assessor estimates the realistic likelihood of it occurring and the consequence if it did, taking existing controls into account. The standard asks for realistic likelihood, so the estimate should draw on what is known: incident history, threat intelligence relevant to the sector, the exposure the organisation actually has, and the effectiveness of the controls already running.
Consequence should be expressed in business terms: operational disruption, contractual or regulatory exposure, loss of customers, harm to individuals. Expressing it this way makes the scores defensible to management and links the assessment to what the organisation cares about, rather than to abstract technical severity.
Prioritising against the acceptance criteria
Once each risk has a level, evaluation sorts them. Risks within the acceptance criteria can be accepted by their owners; risks above the line go to treatment, ordered by level. This ordering is what the treatment plan follows, and it should be visible in how resources are allocated.
Evaluation is also the point to sanity check the result as a whole. If almost every risk is rated high, the scales are probably miscalibrated. If almost everything is acceptable, the assessment may be understating exposure, or existing controls are being credited with more effectiveness than they have. Both patterns are worth correcting before the treatment plan is built on them.
How the assessment feeds the treatment plan and the SoA
Clause 6.1.3 is where the assessment produces its two most visible outputs: the risk treatment plan and the Statement of Applicability. Both should be traceable back to individual risks. If they cannot be, the auditor will conclude that the controls were chosen first and the risks written afterwards to justify them.
The four treatment options
ISO 27005 and ISO 31000 describe the treatment options organisations normally choose between. A risk can be modified, by adding or improving controls to reduce likelihood or consequence; retained, by accepting it as it is within the criteria; avoided, by stopping the activity that creates it; or shared, by transferring part of it, for example through insurance or a contract with a supplier.
Each option is a business decision, and each needs a record of who made it and why. Sharing a risk with a supplier does not remove the need to monitor that supplier, and retaining a risk above the acceptance threshold requires explicit management approval. The treatment plan sets out which option applies to each risk, the actions, the owner and the timescale.
Linking treatments to Annex A controls
The controls chosen to modify risks are then compared with the 93 controls in Annex A of ISO 27001:2022, grouped into organisational, people, physical and technological themes. The Statement of Applicability records, for every Annex A control, whether it is included, whether it is implemented, and the justification for including or excluding it.
The justification is where the link to the assessment shows. A control included because it treats specific risks, and excluded because no identified risk calls for it, gives the auditor a clean trail. A Statement of Applicability where every control is marked "applicable" with no reference to risks suggests the assessment had no influence on control selection.
When to repeat the assessment
Clause 8.2 requires assessments at planned intervals and when significant changes are proposed or occur. The standard does not fix the interval; an annual cycle, aligned with the management review under clause 9.3, is common practice. Management review is expected to take into account the results of risk assessment and the status of the treatment plan, so aligning the two keeps both meaningful.
Significant changes trigger an assessment outside the cycle. Typical triggers include a new product or service, a move to a new cloud provider, an acquisition, a change in regulatory obligations, a major supplier change or a serious incident. The key word in clause 8.2 is "proposed": the assessment should happen before the change goes live, when it can still shape the design, not months afterwards.
What auditors commonly find wrong
The findings auditors raise on risk assessments are remarkably consistent. Criteria that were never documented or approved, so scores cannot be reproduced. Risk registers with owners missing, or every risk owned by the same person. Treatment plans with actions but no dates or no named owner. Residual risks never formally accepted.
Other findings come from the assessment drifting away from reality. Risks that only cover technology, ignoring people, suppliers and physical security. A Statement of Applicability whose exclusions are not justified by the assessment. And, most often at surveillance audits, an assessment that was not updated after a significant change the auditor can see elsewhere in the evidence, such as a migration or a new product line. The stalled ISO 27001 project post covers how these gaps tend to accumulate when nobody owns the system between audits, and ISMS vs security policies explains why the risk process, not the document set, is what makes it a management system.
Qalea's platform brings risk management, controls and evidence together in one place, so the register, the treatment plan and the proof behind each control are kept side by side. Qalea's team supports the work around it: setting criteria the organisation can apply consistently, running the assessments with the right owners in the room, and flagging when a change in the business should trigger a new one. The ISO 27001 topic page collects the rest of the series.
