Information security risk treatment

Plain-language summary

Deciding what to do about each risk that breaches your acceptance criteria, choosing the controls that will do it, checking the choice against Annex A, and recording all of it in the Statement of Applicability and a treatment plan the risk owners sign off.

What the clause is really asking

Treatment is where the risk assessment becomes a set of controls, and the Statement of Applicability (SoA) is the document that proves it. The clause asks you to define and apply a process that selects treatment options for each risk (modify, retain, avoid, share), determines all the controls necessary to implement those options, and compares the controls you chose with the 93 reference controls in Annex A to check nothing necessary has been left out — Annex A is a checklist for completeness, not a mandatory list, and you may add controls from any source. You must then produce the SoA: every necessary control, the justification for including it, whether it is implemented, and the justification for excluding any Annex A control. Finally, you formulate the risk treatment plan and obtain the risk owners' approval of it and their acceptance of the residual risks. Documented information about the process must be retained. The common failure is an SoA written independently of the risk register, with 'best practice' typed in the justification column for all 93 controls — auditors read that as a treatment process that never happened.

What auditors look for

Auditors trace risks to controls to SoA to evidence. They pick a high risk and ask which controls treat it, then open the SoA and check those controls are marked applicable with a justification that mentions the risk. They pick an excluded Annex A control and ask why — 'not applicable' needs a reason that survives a question. They check the treatment plan has owners, dates and resources, that risk owners (not the ISMS manager) approved it and signed off residual risk, and that 'implemented' in the SoA is true when they go and look at the control. Finally they check the SoA was updated when risks changed or controls were added.

Typical evidence

Statement of Applicability covering all 93 Annex A controls plus any additional controls, with inclusion justifications, implementation status and exclusion justifications; risk treatment plan with options, controls, owners, dates and residual risk; signed risk-owner approval of the plan and acceptance of residual risk; traceability from each risk to its controls; SoA version history showing updates.

How to comply — recommendations

Build the SoA from the risk register, not from the Annex A list. For each risk above threshold choose the option, name the controls, and let the SoA fill itself: a control is applicable because risks X and Y select it, or because a legal or contractual requirement does. Then walk Annex A once for completeness and write a specific reason for every exclusion. Put the treatment plan in the same workbook with owner, date, cost and the expected residual score, and have each risk owner sign their rows. Keep the SoA under version control and update it whenever the register changes. A single spreadsheet with linked tabs is enough for most organisations; the Qlause Risk Assessment and SoA Toolkit is built to this pattern.

Common nonconformities

SoA justifications generic, not linked to risks or requirements; SoA not updated when risks changed; Annex A controls excluded with no justification or with 'not applicable' only; controls marked implemented but not in place; treatment plan without owners, dates or resources; residual risk not accepted by the risk owner; no comparison with Annex A to check for omitted controls; treatment chosen before the risk was assessed.

Resources for this clause

• ArticleThe Statement of Applicability, explained — what ISO/IEC 27001 clause 6.1.3 requires, the four ways an SoA fails Stage 1, and how to build one from the risk register
• ArticleISO/IEC 27001:2022 explained for people who already run ISO 9001: what is the same, what is new, and how to get certified
• ArticleISO/IEC 27001:2022 Annex A explained: the 93 controls in plain English, theme by theme, with the 114-to-93 map and the attribute tags
• Toolkit · $39Risk & SoA ToolkitScore your information security risks on a documented method, pick the Annex A controls that treat them, and the Statement of Applicability writes its own first draft — every justification citing the risks behind it.
• Free downloadISO 27001 Gap Analysis ChecklistWhere you stand against ISO/IEC 27001:2022 in one afternoon — the 30 management-system requirements and all 93 Annex A controls, scored, with owners, dates and a readiness figure that calculates itself.
• Free masterclass · ~27 minISO 27001 MasterclassYou already know four fifths of ISO 27001. Here is the other fifth — the risk method, the SoA, the 93 controls, the evidence rhythm, POPIA, and a 44-week path.
• Free appAudit ManagerPlan the programme, anchor each finding to its clause and drive the NC to closure.