What Clause 8.3 Requires
Clause 8.3 is one of the shortest clauses in the standard, and it carries two obligations. First, the organization must implement the information security risk treatment plan — the plan formulated under Clause 6.1.3, with its chosen treatment options, the controls determined as necessary, owners, resources, and timelines, as approved by the risk owners. 8.3 converts that plan from an approved intention into a delivery obligation: the work of building, changing, and operating the controls must actually be carried out.
Second, the organization must retain documented information of the results of the risk treatment. Results means outcomes, not aspirations: which treatments were completed and when, the evidence that controls now exist and operate, the residual risk that remains after treatment, and the updates that flow back into the risk register and into the Statement of Applicability implementation status. The plan itself originates in Clause 6.1.3; what 8.3 adds is execution plus a retained record of what execution achieved.
Why This Clause Exists
To close the loop between deciding how risks will be treated and demonstrably treating them — the risk treatment plan executed as real work, with retained results showing what changed.
What This Really Means
Clause 6.1.3 writes the prescription; Clause 8.3 is taking the medicine — and going back for the follow-up test. Everything before this point is decision-making: risks assessed, treatment options selected, controls determined, the SoA drafted, the plan approved by risk owners. 8.3 is where the ISMS either reduces risk or merely describes it. Two lines of standard cover what is usually the largest share of the entire implementation effort.
Treat the plan as a project tracker, because that is what it is: one line per treatment with the risk it addresses, the option chosen, the controls to implement, a named owner, resources, a target date, and a status. Run it like delivery work — a review cadence, blockers escalated, dates managed. The live cycle an auditor wants to see: a treatment completes, the control begins operating, the risk is re-scored to its residual level in the register, and the SoA implementation status for the relevant controls flips from planned to implemented. That four-step ripple — plan, control, register, SoA — staying synchronized is what a working Clause 8 looks like.
Slippage is normal and survivable; silence about it is not. When a treatment date moves, the standard's logic requires more than editing a cell — the risk owner who approved the plan and accepted the residual risk should re-approve the new timeline, because they are the one carrying the unmitigated exposure in the interim. An auditor reading a treatment plan reads its history: dates that moved with recorded reasons and re-approvals tell the story of an honest operation; dates that silently rewrote themselves, or a plan where nothing has ever closed, tell the other story.
The heart of 8.3 at audit is the end-to-end pull-through. The auditor picks a risk and follows the thread: register entry, treatment plan line, the implemented control inspected live, the re-scored residual risk, the SoA line that now says implemented. Where that thread holds for any risk they pick, the clause is conformant in the way that matters. 8.3 is also the third station of the operating cycle that holds the standard together — Clause 6 defines the machine, 8.2 keeps the risk picture current, 8.3 delivers the treatments, and 9.1 measures whether they work.
Why It Matters
Risk treatment is the part of the ISMS that actually changes your security posture — everything else is analysis, documentation, or measurement of what treatment built. An organization that assesses risks brilliantly but never executes treatments is precisely as exposed as one that never assessed at all; it is simply better informed about its exposure. Clause 8.3 is the standard's guarantee that the gap between knowing and doing is a nonconformity, not a lifestyle.
At Stage 1, auditors confirm the treatment plan exists, is risk-owner approved, and traces back to the assessment. Stage 2 is where 8.3 earns its reputation: auditors sample treatments marked complete and ask to see the control operating. The single most damaging finding pattern in the scheme is an SoA that claims implemented while the evidence says otherwise — it does not just fail this clause, it impeaches the credibility of every other claim the ISMS makes.
Where treatment execution breaks down, organizations face:
- •The eternal treatment plan – a plan where nothing ever closes signals an ISMS that decides but never delivers; chronic, unexplained slippage is standing surveillance-finding material
- •SoA drift – implementation statuses that disagree with the plan and with observable reality walk the audit straight into major-nonconformity territory
- •Unscored residual risk – treatments complete but risks never re-scored leave the register showing pre-treatment exposure, so management decisions run on dead data
- •Silent acceptance – a slipped or quietly abandoned treatment is an unapproved risk acceptance: exposure someone is carrying without the risk owner ever agreeing to it
- •A starved Clause 9 – without retained treatment results, 9.1 cannot evaluate control effectiveness and management review receives a fiction of progress
Documented Information Required
Risk treatment plan and results
MandatoryThe plan from Clause 6.1.3 maintained as a living document — risk, treatment option, controls, owner, resources, target date, status — plus retained results of implementation: completion evidence, dates, and the residual risk that remains. Good looks like every closed line linking to its evidence and to a re-scored register entry.
Updated Statement of Applicability
RecommendedThe SoA itself is mandated under Clause 6.1.3, but keeping its implementation status synchronized as treatments complete is 8.3 hygiene — auditors cross-check plan status against SoA status as a standard move.
Residual risk re-assessment records
RecommendedRegister entries re-scored after treatment, using the same 6.1.2 criteria, with risk-owner acceptance of what remains. This is the evidence that treatment changed the risk picture rather than just consuming budget.
Treatment review minutes and status reports
RecommendedThe cadence trail — periodic reviews of plan progress showing slippage surfaced, re-baselined dates re-approved by risk owners, and blockers escalated. This is what makes moved dates defensible.
See the full ISO 27001 mandatory documents checklist for every document and record the standard requires.
How to Implement Clause 8.3
Turn the approved plan into an executable tracker
Restructure the 6.1.3 output into one line per treatment: risk reference, chosen option, controls to implement, named owner, resources, target date, status, and an evidence-link field. A project board or a disciplined spreadsheet both work — what matters is that statuses and dates are maintained where delivery actually happens, not in a parallel compliance copy.
Assign owners who can deliver, and resource them
The owner of a technical treatment is the engineering lead who will build it, not the CISO who proposed it. Confirm budget and time against Clause 7.1 resource commitments at the point of assignment; an unstaffed treatment is not a plan, it is a wish with a date on it.
Run a delivery cadence
Review the plan on a fixed rhythm — monthly works for most organizations, fortnightly during heavy implementation. Update statuses in the meeting, escalate blockers, and minute the decisions. The minutes become part of your retained results and prove the plan is an operated document rather than an annual artifact.
Manage slippage formally
When a date moves, record the reason and have the risk owner re-approve the new timeline — they accepted residual risk against the original schedule and are carrying the interim exposure on the new one. Chronic slippage across the plan is a resourcing problem; surface it at management review rather than absorbing it line by line.
Define done as implemented plus evidenced
A treatment closes when the control exists and operating evidence is linked — the enforced IdP policy, the signed procedure, the training completion export, the retest report. Closing on the basis of a verbal "done" is the most common gap between a plan that looks finished and one that survives sampling.
Re-score residual risk and update the register
After implementation, reassess the treated risk against the same 6.1.2 criteria and record the residual score and date. Where residual risk remains above appetite, route it back to the risk owner for explicit acceptance or further treatment. The re-score is what proves the cycle ran — treatment without it is spend without a measured outcome.
Synchronize the SoA and feed the results forward
Flip the SoA implementation status as the related controls go live, so plan, register, and SoA tell one story. Then hand the new controls to Clause 9.1 monitoring so effectiveness gets measured, and report treatment progress and residual-risk movement into management review — that is the loop closing.
Audit Evidence
During Stage 1 and Stage 2 of your ISO 27001 certification audit, auditors will expect the following evidence to demonstrate conformity with Clause 8.3:
Documentation
- The risk treatment plan with owners, dates, and a visible status history — including re-baselined dates with recorded reasons
- Completion evidence for sampled closed treatments: configurations, deployed policies, training exports, retest reports, deployment tickets
- Risk register entries showing post-treatment residual scores with dates and risk-owner acceptance
- The Statement of Applicability with implementation statuses consistent with the plan and the register
- Treatment review minutes showing the cadence, slippage decisions, and escalations
Interviews
- Risk owners on the treatments addressing their risks, the residual levels they accepted, and any re-approvals of moved dates
- Treatment owners — engineering and operations leads — on what was implemented, when, and where the evidence lives
- The CISO or ISMS manager on how plan progress is tracked, reported to management, and reconciled with the SoA
Observations
- A sampled risk traced end to end: register entry, plan line, implemented control inspected live, residual score, SoA status
- The live control behind a closed treatment verified directly — for example the MFA or access policy actually enforced in the identity platform
- The tracker tooling examined for genuine history — status transitions and date changes spread over time, not a snapshot created for the audit
Practitioner Insights
At Stage 2 I run the same test on every ISMS: pick two or three risks and pull the thread — register entry to treatment line to implemented control to residual score to SoA status. That one trace tells me more about the management system than a day of document review, because consistency across four artifacts is very hard to fake. The most damaging answer an organization can give is an SoA that says implemented while the plan says in progress and the engineer says next quarter. Reconcile the three before anyone external reads them; that consistency is most of your audit defense on this clause.
Startups habitually treat the treatment plan as a certification artifact — built once, polished for the audit, untouched in between. The fix is to stop maintaining it as a separate document: run treatments as tickets on the board your engineers already work from, with owners, due dates, and an evidence attachment required to close. The dated export of that board is your retained documented information, and it stays current without anyone doing extra compliance work. The other gap I see constantly is closing a treatment with no linked evidence — a done column in a spreadsheet is a claim, not a record.
Common Challenges & Solutions
Challenge
The treatment plan was built for certification and froze — statuses have not changed since the Stage 2 audit.
Solution
Move the plan into the delivery tooling the owning teams already use and put a recurring review on the calendar with minutes. A healthy plan shows dated status transitions spread across the year; if every update clusters in audit month, the operating model is wrong — fix the model, not the team's diligence.
Challenge
Every treatment is assigned to the CISO or the security team, while the actual work needs engineering time nobody committed.
Solution
Reassign each treatment to the person who controls the delivery — the platform lead, the IT manager, the HR head for people controls — and secure the resource commitment explicitly under Clause 7.1, ideally as a recorded management review decision. Track unstaffed treatments as their own risk: unowned work is exposure with no countdown.
Challenge
Treatment dates slip chronically and silently — the plan is a graveyard of rewritten deadlines.
Solution
Introduce formal re-baselining: a moved date requires a recorded reason and risk-owner re-approval, because the risk owner carries the interim exposure. Report slippage as a metric at management review. Auditors accept moved dates with documented rationale; what they flag is dates that rewrote themselves and a pattern suggesting treatments never finish.
Challenge
Treatments complete, but residual risk is never re-scored — the register still shows pre-treatment exposure everywhere.
Solution
Make residual re-scoring part of the definition of done for every treatment, with register fields for residual score, date, and accepting owner. Run a quarterly reconciliation between plan and register to catch misses. Without the re-score you cannot demonstrate that treatment reduced anything — which is the entire point of the clause.
Challenge
At audit, the SoA implementation status disagrees with the treatment plan and with what engineers describe.
Solution
Give the SoA a single named owner and one synchronization trigger: whenever a treatment closes, the related SoA lines update in the same change. Reconcile SoA, plan, and register at each assessment round and before any audit. The three documents are read as one story — divergence between them is itself the finding, regardless of which one is right.
