ISO 27001 risk assessment and treatment

ISO 27001:2022 asks you to define a repeatable way to assess information security risk (6.1.2), decide how to treat each risk and which controls that needs (6.1.3), and have risk owners approve the plan and accept what remains. Clause 8 then has you repeat the assessment and carry out the plan (8.1 to 8.3).

The requirement in plain English

Risks and opportunities (ISO 27001:2022 6.1.1). When you plan the ISMS, you consider your issues and interested parties’ requirements and decide which risks and opportunities need action, so the system works, avoids nasty surprises and improves.

Risk assessment (ISO 27001:2022 6.1.2). You define a process and apply it. It sets risk criteria, including when a risk is acceptable and when an assessment must be done. Run twice, it should give consistent, comparable results. It identifies risks to the confidentiality, integrity and availability of information in scope and names an owner for each. It analyses consequences and realistic likelihood to give a level of risk, then compares that level with your criteria to prioritise. You keep documented information about the process.

Risk treatment (ISO 27001:2022 6.1.3). For each risk you choose a treatment, determine the controls it needs, compare them with Annex A to check nothing necessary is missing (ISO 27001:2022 6.1.3 c)), and produce the Statement of Applicability (ISO 27001:2022 6.1.3 d)). You write a risk treatment plan (ISO 27001:2022 6.1.3 e)) and get risk owners to approve it and accept the residual risk (ISO 27001:2022 6.1.3 f)).

Objectives and change (ISO 27001:2022 6.2 and 6.3). You set measurable security objectives, plan how to reach them, and, new in 2022, monitor them. Also new in 2022, changes to the ISMS itself must be planned rather than made on the fly.

Operation (ISO 27001:2022 8.1, 8.2 and 8.3). You run the processes and the plan, repeat the assessment at planned intervals or on significant change, and keep the results of both assessment and treatment.

This is guidance to help you understand the requirement, not legal advice.

What good looks like

A 40-person healthtech company writes a four-page risk method. It scores likelihood and impact from 1 to 5 with a one-line definition for each score, so two assessors reach the same number. Anything scoring 12 or more needs treatment; anything below can be accepted by its owner. The method says a full review happens every year and before any significant change: a new product, a new hosting provider, an acquisition.

The risk register holds around 40 risks written as scenarios (“a support agent’s laptop is stolen with unencrypted customer exports on it”) rather than asset lists. Each has an owner from the business, not only from IT: the head of support owns the laptop risk. Each shows the score before and after treatment, the treatment option and the Annex A controls chosen.

The treatment plan lists every action with an owner, a due date and the resources it needs. Risk owners sign it off and accept the residual scores. Progress is reviewed monthly; the register is re-scored after any incident.

Security objectives are few and measurable: all laptops encrypted and managed by the end of the quarter, phishing-test click rate under 5%, every critical supplier reviewed within the year. Each has an owner and a monthly measure.

Evidence an auditor expects

Risk assessment method (required documented information): the auditor checks criteria, acceptance thresholds and how consistency is achieved.
Risk assessment results (required): a dated register with owners, scores and the link to treatment; the auditor samples risks and traces each one to a control.
Risk treatment plan (required): actions with owners and dates; the auditor checks progress against the dates.
Risk owner approval and acceptance: names and dates on the plan and on residual risk.
Statement of Applicability (required): traced back to the treatment decisions.
Security objectives and their measures (required): the auditor asks how each is monitored and what the latest figure is.
Change records: usual evidence for 6.3, showing an ISMS change was planned before it happened.

Common mistakes

Risk owners who never saw their risks

The security lead fills in every owner field and approves the whole plan. Clause 6.1.3 f) wants the owners themselves to approve treatment and accept residual risk. Walk each owner through their risks and record their sign-off.

Criteria nobody could apply twice

“High”, “medium” and “low” with no definitions give different answers from different people, which fails the consistency test in 6.1.2. Define each score with an example and test the method by having two people score the same risk.

Controls chosen first, risks invented to fit

Some teams start from Annex A, mark most controls as applicable, then write a risk for each. Auditors spot risks that read like control titles. Start from real scenarios in your scope and let the controls follow.

A register frozen since certification

The register carries the date of the original project. Clause 8.2 expects reassessment at planned intervals and on change; an auditor will ask what changed after the last major incident or new supplier. Re-score after every significant change and date each review.

Objectives that cannot be measured

“Improve security awareness” cannot be monitored, and monitoring became an explicit requirement in 2022. Give each objective a number, a date and an owner.

How Sted helps

For ISO 27001 risk work Sted’s knowledge base carries the Risk Management Procedure (PRC-RMP) with its Operating Risk Assessment Record (REC-ORAR) and Operating Opportunity Assessment Record (REC-OORA), and for planned changes the Change Management Policy (POL-CHG) with its Change Record (REC-CR).
Records are part of the Full Management System plan.
Management-system registers (scope, interested parties, obligations, issues, objectives, risks and opportunities, processes) are edited by administrators; the first three are drafted from your onboarding answers and the rest start empty.
Risk levels are computed from likelihood and impact.
When onboarding finishes, Sted drafts the management systems, scope, interested parties and compliance obligations registers from your answers, labels each drafted row “Derived from your onboarding answers” until someone edits it, and never overwrites an edited row; issues, objectives, risks and opportunities, and processes start empty, every register hangs off a management system, nothing is deleted, and only issues, objectives and risks can be retired.

Sted holds the method, the register and the records, and computes risk levels. It does not identify your risks or accept residual risk; your risk owners do.

Risk assessment guide: running the assessment step by step.
The Statement of Applicability: where treatment decisions become a list of controls.
Context of the organisation: the issues and requirements the assessment starts from.
Management-system registers: where the risk register lives in Sted.
Residual risk: what is left after treatment, and who accepts it.

Frequently asked questions

Does ISO 27001 still require an asset-based risk assessment?

No. Since the 2013 edition the standard asks you to identify risks to confidentiality, integrity and availability within scope, by any method that gives consistent, comparable results. Many small organisations find scenario-based assessment quicker; an asset inventory is still needed for Annex A 5.9 either way.

How often must we redo the risk assessment?

At planned intervals you set yourself, and whenever a significant change is proposed or happens (clause 8.2). Most organisations run a full review once a year and assess new risks as they arise, for example before adopting a new supplier or launching a product.

Who has to accept residual risk?

The risk owner, a person with the accountability and authority to manage that risk. Clause 6.1.3 f) asks risk owners to approve the treatment plan and accept the residual risk, so the evidence should carry their names and dates, not just the security lead’s.