---
title: "ISO 27001 Clause 8.3: executing your risk treatment plan"
canonical: https://www.grcmana.io/vault/iso-27001/clause-8-3-information-security-risk-treatment
published: 2023-01-04
updated: 2026-10-07
author: "Harry West"
framework: "ISO 27001"
control: "Clause 8.3 Information security risk treatment"
journeyStage: implementation
---

# ISO 27001 Clause 8.3: executing your risk treatment plan

## Key takeaways

Clause 8.3 is the 'do' phase of risk treatment: you carry out the plan and keep records proving each treatment happened and worked. Auditors follow a thread from risk to decision, Statement of Applicability control and live configuration. Evidence-gated tickets, scheduled reconciliation and expiring acceptances keep that thread intact all year.

- **The mandate** — Clause 8.3 requires you to carry out the treatment plan built under Clause 6.1.3 and keep documented information of the results, so each treatment can be shown to have happened and worked.
- **The golden thread** — Auditors trace a risk from its assessment to the treatment decision, the Statement of Applicability control and live operational proof. A break anywhere in that chain becomes the finding.
- **The four Ts** — Every above-tolerance risk gets one deliberate, recorded response: treat it with controls, transfer it through insurance or contracts, tolerate it by signed acceptance, or terminate the activity.
- **Residual risk** — Record the score before treatment, apply the control, then re-score and compare the result with your acceptance threshold. Without that before-and-after, nothing demonstrates the treatment worked.

Your risk register is immaculate. The auditor asks to see MFA enforced in the console for a risk you marked as treated, and you can offer only a policy PDF. ISO 27001 Clause 8.3 is where that gap becomes a finding.

This guide shows Information Security Managers, Heads of Compliance and CTOs how to execute the risk treatment plan in live systems, document transfers and acceptances, recalculate residual risk and survive the Stage 2 sample. It also shows how to keep the plan moving all year, so the week before the audit stays quiet.

## What does ISO 27001 Clause 8.3 require?

ISO 27001 Clause 8.3 requires you to carry out the risk treatment plan built under Clause 6.1.3 and keep documented information of the results, so you can show each treatment happened and worked. It is the 'do' phase of the plan-do-check-act cycle, and Stage 2 auditors test it by looking for execution evidence, not intent.

Clause 8.3 is one of the shortest clauses in the standard, and it is where documented firms and certified firms part company. Plenty of firms record their risks well; certified firms carry the plan out and keep the records. The requirement is simple to state and hard to prove.

Think of it as the middle of a loop. Clause 6.1.3 plans, Clause 9.1 measures, and management review acts on what the measurement finds. The [NCSC Cyber security risk management framework](https://www.ncsc.gov.uk/collection/risk-management/cyber-security-risk-management-framework) takes the same view: it describes implementing, managing and maintaining technical and non-technical controls, not installing them once and moving on.

The cost of skipping execution is concrete. A firm that assesses well and treats slowly carries every risk it documented, plus a trail proving it knew. After a breach, that trail supports a negligence argument and complicates an insurance claim. Stage 1 reviews documents, while Stage 2 tests implementation, so only execution evidence gets you certified.

## How does Clause 8.3 differ from Clause 6.1.3?

Clause 6.1.3 chooses what to do about each risk: the treatment options, the Statement of Applicability and the plan itself. Clause 8.3 does the work and proves it. An auditor reads your plan under 6.1.3, then reads your tickets, configurations and signatures under 8.3 to see whether the plan became reality.

The split matters because auditors test each clause against its own artefacts:

- **Clause 6.1.3:** the treatment options, the Statement of Applicability and the approved plan with owners and dates.
- **Clause 8.3:** closed tickets, configuration exports, signed acceptances, insurance policies and decommissioning records.
- **Clause 8.2 as the input:** current risk assessment results that tell you which risks need treatment now.

A plan can be excellent under 6.1.3 and still fail under 8.3. The reverse happens too: engineers do real work, but no recorded decision ties it to a risk, so the effort earns no credit. Both halves must reconcile, and neither carries the other.

## What is the auditor's golden thread through Clause 8.3?

The golden thread is the trace an auditor follows: a risk surfaced by Clause 8.2 leads to a treatment decision, that decision to a control in the Statement of Applicability, and that control to operational proof it is running. A break anywhere in the chain is where the Clause 8.3 finding lands.

Each link has its own artefact. Walk the chain in this order:

1. **Risk:** the entry from the Clause 8.2 assessment, with its initial score.
2. **Treatment decision:** the chosen response, a named owner, a date and the approved resourcing.
3. **SoA control:** the Annex A control that delivers the reduction, with a justification that matches the risk.
4. **Operational proof:** the configuration export, closed ticket, insurance policy or signed acceptance.
5. **Residual score:** the re-score after treatment, checked against the acceptance line.

The [NCSC Basic Risk Assessment and Management Method](https://www.ncsc.gov.uk/collection/risk-management/a-basic-risk-assessment-and-management-method) works the same way from the practitioner's side: its treatment plan records each risk against the controls proposed to treat it, and a separate assurance plan then links each treatment to how it will be assured.

The strongest single artefact is one risk shown end-to-end. One complete thread persuades more than fifty plan rows. Pick your highest-scoring access or supplier risk and assemble the whole chain in one place before the audit. If you can walk it in two minutes, you are ready for the auditor to pick any other.

Breaks cluster in predictable places: a risk with no treatment row, a reduction with no SoA control, or a control that exists on paper with no operational record. Each is cheap to find yourself and expensive to have found for you.

## How do the four Ts apply to Clause 8.3 risk treatment?

The four Ts give every above-tolerance risk one of four responses: treat it with controls, transfer the financial impact through insurance or supplier terms, tolerate it through formal acceptance, or terminate the activity that creates it. Each is legitimate when the choice is deliberate and recorded.

The [NIST Computer Security Resource Center Glossary](https://csrc.nist.gov/glossary/term/risk_response) defines risk response as accepting, avoiding, mitigating, sharing or transferring risk. The vocabulary differs from the four Ts, but the demand is identical: an intentional, informed decision per risk, never a default.

For each above-tolerance risk, our guidance is to record:

- **A named owner** with real authority to change the system or spend the money.
- **A chosen response** from the four Ts, with the reason for it.
- **A hard date**, with milestones for anything longer than a quarter.
- **The delivering control**, mapped into the SoA so the thread is traceable rather than reconstructed.

A treatment plan without dates is a wish list.

Terminating counts as a full treatment. Cancelling a risky project or retiring a legacy system removes the risk entirely, and the cancellation or decommissioning record is your evidence. Teams overlook this option because it generates no configuration to export.

The common failure is blanket controls: the same generic mitigation, usually 'enforce policy and train staff', pasted against every risk. Auditors spot it quickly, because a phishing risk and a supplier outage cannot share a treatment. Write the control the specific scenario needs, and the SoA mapping follows.

## How do you execute risk treatment in your systems, not your documents?

Execute treatments where the risk lives: enforce multi-factor authentication and least-privilege access in the console, run the patching workflow, fix what the penetration test found and change physical controls. The configuration is the treatment; the policy describing it is not. Capture dated, attributable evidence as the work happens, not afterwards.

Take multi-factor authentication. The treatment is closed when the identity provider enforces it for every account in scope and an export dated that week proves it. A policy requiring MFA without enforcement is the paper version of the same control.

A risk closed with only a policy attached hasn't been treated, just renamed.

Resourcing is part of execution. A plan whose actions have no budget, staffing or tooling behind them is a known-risk backlog. Management's formal approval of that resourcing is itself evidence, so minute it.

Penetration-test findings deserve their own trail: finding, fix, retest, closure. The retest is the proof the treatment worked, not merely that someone touched the system.

Each record, whether the ticket, the configuration export or the decommissioning record, should be attributable, dated and original. Evidence rebuilt later reads as exactly that, and auditors see it in the file dates.

One pitfall undoes good execution: ghost ownership. The action is assigned to a team or to someone who has left, so accountability lives only in the spreadsheet. Check owners against your current staff list every month.

The table pairs each treatment with the proof that works and the paper that fails.

| Treatment | Live proof | Paper that fails |
| --- | --- | --- |
| MFA enforcement | Identity provider enforcement setting plus a dated export of enrolled accounts | Access control policy stating MFA is required |
| Least-privilege access | Role assignments exported from the console, with a recent access review | Approved role matrix nobody reconciled |
| Patching | Closed patch tickets and scan results showing the fix | Patch management policy |
| Penetration-test remediation | Finding-by-finding trail through to retest | Report filed with no follow-up |
| Physical change | Work order and installer sign-off | Statement that the premises are secure |

## How do you document risk transfer and risk acceptance?

Transfer needs instruments that exist: a bound cyber insurance policy or supplier contracts carrying security obligations. Acceptance needs a written business justification, a cost-benefit view and a senior signature confirming the residual position sits inside tolerance. Acceptance by silence, an untreated and unsigned risk, is a finding rather than a decision.

A transfer is real when the instrument is in force and covers the scenario. Check that the policy limits and exclusions match the risk, and that supplier contracts carry obligations such as breach notification and audit rights. Keep the bound policy document and the signed contract alongside the risk.

The supply chain is the usual blind spot. A transfer that was never contractually enforced is a hope, and a supplier assurance report nobody reviews is not assurance. Assign a reviewer and a date to every report you rely on.

A valid acceptance record holds four items:

- **Business justification:** why the business is living with the risk.
- **Cost-benefit view:** what treatment would cost against the exposure.
- **Residual position:** the score after any partial treatment, inside stated tolerance.
- **Senior signature:** someone with authority over the affected business area.

Acceptance is a legitimate treatment for risks the business would rather not fund, provided those four items exist and the review minutes show management discussed them. At 50 people, one page per acceptance is enough, provided it carries a review date. Authority matters more than length.

An accepted risk with no expiry date isn't a decision. It's a burial.

## How do you recalculate residual risk after treatment?

Record the initial score, the treatment applied and the residual score, then check that residual score against your stated acceptance threshold. The before-and-after is the point of the exercise. A plan that never recalculates cannot show that anything worked, and management cannot confirm residual exposure sits within risk appetite.

Make the recalculation mechanical. Score the risk before treatment using the same method as the Clause 8.2 assessment, apply the treatment, re-score once evidence exists, and compare against the line you set for acceptable residual risk. Without a defined threshold there is nothing to score against.

An illustrative example: unmanaged laptops holding customer data score 20, from likelihood 4 and impact 5. Once disk encryption and device management are enforced, likelihood falls to 2 and the residual score is 10. Against a threshold of 12, the risk is within appetite and the thread closes.

Data protection work applies the same logic. The [Information Commissioner's Office DPIA Guidance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/data-protection-impact-assessments/) says an assessment need not show every risk eradicated, but it should document what remains and assess whether it is justified.

The pitfall is completion without recalculation: tickets closed, scores untouched. Auditors look for genuine movement, and a residual score identical to the initial one raises the question of why you treated the risk at all.

## What do auditors sample for Clause 8.3 in Stage 2 and surveillance audits?

Auditors trace a handful of risks end-to-end, check that before-and-after scores reflect genuine recalculation, interview owners against their milestones, test one paper treatment against live configuration and inspect acceptances for justification and authority. They also compare early-cycle and late-cycle plan states, because a plan that only moves in audit season shows.

Expect the auditor to choose risks from your register, then ask questions like these:

- "Walk me from this risk to its treatment decision, its SoA line and the change that happened."
- "What was the score before treatment, and what is it now? Show me the recalculation."
- "You own this treatment. What are your milestones and where do they stand?"
- "This says MFA is enforced. Show me in the console, not the policy."
- "Where is the signed approval for the risks you accepted, and the reasoning behind it?"

Owners are interviewed directly, so brief them. An owner who cannot say where a milestone stands suggests ghost ownership, whatever the spreadsheet claims.

Version history and ticket timestamps do the rest. A quarter's movement compressed into the final week is visible in every date.

Grading follows certification-body practice rather than the wording of the clause:

- **Major:** a plan clearly not being carried out, with no owners, no movement and no operational evidence, or risk acceptance with no management authority behind it.
- **Minor:** a slipped milestone, one stale residual score, or a thin justification on a single acceptance.
- **Pattern:** repeated minors across several risks can aggregate into a major.

Rehearse the sample a month before the visit. Trace three risks, test one treatment against the console and fix whatever breaks. That rehearsal is cheap, and it turns the audit into a confirmation of work you already trust.

## How does GRC engineering keep Clause 8.3 running continuously?

GRC engineering turns the treatment plan into a ticketing backlog where each action has an owner and due date, closure is gated on attached evidence, a scheduled job reconciles risks, treatments and SoA controls, completion triggers residual re-scoring, and accepted risks expire for review. The evidence base assembles itself as work completes.

The aim is to remove the pre-audit batch update by construction. Five mechanisms do it:

1. **Plan as backlog:** treatment actions live in the ticketing system with owners, due dates and status, so slippage shows weekly and the change history is continuous.
2. **Evidence-gated closure:** a ticket cannot close without its configuration export, enforcement screenshot or remediation record attached.
3. **Scheduled reconciliation:** a job checks that every above-tolerance risk has a treatment item, every reduction maps to an SoA control and every completed treatment has a re-score.
4. **Residual re-scoring as workflow:** completing a treatment raises the re-score task on the linked risk, applies the acceptance line and routes out-of-tolerance results to management.
5. **Expiring acceptances:** accepted risks carry review dates that reopen them automatically.

Ghost ownership disappears too, because a ticket assigned to a leaver shows up when their account is removed. The human layer shrinks to judgement: choosing the response, signing the acceptance and deciding what tolerance means for the business.

The commercial upside is direct. When an enterprise buyer's due-diligence team asks to see a risk you closed, you open the ticket and show the owner, the evidence, the residual score and the signature. A questionnaire that would have stalled the deal becomes a screen-share.

## Frequently asked questions

### Who should own a Clause 8.3 risk treatment action?

Give each action to one named individual who can change the system or spend the budget, not to a team. Where work spans functions, keep a single accountable owner and list contributors in the ticket. A CTO often owns technical items, while a Head of Compliance owns the plan as a whole. The action owner is not always the risk owner: under Clause 6.1.3 the risk owner approves the plan and accepts the residual risk, so both names belong on the record.

### Does Clause 8.3 require budget and staffing behind each risk treatment?

Not in its own words. The duty to find and provide resources for the ISMS sits in Clause 7.1, and the treatment plan is where an auditor sees whether you met it. Record the approved resource against each action or wave, in the plan or in management review minutes. If management declines funding, the outcome becomes a tolerate decision that needs a signature.

### How long does the first Clause 8.3 risk treatment execution wave take?

At around 50 people, the first execution wave typically runs six to twelve weeks alongside the Annex A build it drives, then becomes continuous. It depends on current Clause 8.2 inputs and on the decision framework from Clause 6.1.3, so late changes to either stretch the timeline. Start with the highest-scoring risks so one complete thread exists early.

### How does Clause 8.3 risk treatment progress feed management review?

Treatment progress is an input to Clause 9.1 measurement and to management review. Report open actions by age, completed treatments with their residual scores, and acceptances nearing expiry. Minuting the discussion gives you the resourcing approval and the evidence that management oversaw the plan, both of which auditors ask to see.