ISO 27001 Clause 6.1.3 Information Security Risk Treatment: The Lead Auditor’s Implementation and Audit Guide

ISO 27001 Clause 6.1.3 is a security control that mandates the definition and application of an information security risk treatment process. Its primary implementation requirement is to select appropriate treatment options and verify them against Annex A controls. The business benefit is ensuring that all identified risks are modified, retained, or avoided to match the organizational risk appetite.

In this guide, I will show you exactly how to implement ISO 27001 Clause 6.1.3 and ensure you pass your audit. You will get a complete walkthrough of the control, practical implementation examples, and access to the ISO 27001 templates and toolkit that make compliance easy.

I am Stuart Barker, an ISO 27001 Lead Auditor with over 30 years of experience conducting hundreds of audits. I will cut through the jargon to show you exactly what changed in the 2022 update and provide you with plain-English advice to get you certified.

ISO 27001 Information Security Risk Treatment

The ISO 27001 standard is a risk based management system that requires an organisation to select appropriate risk treatment options based on the risk assessment results.

What is ISO 27001 Clause 6.1.3?

This clause is all about risk treatment.

The ISO 27001 standard for ISO 27001 certification wants you define and implement a risk assessment process and to treat those risks appropriately.

It is, after all, a risk based management system. Not a rule based system.

That risk treatment process has to set out risk criteria which are the parameters of your risk management.

Definition

The organization shall define and apply an information security risk treatment process to:

select appropriate information security risk treatment options, taking account of the risk assessment results;

determine all controls that are necessary to implement the information security risk treatment option(s) chosen;

compare the controls determined with those in Annex A and verify that no necessary controls have been omitted;

produce a Statement of Applicability that contains the necessary controls justification for their inclusion; whether the necessary controls are implemented or not; and the justification for excluding any of the Annex A controls.

formulate an information security risk treatment plan; and

obtain risk owners’ approval of the information security risk treatment plan and acceptance of the residual information security risks.

The organization The organization shall retain documented information about the information security risk treatment process.

What are the ISO 27001:2022 Changes to Clause 6.1.3?

The changes to ISO 27001 Clause 6.1.3 are minor but important

• Changing the wording of 6.1.3 c to now reference Annex A as containing a list of possible information security controls. This is a change from it containing a comprehensive list of control objectives.
• Removing the wording that control objectives are implicitly included in the controls chosen. Changing from the control objectives listed in Annex A as being not exhaustive with additional controls may being needed to the wording of Information Security Controls listed in Annex. Change the word control objectives to controls.
• Changing the sentence of 6.1.3 d into a list for ease of reading
• Changing the words ‘International Standard’ to the word ‘document’

Overall these are clarification changes and not material.

Watch the ISO 27001 Clause 6.1.3 Video Tutorial

ISO 27001 Clause 6.1.3 Implementation Guidance

Risk Treatment Options

You are expected to select appropriate information security risk treatment options, taking account of the risk assessment results.

Risk treatment options can include

• accepting the risk
• treating the risk
• mitigating the risk
• transfer the risk
• avoiding the risk

Risk Controls

Risk controls where required as necessary are identified and the information security risk treatment option(s) is chosen. A great place to identify what those controls are is in the Statement of Applicability ( SOA ). This is the list of ISO 27002 / Annex A controls that apply to you. Of course if you have not defined your Statement of Applicability yet then you can choose directly from the ISO 27002 / Annex A control list.

Of course there may be additional controls that you want to consider but the ISO 27001 standard and the provided list of Annex A controls is designed specifically as a common sense set of controls. It therefore makes perfect sense to you that list of controls as the controls you will use to mitigate risk. It also helps with your ISO 27001 certification by staying on point.

You will compare the controls determined in 6.1.3 above with those in ISO 27001 Annex A and verify that no necessary controls have been omitted.

Statement of Applicability (SOA)

It is down to you to produce a Statement of Applicability that contains the necessary controls and justification for inclusions, whether they are implemented or not, and the justification for exclusions of controls from Annex A.

As mentioned the Statement of Applicability is not a particular difficult or complex document. Moreover it is just a list of controls with a date they were assessed and if they are not applicable why not. Don’t over think it.

Risk Treatment Plan

Once you have decided on what your risk treatment will be then you need a plan to address it.

For risks that you accept you will want to update the risk register and then minute that you accepted the risks at an appropriate Management Review Team Meeting.

For other risks you will formulate a plan. The plan will include what you will do, who will do it, when they will do and a check of the results.

Once the risk treatment has completed you will then risk assess again using the new controls in place. This gives you what is called Residual Risk. All of this is documented in the risk register.

Risk Treatment Approval

Risk owners will approve the risk treatment plan and the acceptance of the residual information security risks. This will also be shared at the next Management Review Team meeting and agreed and minuted.

How to implement ISO 27001 Clause 6.1.3

To implement ISO 27001 Clause 6.1.3 effectively, organisations must transition from identifying risks to executing a formalised treatment strategy that aligns with their risk appetite and business objectives. This process ensures that every security threat is met with a proportionate response, leveraging the Annex A control framework to maintain a robust security posture.

Categorise Risk Treatment Strategies

Analyse the results of the risk assessment to determine the most effective treatment path for every identified threat within the Asset Register. This phase ensures that resources are prioritised for high-impact vulnerabilities:

• Select Risk Modification to implement security controls that reduce the likelihood or impact of a threat.
• Opt for Risk Avoidance by withdrawing from activities that create unacceptable levels of exposure.
• Utilise Risk Sharing through insurance or third-party outsourcing to distribute the financial or operational burden.
• Apply Risk Retention for low-level threats that fall within the defined organisational risk appetite.

Provision Technical Controls via Annex A

Map every risk requiring modification to the specific security measures outlined in Annex A to ensure comprehensive mitigation. This step creates a direct link between identified vulnerabilities and technical safeguards:

• Provision Multi-Factor Authentication (MFA) to mitigate risks associated with unauthorised access or credential theft.
• Configure granular Identity and Access Management (IAM) roles to enforce the principle of least privilege across all systems.
• Deploy encryption and data masking to protect sensitive information assets at rest and in transit.
• Audit existing configurations against the ISO 27002 guidance to verify that chosen controls meet international best practices.

Formalise the Statement of Applicability (SoA)

Produce a definitive document that lists all necessary controls and provides a clear justification for their inclusion or exclusion. The SoA serves as the primary evidence for auditors during the certification process:

• Document the implementation status of every control to provide a real-time view of the security landscape.
• Justify the exclusion of any Annex A controls by providing evidence that the associated risk is not applicable to the environment.
• Link every selected control back to a specific risk entry to demonstrate a requirement-led security strategy.
• Maintain the SoA as a living document that is updated following every significant change to the risk assessment.

Formulate a Managed Risk Treatment Plan

Develop a structured roadmap that outlines the specific actions, resources, and timelines required to implement the chosen treatment options. This plan ensures accountability and provides a framework for progress tracking:

• Assign specific responsibilities to risk owners and technical leads for the deployment of new security measures.
• Establish a ROE (Rules of Engagement) document to define how security changes will be tested and implemented without disrupting operations.
• Allocate necessary budget and human resources to ensure that the treatment plan remains on schedule.
• Define clear success criteria for every action to allow for the verification of risk reduction.

Authorise Residual Risk Levels

Obtain formal approval from risk owners to validate the proposed treatment plan and accept any remaining risks. This step ensures that senior management remains accountable for the organisation’s security posture:

• Present the projected residual risk levels to stakeholders to ensure they understand the remaining exposure after treatment.
• Formalise the acceptance of residual risks through signed documentation or minuted management reviews.
• Verify that all accepted risks align with the pre-defined risk criteria and organisational thresholds.
• Revoke or revise treatment plans that do not reduce risk to an acceptable level for the business.

ISO 27001 Clause 6.1.3 Implementation Checklist

Information Security Risk Treatment ISO 27001 Clause 6.1.3 Implementation Checklist

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           

ISO 27001 Clause 6.1.3 Information Security Risk Treatment: Challenges and Solutions

Risk Treatment Step	Requirement & Description	Common Challenge	Implementation Solution
1. Identify Options	Determine appropriate actions to address risks (mitigation, transfer, avoidance, or acceptance).	Choosing cost-effective options and assessing feasibility.	Conduct cost-benefit analyses and involve relevant interested parties.
2. Select Options	Choose suitable treatments based on cost, feasibility, and organisational context.	Balancing security needs with business requirements and prioritising risks.	Establish clear selection criteria and document the rationale for choices.
3. Prepare Plan	Develop a detailed plan including actions, responsibilities, timelines, and resources.	Defining measurable actions or facing resource/expertise shortages.	Break down complex tasks and secure necessary expertise and resources.
4. Implement Plan	Execute planned actions to implement the chosen risk treatment options.	Employee resistance to change and cross-departmental coordination.	Provide training, support, and establish clear communication channels.
5. Monitor & Review	Regularly monitor effectiveness to ensure objectives are being achieved.	Measuring effectiveness and a lack of clear performance indicators.	Define clear metrics and conduct regular security assessments.
6. Document Decisions	Maintain records of decisions, rationale, plans, and monitoring results.	Keeping documentation up-to-date and integrated with ISMS processes.	Use a centralised risk management system for regular updates.
7. Communicate Info	Communicate risk information to management, employees, and external parties.	Communicating technical info to non-technical audiences.	Tailor communication using visual aids and plain language.
8. Accept Residual Risk	Formally acknowledge and accept risks remaining after treatment.	Determining acceptable levels and gaining management buy-in.	Establish risk acceptance criteria and obtain formal management approval.
9. Maintain & Update	Review treatments to reflect changes in threats and the business environment.	Resource constraints for regular reviews and updates.	Schedule regular reviews and integrate with change management.
10. Continuous Improvement	Identify opportunities to improve process effectiveness and efficiency.	Lack of time for initiatives and measuring improvement impact.	Prioritise initiatives by impact and establish measurement metrics.

ISO 27001 Clause 6.1.3 Audit Checklist

The following is a summary of How to audit ISO 27001 Clause 6.1 and covers the Information Security Risk Treatment ISO 27001 Clause 6.1.3 Audit Checklist

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       

ISO 27001 Clause 6.1.3 Information Security Risk Treatment Audit Checklist

Audit Step	Audit Objective & Requirement	Audit Techniques
1. Risk Treatment Options	Verify that the organisation has a process for identifying appropriate risk treatment options (modification, transfer, avoidance, acceptance).	Document review (policies, procedures), interviews with risk management personnel, review of past risk treatment decisions and their rationale, walkthrough of a risk treatment identification process.
2. Treatment Selection	Ensure the organisation has criteria for selecting risk treatment options, considering factors like cost, feasibility, and business objectives.	Document review (risk acceptance criteria, cost-benefit analysis templates), interviews with decision-makers, examination of selected risk treatments and their justification.
3. Risk Treatment Plans	Verify the existence and completeness of risk treatment plans, including specific actions, responsibilities, timelines, and resources.	Document review (risk treatment plans, project plans), interviews with project managers and responsible parties, review of resource allocation documentation.
4. Implementation	Confirm that risk treatment plans have been implemented as documented.	Document review (implementation records, change management logs), observation of processes, interviews with staff, testing of implemented controls.
5. Monitoring & Review	Verify the organisation monitors the effectiveness of implemented risk treatments and reviews them regularly.	Review of performance data (incident rates, vulnerability scans), interviews with staff, review of management review outputs.
6. Documentation	Inspect records of risk treatment decisions, chosen options, rationale, implementation plans, and monitoring results.	Document review (risk register, risk treatment reports), data analysis of trends, sampling of risk treatment records for detailed review.
7. Communication	Verify that risk treatment information is communicated to relevant stakeholders.	Interviews with stakeholders, review of communication logs and meeting minutes, analysis of stakeholder feedback mechanisms.
8. Residual Risk Acceptance	Confirm that residual risks (risks remaining after treatment) are formally accepted by management.	Review of risk acceptance documentation, interviews with management, examination of residual risk levels and justification.
9. Maintenance & Updates	Verify that risk treatments are regularly reviewed and updated to reflect changes in the threat landscape.	Review of risk treatment update schedule, interviews with personnel, review of change management records and threat intelligence.
10. Continuous Improvement	Verify that the organisation seeks opportunities to improve the effectiveness and efficiency of risk treatment processes.	Interviews with personnel, review of process improvement initiatives, analysis of metrics, and benchmarking.

What an auditor looks for ISO 27001 Clause 6.1.3

What the Auditor Looks For	Audit Objective	Examples of Evidence
Risk Treatment Selection	Evidence that the organisation has selected a specific treatment (Treat, Transfer, Avoid, Accept) for every risk.	A Risk Register with a “Treatment Option” column mapped to every identified risk with a score above the appetite threshold.
Consistency with Annex A	Verification that the controls chosen are compared against the 93 controls in Annex A (ISO 27001:2022).	A cross-reference table showing how a treatment (e.g., “Secure Remote Access”) maps to Annex A 5.37 and 8.1.
Statement of Applicability (SoA)	A complete list of Annex A controls, showing which are included/excluded and the justification for both.	A formal SoA document. If “Physical Security” is excluded, the auditor looks for a justification like “We are a 100% remote company with no physical office.”
Risk Treatment Plan (RTP)	A project plan for implementing controls, including timelines, responsibilities, and status.	An Excel or Project sheet showing: “Implement MFA – Assigned to IT Manager – Deadline: Q3 – Status: In Progress.”
Risk Owner Approval	Proof that the people responsible for the budget/impact have formally accepted the residual risk.	Meeting minutes or signed “Risk Acceptance” forms from Department Heads or the CEO.
Residual Risk Levels	Evidence that the organisation calculated the risk level after treatment to ensure it is acceptable.	A “Pre-Treatment Score” vs. a “Post-Treatment Score” in the Risk Register (e.g., 25/25 reduced to 5/25).

Applicability of ISO 27001 Clause 6.1.3 across different business models.

                                                                                                                                                                                                   

Business Type	Applicability	Why It Is Important	Risk Treatment Examples
Small Business	High; focuses on protecting core client data and maintaining basic business continuity.	Prevents catastrophic financial loss from simple threats like phishing or hardware failure where resources are limited.	Implementing basic MFA (Treat), offloading payment processing to a third-party gateway (Transfer), and maintaining offline backups.
Tech Startups	Critical; necessary for building trust with enterprise clients and securing VC funding.	Demonstrates to high-value customers that their data is being handled with professional-grade security controls early in the lifecycle.	Automated CI/CD security scanning (Treat), formalising intellectual property access logs, and choosing SOC2-compliant cloud providers.
AI Companies	Essential; covers specific risks related to training data integrity and model poisoning.	Protects the high-value proprietary models and ensures compliance with evolving regulations like the EU AI Act.	Encrypting massive training datasets (Treat), rigorous input validation to prevent prompt injection (Treat), and model versioning controls.

Fast track ISO 27001 Clause 6.1.3 compliance with the ISO 27001 Toolkit

When dealing with Clause 6.1.3 (Risk Treatment), the last thing you want is your Risk Treatment Plan (RTP) or Statement of Applicability (SoA) trapped behind a SaaS paywall when an auditor walks through the door. Using the ISO 27001 Toolkit keeps you in the driver’s seat. Here is the breakdown of why local ownership beats the subscription model for managing your risk treatment.

Comparison of ISO 27001 Toolkit vs. SaaS for Clause 6.1.3 Risk Treatment

Feature / Argument	HighTable ISO 27001 Toolkit	Online SaaS Platform
Data Ownership	Permanent Ownership. You own the Word and Excel files forever. Your risk data stays on your infrastructure.	Data Rental. Your data lives on their servers. If you stop paying the monthly fee, you lose access to your compliance records.
Operational Simplicity	Zero Learning Curve. Uses familiar tools like Microsoft Excel. No need for staff training on proprietary interfaces.	Complex Onboarding. Requires time-consuming training for the team to navigate specific software workflows.
Cost Efficiency	Single One-Off Fee. Transparent pricing with no recurring monthly overheads or “per-user” seats.	Compounding Subscriptions. Expensive monthly or annual fees that increase as your team grows.
Vendor Freedom	No Lock-in. You aren’t tied to a specific provider. You can move, edit, or archive your files as you see fit.	Heavy Lock-in. Exporting data out of a SaaS into a format an auditor likes can be technically difficult and restrictive.
Clause 6.1.3 Focus	Direct Customisation. Easily map Annex A controls to your Risk Treatment Plan (RTP) without software constraints.	Rigid Workflows. You are forced to follow the software’s specific logic, which may not align with your unique business risks.

Top 3 ISO 27001 Clause 6.1.3 Mistakes and How to Fix Them

Common Mistake	Why It Fails Audit	The Technical Fix	Real-World Example
Generic Treatment Descriptions	Clause 6.1.3 requires “specific” actions. Auditors reject vague statements like “We will use security software” as they aren’t measurable or assignable.	Define the exact control, the owner, and the implementation deadline within a formal Risk Treatment Plan (RTP).	Mistake: “Improve password security.” Fix: “Enforce 14-character minimum and MFA via Azure AD for all staff. Owner: IT Lead. Deadline: 31/03/2026.”
The “SoA Gap”	Clause 6.1.3(c) and (d) require a comparison with Annex A. Companies often select treatments but forget to cross-reference them against the 93 Annex A controls.	Map every risk treatment directly to one or more Annex A controls. Use your Statement of Applicability (SoA) as the primary verification tool.	Mistake: Treating a data breach risk but not linking it to Annex A 8.12 (Data Leakage Prevention). Fix: Explicitly mapping your DLP tool implementation to Annex A 8.12 in your SoA.
Lack of Risk Owner Sign-off	Clause 6.1.3(f) mandates that “Risk Owners” must approve the residual risk. Auditors often find that IT Managers are “accepting” risks they don’t have the authority to hold.	Ensure the person with the budget and accountability (e.g., CEO, COO, or Dept Head) provides a documented sign-off on all residual risks.	Mistake: The System Admin accepts the risk of an unpatched legacy server. Fix: The Head of Operations signs a Risk Acceptance Form acknowledging the uptime vs. security trade-off.

ISO 27001 Templates

Implementing ISO 27001 can be a significant undertaking and incur significant ISO 27001 Costs. To streamline the process and potentially save valuable time and resources, consider utilising pre-written ISO 27001 templates. This ISO 27001 Toolkit offers a comprehensive set of resources specifically designed for those seeking to achieve ISO 27001 certification independently. With this toolkit, you can potentially build your Information Security Management System (ISMS) within a week and be ready for certification within 30 days.

These individual templates help meet the specific requirements of ISO 27001 clause 6.1.3.

How ISO 27005 Supports Clause 6.1.3

Think of ISO 27001 as the “Project Manager” that defines what must be done, and ISO 27005 as the “Technical Specialist” who explains how to execute the risk treatment process.

Mapping: Requirements vs. Guidance

ISO 27001 Clause	Requirement Summary	ISO 27005 Reference	Practical Guidance
6.1.3 a)	Formulate a Risk Treatment Plan	Section 9.1	Strategic guidance on the four treatment options: Avoid, Modify, Share, or Retain.
6.1.3 b)	Determine necessary controls	Section 9.2	How to select controls based on the level of risk reduction required.
6.1.3 c)	Compare with Annex A	Annex A & G	Ensuring comprehensive coverage and alignment with the ISO 27002 framework.
6.1.3 d)	Produce a Statement of Applicability	Section 9.1 & Annexes	Methodology for justifying the inclusion and exclusion of controls.
6.1.3 e) & f)	Risk Owner approval/authorization	Section 9.3 & 9.4	Framework for evaluating and formally accepting “Residual Risk.”

How ISO 27005 Supports Implementation

1. Defining treatment strategies

ISO 27005 expands on the requirement to “select options” by providing the criteria for Risk Sharing (e.g., insurance) and Risk Avoidance, ensuring you don’t default to “Modification” (buying tools) for every single issue.

2. The Mechanics of Control Selection

It provides a structured Information Security Risk Treatment (ISRT) process. This helps balance the cost of implementation against the expected reduction in risk, preventing over-expenditure on low-value assets.

3. Managing Residual Risk

Clause 6.1.3 requires owner approval of residual risk. ISO 27005 provides the math and logic for this by quantifying:

• Initial Risk Level
• Control Effectiveness
• Residual Risk: The actual level of threat the business is signing off on.

Peer Note: Many organizations fail audits because they treat risk treatment as a one-time document. ISO 27005 turns this into a lifecycle, reminding you that as technology or threats change, the treatment plan must be re-evaluated.    

Mapping ISO 27001 Clause 6.1.3 to ISO 27005 Guidance

ISO 27001 Clause	Requirement Summary	ISO 27005 (Guidance Reference)	Practical Application / Guidance
6.1.3 a)	Formulate an information security risk treatment plan.	Section 9.1 (Risk Treatment Plan)	Guidance on selecting treatment options: Avoid, Modify, Share, or Retain.
6.1.3 b)	Determine all controls necessary to implement risk treatment.	Section 9.2 (Selection of Controls)	How to use Annex A or other sets of controls to mitigate identified risks to an acceptable level.
6.1.3 c)	Compare controls with those in Annex A.	Annex A & G (Control Selection)	Ensuring no necessary controls are omitted; cross-referencing with the ISO 27002 framework.
6.1.3 d)	Produce a Statement of Applicability (SoA).	Section 9.1 & Annexes	Documenting the justification for inclusions and exclusions of controls based on the risk assessment.
6.1.3 e)	Obtain risk owners’ approval of the risk treatment plan.	Section 9.3 (Risk Acceptance)	Guidance on how risk owners should evaluate residual risk and formally accept it.
6.1.3 f)	Obtain risk owners’ authorization for residual risks.	Section 9.4 (Residual Risk)	Ensuring the remaining risk after treatment aligns with the organization’s risk acceptance criteria.

ISO 27001 Clause 6.1.3 related controls

To satisfy the requirements of ISO 27001 Clause 6.1.3, organisations must map their identified risks to specific controls from Annex A. These controls serve as the practical mechanism for “Risk Modification,” providing the technical and organisational safeguards necessary to reduce risks to an acceptable level.

Governance and Organisational Controls

These controls establish the framework for risk treatment, ensuring that security objectives are aligned with business operations and legal mandates:

• ISO 27001 Annex A 5.1 Policies for Information Security: Defines the management’s direction and support for information security in accordance with business requirements.
• ISO 27001 Annex A 5.8 Information Security in Project Management: Ensures that risk treatment is integrated into the project lifecycle from the outset.
• ISO 27001 Annex A 5.31 Legal, Statutory, Regulatory, and Contractual Requirements: Validates that the chosen risk treatment options comply with relevant legislation and international standards.

Access and Identity Controls

Access management is a primary treatment strategy for mitigating risks related to data breaches and internal threats:

• ISO 27001 Annex A 8.2 Privileged Access Rights: Restricts the allocation and use of privileged access rights to mitigate the risk of administrative account abuse.
• ISO 27001 Annex A 8.3 Information Access Restriction: Controls access to information and application functions in accordance with the defined topic-specific policy on access control.
• ISO 27001 Annex A 8.5 Secure Authentication: Provisions robust authentication techniques, such as Multi-Factor Authentication (MFA), to reduce the risk of unauthorised system entry.

Technical Information Security Controls

These controls provide technical “Modification” strategies to protect the integrity and confidentiality of data assets:

• ISO 27001 Annex A 8.11 Data Masking: Utilised as a treatment for protecting sensitive data in testing or development environments.
• ISO 27001 Annex A 8.24 Use of Cryptography: Implements encryption to mitigate risks associated with data interception or unauthorised disclosure.
• ISO 27001 Annex A 8.28 Secure Coding: Ensures that software is developed with security principles to reduce the risk of exploitable vulnerabilities in applications.

Operational and Monitoring Controls

When risks are retained or shared, operational controls ensure that the environment is monitored for changes in the threat landscape:

• ISO 27001 Annex A 5.7 Threat Intelligence: Provides information about existing or emerging threats to allow for the dynamic adjustment of the Risk Treatment Plan.
• ISO 27001 Annex A 5.24 Information Security Incident Management: Establishes the procedures needed to respond to risks that manifest as active security incidents.
• ISO 27001 Annex A 8.16 Monitoring Activities: Ensures that systems are audited and monitored to detect anomalies that may indicate a failure in other risk controls.

Every control selected from this list must be formally documented in your Statement of Applicability (SoA). This document must provide a clear justification for why each control was chosen based on the results of your risk assessment, and conversely, why any controls were excluded.

To demonstrate to an auditor that your risk treatment is actually working, you must move beyond “implementing” and into “measuring”. Clause 6.1.3 is only successful if the selected controls are effective. This helps bridge the gap to ISO 27001 Clause 9.1 Monitoring, Measurement, Analysis, Evaluation

Key Performance Indicators for Risk Treatment Effectiveness

KPI Category	Specific Metric	Intent
Control Efficacy	% of Risk Treatment Plan (RTP) actions completed on schedule.	Measures the organisation’s ability to execute its security roadmap.
Residual Risk Drift	Number of risks where residual risk exceeded appetite during review.	Identifies if the chosen controls are failing to keep pace with the threat landscape.
Implementation Coverage	% of assets covered by the chosen “Modification” control (e.g., MFA or Encryption).	Ensures there are no “shadow IT” gaps in your treatment application.
Financial Impact	Comparison of “Cost of Control” vs. “Potential Loss Averted.”	Provides business-level justification for the treatment budget.
Incident Correlation	Frequency of security incidents related to “Retained” risks.	Validates if the decision to “Accept” a risk was based on accurate data.

The Technical Bridge: Mapping Assessment (6.1.2) to Treatment (6.1.3)

This table demonstrates how the outputs of your assessment dictate the mandatory actions in your treatment phase.

Phase: Clause 6.1.2 (Assessment)	The Technical Bridge	Phase: Clause 6.1.3 (Treatment)
Risk Criteria Definition: Defining what “High,” “Medium,” and “Low” look like.	The Threshold: Any risk exceeding the “Acceptance Criteria” must trigger a treatment action.	Option Selection: Determining if you will Modify, Avoid, Share, or Retain based on the gap.
Risk Identification: Creating the Asset Register and identifying vulnerabilities.	Control Mapping: Every identified vulnerability must be paired with an Annex A safeguard.	Control Determination: Selecting specific technical tools (MFA, Encryption, IAM) to close the gap.
Risk Analysis: Calculating the Likelihood x Impact to get a Raw Score.	ROI Calculation: Evaluating if the cost of a control is proportionate to the Raw Score.	Risk Treatment Plan (RTP): Allocating budget, resources, and owners to implement the chosen controls.

How Risk Acceptance Criteria Dictate Control Selection

Your Risk Acceptance Criteria (established in 6.1.2) act as the “Filter” for every decision made in 6.1.3. This ensures consistency and prevents auditors from questioning your logic.

• Below the Threshold (Retention): If the risk assessment score falls within your acceptance criteria, Clause 6.1.3 directs you to “Risk Retention.” No new Annex A controls are required, but the decision must be documented in the SoA.
• Above the Threshold (Modification): If a risk (e.g., Unauthorised Access) exceeds the threshold, Clause 6.1.3 mandates the selection of controls (e.g., Annex A 8.5 Secure Authentication).
• The “Residual Risk” Loop: After selecting controls in 6.1.3, you must re-calculate the score. If the Residual Risk is still above the acceptance criteria defined in 6.1.2, you must return to 6.1.3 and select additional or more robust controls.

Implementation Checklist: Connecting 6.1.2 and 6.1.3

• Sync the Risk Register: Ensure your Risk Register has a column for “Initial Risk Score” (6.1.2) and “Residual Risk Score” (6.1.3).
• Verify SoA Justifications: In your Statement of Applicability, every “Inclusion” should specifically reference a Risk ID from your assessment.
• Executive Alignment: Ensure the Risk Owners approving the treatment plan (6.1.3) are the same stakeholders who defined the acceptance criteria (6.1.2).
• Technical Consistency: Use the same “Likelihood/Impact” scales for both the initial assessment and the post-treatment residual risk calculation to ensure data integrity.

Asset-Based vs. Scenario-Based Treatment

To move beyond a generic ISO 27001 implementation, your Risk Treatment Plan (RTP) must reflect the specific technical landscape of your organisation. Modern auditors are increasingly critical of “one-size-fits-all” security; they expect to see risk treatment strategies that differentiate between Asset-Based and Scenario-Based methodologies.

Understanding the distinction between these two approaches is vital for creating a granular Statement of Applicability (SoA) and a robust Risk Treatment Plan.

Approach	Focus	Audit Expectation	Implementation Example
Asset-Based	Individual hardware, software, or data assets.	Evidence of specific controls for high-value assets (e.g., Customer Database vs. Office Printer).	Encrypting a Production Database (Asset) via Annex A 8.24.
Scenario-Based	Threat events or “stories” (e.g., “What happens if a developer’s laptop is stolen?”).	Evidence of “Defence in Depth” across multiple assets to prevent a specific outcome.	Mitigating a Ransomware Attack (Scenario) by combining MFA, Offline Backups, and EDR.

Treatment Variability: Cloud vs. On-Premise

The selection of controls in Clause 6.1.3 must shift significantly based on where your data lives. Auditors look for this technical nuance to verify that your risk treatment is actually effective for the specific environment.

1. Cloud-Native Risk Treatment

When treating risks in a Cloud (SaaS/IaaS/PaaS) environment, the focus shifts toward Identity and Configuration rather than physical perimeter security.

• Risk Sharing: High use of Risk Sharing via the “Shared Responsibility Model” with providers like AWS or Azure.
• Modification Controls:
  • ISO 27001 Annex A 5.23 (Information Security for Use of Cloud Services): Mandatory inclusion in the SoA to manage vendor-side risk.
  • ISO 27001 Annex A 8.5 (Secure Authentication): Prioritising SSO and Conditional Access policies over hardware tokens.
  • ISO 27001 Annex A 8.12 (Data Leakage Prevention): Using API-based DLP to scan cloud storage buckets (e.g., S3).

2. On-Premise (Legacy) Risk Treatment

For physical infrastructure, risk treatment is anchored in Physical Protection and Hardware Lifecycle.

• Risk Modification:
  • ISO 27001 Annex A 7.1 (Physical Security Perimeters): Critical for server rooms and data centres.
  • ISO 27001 Annex A 8.22 (Segregation of Networks): Implementing VLANs to isolate legacy hardware that cannot support modern encryption.
  • ISO 27001 Annex A 8.19 (Installations of Software on Operational Systems): Strict “Gold Image” controls for local workstations.
• Risk Retention: Occasionally used for end-of-life hardware where the cost of replacement exceeds the current asset value, provided compensatory controls (like network air-gapping) are in place.

Best Practices for Granular Treatment

To satisfy a modern auditor, ensure your Risk Treatment Plan includes the following:

1. Differentiated Justifications: In your SoA, don’t just say “MFA is implemented.” Say: “MFA is implemented for Cloud Apps via Azure AD; Physical access to On-Prem servers is mitigated via Bio-metric controls (Annex A 7.2).”
2. Environment-Specific ROEs: Establish different Rules of Engagement (ROE) for cloud changes (which are often automated/CI/CD) versus on-premise hardware changes (which require physical maintenance windows).
3. Inventory-Linked Treatment: Ensure every risk treatment entry in your register links directly back to a specific unique ID in your Asset Register.

ISO 27001 Clause 6.1.3 FAQ

Further Reading

• How to audit ISO 27001 Clause 6.1

About the author