ISO 27001 Clause 8.3: Risk Treatment

Clause 8.3 requires your organization to implement the information security risk treatment plan and retain documented information of the results. This is the execution clause - where the treatment decisions made during risk assessment under Clause 8.2 get turned into implemented controls. Without 8.3, your risk register is a list of intentions. With it, the register becomes evidence of action.

What the clause requires

ISO 27001:2022 Clause 8.3 states:

The organization shall implement the information security risk treatment plan.

The organization shall retain documented information of the results of the information security risk treatment.

Two requirements, deliberately concise:

1. Implement the risk treatment plan - carry out the treatment decisions documented in the plan
2. Retain documented results - keep evidence showing what was done and what the outcomes were

The clause is short because the treatment plan itself is defined under Clause 6.1.3, and the risks being treated are assessed under Clause 8.2. Clause 8.3 closes the loop by requiring execution and proof.

How to implement risk treatment

Understand the four treatment options

Every risk above your acceptance threshold needs a treatment decision. The standard recognizes four options:

• Mitigate - apply controls to reduce likelihood, impact, or both. The most common option. Implementing MFA for unauthorized access risk, deploying endpoint detection for malware risk, or establishing backup procedures for data loss risk.
• Transfer - shift some or all of the risk to a third party. Cyber insurance is the classic example. Outsourcing infrastructure to a cloud provider transfers some operational risk (though responsibility for the data remains yours).
• Avoid - eliminate the activity that creates the risk. If a legacy application processes sensitive data but cannot be secured, decommissioning it avoids the risk entirely.
• Accept - acknowledge the risk and take no additional action. Valid when the risk is within your acceptance criteria or when the cost of treatment exceeds the potential impact. Requires explicit approval from the risk owner.

Most risk treatment plans for a 20-person SaaS company contain 15-30 risks, with roughly 70-80% treated through mitigation, 10-15% accepted, and the remainder split between transfer and avoidance.

Build a treatment implementation tracker

The risk treatment plan from Clause 6.1.3 defines what you intend to do. Clause 8.3 needs evidence that you actually did it. A treatment implementation tracker bridges the gap. For each risk being treated, track:

• Risk ID - linking back to the risk register from Clause 8.2
• Treatment action - the specific control or measure being implemented
• Responsible person - who is accountable for implementing this action
• Target date - when implementation should be complete
• Status - not started, in progress, complete, or deferred
• Evidence - what documentation proves the action was taken (configuration screenshots, policy documents, training records, purchase orders)
• Residual risk - the risk level after treatment, confirmed by the risk owner

For a small organization, this can be additional columns in your risk register spreadsheet. Compliance platforms like Eramba or Vanta provide built-in treatment tracking with workflow features.

Connect treatments to Annex A controls

Most mitigation actions map to specific controls in Annex A of ISO 27001. Your Statement of Applicability documents which controls are applicable and why. The risk treatment plan should reference which SoA controls each treatment action implements.

For example:

• Risk: “Unauthorized access to production systems” → Treatment: implement role-based access control → SoA controls: A.5.15 (access control), A.5.18 (access rights), A.8.2 (privileged access)
• Risk: “Data loss from system failure” → Treatment: automated daily backups with tested recovery → SoA controls: A.8.13 (information backup), A.8.14 (redundancy)
• Risk: “Phishing leading to credential compromise” → Treatment: security awareness training and simulated phishing → SoA controls: A.6.3 (information security awareness), A.8.5 (secure authentication)

This mapping demonstrates traceability from identified risks through treatment decisions to implemented controls - exactly what auditors want to see.

Document residual risk acceptance

After implementing treatment actions, some risk remains. This residual risk must be formally accepted by the risk owner. For risks treated through mitigation, the residual risk should be lower than the inherent risk. For accepted risks, the full risk level is accepted.

Document the acceptance explicitly. A record showing the risk owner reviewed the residual risk level and approved it is sufficient. Some organizations use a formal acceptance form; others record it in the risk register with the owner’s name and date.

Risk owners should be people with the authority to accept risk on behalf of the organization - typically department heads, the CISO, or senior management. The ISMS manager should not be accepting all risks by default.

Connecting 8.3 to the rest of your ISMS

Clause 6.1.3 connection. Clause 6.1 defines the risk treatment plan and the process for selecting controls. Clause 8.3 executes that plan. The treatment plan is the what and why; 8.3 is the proof that it happened.

Clause 8.2 connection. Risk assessment identifies and evaluates risks. Risk treatment acts on them. These two clauses form a continuous cycle - assess, treat, reassess to verify treatment effectiveness. When the next 8.2 cycle runs, it should reflect the impact of treatments implemented under 8.3.

Clause 8.1 connection. Operational planning provides the process framework. Risk treatment implementation is one of the key processes governed by 8.1, with defined criteria, timelines, and monitoring.

SoA connection. The Statement of Applicability links risk treatment to Annex A controls. Every applicable control should be traceable to one or more risks in the treatment plan. Controls without risk justification get questioned by auditors.

Clause 9.1 connection. Performance evaluation measures whether implemented controls are effective. If monitoring under 9.1 shows a control is not reducing risk as expected, the treatment plan needs updating.

What auditors check

Implementation completeness. Auditors compare the risk treatment plan against implementation evidence. If the plan says “implement endpoint detection on all workstations by Q2,” they check whether it was deployed and when. Open treatment actions with passed deadlines are a common finding.

Evidence quality. Auditors sample treatment actions and verify the evidence. For a control like “annual access reviews,” they look for actual review records - not just a policy saying reviews will happen. Configuration evidence, training attendance logs, and test results all count.

Residual risk acceptance. Auditors check whether residual risks have been formally accepted by appropriate risk owners. Missing acceptance records suggest the organization has not closed the treatment loop. Accepting a critical risk without justification raises questions.

Traceability. Auditors trace the chain from risk register through treatment plan to implemented controls to SoA. Gaps in this chain - risks without treatment decisions, treatments without evidence, or SoA controls without risk justification - indicate process weaknesses.

Treatment plan currency. Auditors check whether the treatment plan reflects the current risk landscape. A plan that references risks from two years ago without updates suggests treatment is not an active process.

Common mistakes to avoid

Treatment plans that never get implemented. The most damaging pattern. Organizations create detailed treatment plans during certification preparation but fail to follow through. By the first surveillance audit, auditors find treatment actions still marked “in progress” with original deadlines long passed.

No evidence of implementation. Controls may be in place, but without documented evidence, auditors cannot verify it. If you deployed MFA six months ago but kept no rollout records - no configuration evidence, no enrollment data, no change management record - the implementation is unverifiable.

Risk owners who do not own their risks. Assigning all risks to the ISMS manager defeats the purpose. Risk owners should have operational authority over the affected area. The engineering lead owns technology risks, the HR manager owns people risks. The ISMS manager coordinates, but ownership sits with the business.

Treating risk treatment as a one-time event. Risk treatment is ongoing. New risks emerge from each assessment cycle, existing treatments need effectiveness checks, and threats evolve. Build treatment review into your regular management review cycle.

Disconnecting treatment from the SoA. If your SoA declares 80 controls applicable but your treatment plan only addresses 15 risks, the mapping is incomplete. Every applicable control should connect to at least one risk, or auditors question the basis for control selection.

How 27kay can help

We help organizations turn risk treatment plans into implemented controls with proper evidence. As part of ISO 27001 implementation, we build the treatment tracker, establish the evidence framework, facilitate risk owner acceptance, and ensure full traceability from risks to controls. For the full picture, see our ISO 27001 knowledge hub.

Struggling with treatment plan implementation or preparing for a surveillance audit? Get in touch - we will review your treatment status and help you close open items before your auditor does.