Information security risk treatment

Plain-language summary

Implementing the risk treatment plan from 6.1.3 — putting the chosen controls in place, on time, by the people named — and keeping the results.

What the clause is really asking

Treatment is only real when the controls exist and work. The clause requires the organisation to implement the risk treatment plan and to retain documented information of the results. In practice auditors read 'results' as more than a ticked plan: the control is in place, it has been checked to operate as intended, the residual risk has been re-evaluated against the acceptance criteria and, where the residual risk is still above threshold, the risk owner has either approved further treatment or formally accepted it. Slippage is normal — budgets, suppliers and priorities move — but a plan whose dates have all passed with no revision and no re-acceptance of the exposed risk is a finding. This clause and 8.2 together are the operating heartbeat of the ISMS: assess, treat, verify, repeat.

What auditors look for

Auditors take the treatment plan and go looking for the controls: the MFA that was to be enabled, the backup test that was to be scheduled, the supplier clause that was to be added. They compare planned dates to actual, ask what happened to overdue items and whether the risk owner re-accepted the interim exposure. They check the SoA's 'implemented' status against what they find, and that residual risk was re-scored after implementation rather than assumed. They also ask how implementation was verified — by the implementer alone, or by someone else.

Typical evidence

Risk treatment plan with status, completion dates and evidence per action; implementation records (configuration evidence, procedure issued, training delivered, contract clause signed); verification that controls operate (test results, first audit of the control); re-evaluated residual risk and risk-owner acceptance; revised plan and re-acceptance where actions slipped; SoA updated to reflect implementation status.

How to comply — recommendations

Run the treatment plan like any project: a status review monthly, evidence attached to each closed action, and a rule that an overdue action gets either a new date approved by the risk owner or a formal acceptance of the interim risk. Verify each implemented control with a simple test by someone other than the implementer and record it. Re-score the residual risk and update the SoA in the same sitting. Keep the plan and the SoA in the same workbook so one cannot drift from the other.

Common nonconformities

Treatment plan not implemented or largely overdue with no revision; controls recorded as implemented but not operating; no verification that controls work; residual risk never re-evaluated; overdue exposures not re-accepted by risk owners; results not retained; SoA implementation status inconsistent with the treatment plan.

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
• 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.