Information Security Risk Treatment and Risk Owners

Information Security Risk Treatment and Risk Owners (ISO/IEC 27001 Clause 6.1.3 and 8.3): A Lead Auditor Guide

Introduction
Risk treatment is where an Information Security Management System (ISMS) turns analysis into action. After risks have been identified, analysed and evaluated (Clause 6.1.2), the organization must decide what to do about them, select controls, document its decisions and obtain approval from the people accountable for those risks, known as risk owners. For an ISO/IEC 27001 Lead Auditor, this is one of the most heavily tested topics. It links the risk assessment, Annex A, the Statement of Applicability (SoA), the risk treatment plan and operational implementation into one auditable chain.

1. Why Risk Treatment and Risk Owners Are Important
It is the core of a risk-based ISMS. ISO/IEC 27001 does not require every control in Annex A. It requires controls that are necessary to treat identified risks. Risk treatment is the mechanism that justifies which controls exist and why.
It creates accountability. Without named risk owners, risks drift. Nobody approves residual risk and nobody is responsible when controls fail. Risk owners make risk decisions visible and assign them to people with real authority.
It links management decisions to the business. Accepting residual risk is a business decision, not a purely technical one. Risk owner approval ensures that informed people consciously accept the remaining exposure.
It produces key mandatory documented information. The SoA and the risk treatment process and its results are required evidence. Certification auditors rely on them to understand scope, control selection and exclusions.
It is a frequent source of nonconformities. Common audit findings include an SoA that does not match the risk assessment, exclusions without justification, treatment plans with no owners or deadlines, and residual risks never formally accepted.

2. What It Is: Key Definitions
Risk treatment: the process of selecting and implementing options to modify, or otherwise address, information security risk.
Risk owner: per ISO/IEC 27000, a person or entity with the accountability and authority to manage a risk. This is not necessarily the asset owner, although it often is the same person. The important qualities are accountability and authority, for example the authority to allocate budget or accept risk.
Residual risk: the risk remaining after risk treatment.
Control: a measure that maintains and/or modifies risk.
Statement of Applicability (SoA): documented information listing the necessary controls, the justification for including them, whether they are implemented, and the justification for excluding any Annex A controls.
Risk treatment plan (RTP): a plan describing how the selected treatment options and controls will be implemented, typically including actions, responsibilities, resources, timescales and how results will be evaluated.

3. Where It Sits in the Standard
Clause 6.1.1: general actions to address risks and opportunities.
Clause 6.1.2: information security risk assessment. Item c) 2) requires the organization to identify the risk owners.
Clause 6.1.3: information security risk treatment. This is the main requirement.
Clause 8.2: perform risk assessments at planned intervals or when significant changes occur.
Clause 8.3: implement the risk treatment plan and retain documented information of the results.
Clause 9 and 10: monitor effectiveness, review in management review, and correct and improve.
Annex A: the reference control set. In the 2022 edition it contains 93 controls in four themes: organizational (37), people (8), physical (14) and technological (34).
ISO/IEC 27005: guidance on information security risk management. It is useful but not auditable as requirements.
ISO/IEC 27002: implementation guidance for Annex A controls.

4. How It Works: Clause 6.1.3 Step by Step
The organization must define and apply an information security risk treatment process to:
a) Select appropriate risk treatment options, taking the risk assessment results into account.
b) Determine all controls necessary to implement the chosen options. Controls may come from Annex A or from any other source, including sector frameworks or the organization's own design.
c) Compare the controls determined in b) with Annex A and verify that no necessary controls have been omitted. Annex A is a cross-check, not a starting checklist. The 2022 notes clarify that Annex A is not exhaustive and additional controls may be needed.
d) Produce a Statement of Applicability containing the necessary controls, the justification for their inclusion, whether they are implemented or not, and the justification for excluding any Annex A controls.
e) Formulate an information security risk treatment plan.
f) Obtain risk owners' approval of the risk treatment plan and acceptance of the residual information security risks.
The organization must retain documented information about the risk treatment process.

5. Risk Treatment Options
ISO/IEC 27005 describes four main options:
Risk modification (reduce or mitigate): apply controls to lower likelihood and/or impact, for example adding MFA, encryption or training.
Risk retention (accept): knowingly retain the risk, typically because it falls within the risk acceptance criteria or treatment cost outweighs benefit. This must be an informed decision by the risk owner.
Risk avoidance: stop or change the activity that creates the risk, for example discontinuing an insecure legacy service.
Risk sharing (transfer): share the risk with another party, for example through insurance or outsourcing. Accountability cannot be transferred. The organization remains responsible for its information security, and sharing may introduce new risks, such as supplier risk, that must be assessed.
Options are not mutually exclusive. A single risk may be partly reduced and partly shared, with the remainder retained.

6. The Statement of Applicability in Practice
A good SoA allows an auditor to trace each control back to risk treatment decisions and, where relevant, legal, regulatory, contractual or business requirements.
Typical SoA columns: control reference and name, applicable (yes/no), justification for inclusion (for example the linked risk IDs or a legal requirement), implementation status, justification for exclusion, and reference to the relevant policy or procedure.
Exclusions: an Annex A control may be excluded only if it is not needed to treat any identified risk and is not required by other obligations. 'Not applicable because we don't want it' is not a justification. A valid example is excluding secure development controls in an organization that genuinely does no software development and has no such activity in scope. Even then, the auditor should verify that outsourced development is not happening.
Implementation status: the SoA must state whether each included control is implemented. A control can be applicable but not yet implemented if the risk treatment plan covers it.
Version control: the SoA is referenced in the certification scope, so its version matters.

7. The Risk Treatment Plan in Practice
The standard does not prescribe a format, but an effective RTP normally answers: what will be done, what resources are required, who is responsible, when it will be completed and how results will be evaluated. This mirrors the planning expectations of Clause 6.2 for objectives. The RTP may be a separate document, integrated into the risk register or held in a project tool, as long as it exists as documented information and is approved by risk owners.

8. The Role of Risk Owners
Identified during risk assessment (6.1.2 c) 2)). Every risk should have an owner.
Approve the treatment plan (6.1.3 f)). The owner agrees that the proposed actions are appropriate.
Accept residual risk (6.1.3 f)). The owner formally acknowledges what remains after treatment and confirms it is acceptable against the risk acceptance criteria established in 6.1.2 a).
Monitor and review. Owners should be involved when risk levels change, when treatment is delayed or when incidents reveal ineffective controls.
Appropriate seniority. The owner must have the authority to commit resources and accept the risk. A junior system administrator accepting a high enterprise-wide risk is a red flag. Many organizations escalate acceptance authority according to risk level, for example the CISO for medium risks and the executive board for high risks.
Risk owner versus asset owner: an asset owner is responsible for an asset's protection throughout its lifecycle. A risk owner is accountable for a risk, which may span multiple assets. They may be the same person but do not have to be.
Risk owner versus control owner: a control owner operates or maintains a specific control. The risk owner relies on controls and is accountable for the overall risk outcome.

9. Implementation: Clause 8.3
Planning is not enough. Clause 8.3 requires the organization to implement the risk treatment plan and retain documented information of the results of risk treatment. Auditors therefore look for evidence that planned actions were completed, such as change records, configuration evidence, training records and updated risk ratings, and that the risk register reflects the post-treatment situation.

10. How a Lead Auditor Audits Risk Treatment
Review documentation: risk treatment methodology, risk register, SoA and RTP.
Trace samples both ways:
- From risk to control: pick high risks from the register, check that the chosen option is documented, controls are listed in the SoA, actions appear in the RTP and evidence of implementation exists.
- From control to risk: pick SoA controls, especially exclusions, and check the justification and link to risks or requirements.
Verify risk owner approval: look for signatures, workflow approvals, meeting minutes or system records showing approval of the RTP and acceptance of residual risk. Check that the approver had suitable authority.
Check consistency with acceptance criteria: residual risks above the acceptance threshold should not be retained without documented, authorized justification.
Interview risk owners: do they know they own the risk? Do they understand the residual risk they accepted? Lack of awareness suggests approval was a formality.
Check implementation status: overdue RTP actions without re-evaluation or re-approval may indicate an ineffective process.
Check linkage to management review: Clause 9.3 requires consideration of risk assessment results and the status of the risk treatment plan.

11. Typical Nonconformities
- Annex A controls excluded with no justification or a weak justification (6.1.3 d)).
- SoA states controls are implemented, but no evidence exists in operation (6.1.3 d) and 8.3).
- Annex A used as a starting checklist with no link to identified risks. This may mean controls are not determined from risk treatment (6.1.3 b)).
- No risk owner assigned to some risks (6.1.2 c) 2)).
- No evidence of risk owner approval of the RTP or acceptance of residual risk (6.1.3 f)).
- Residual risks exceed acceptance criteria with no authorized decision.
- RTP lacks responsibilities, timescales or resources, so implementation cannot be verified.
- Risk treatment results not retained as documented information (8.3).
- Outsourcing treated as having transferred all responsibility, with no supplier controls (risk sharing misunderstood; links to A.5.19 to A.5.23).
Grading: a single missing approval for a low risk may be a minor nonconformity. A systemic absence of risk owner approval, or an SoA disconnected from risk assessment, may indicate a breakdown of the risk treatment process and could be graded major.

12. Worked Example
A company identifies the risk of customer data leakage through lost laptops. The risk owner is the Head of Sales, who is accountable for the customer pipeline and holds budget authority. Inherent risk is rated high. The treatment option is modify: full-disk encryption (A.8.24 use of cryptography), endpoint management (A.8.1 user endpoint devices) and awareness training (A.6.3). Residual risk is rated low, within acceptance criteria. The RTP assigns IT to deploy encryption within 60 days. The Head of Sales signs off the plan and accepts the residual risk. The SoA lists the three controls with justification referencing this risk ID. The auditor samples five laptops and confirms encryption is active, providing 8.3 evidence.

13. Exam Tips: Answering Questions on Information Security Risk Treatment and Risk Owners
Tip 1: Know the six items of 6.1.3 in order. Select options, determine controls, compare with Annex A, produce the SoA, formulate the RTP, and obtain risk owner approval and residual risk acceptance. Many questions test one specific item.
Tip 2: Annex A is a cross-check, not a mandatory list. If an answer option says all 93 Annex A controls must be implemented, it is wrong. Controls are required only when necessary to treat risk or meet other obligations.
Tip 3: Remember the four SoA elements. Necessary controls, justification for inclusion, whether implemented, and justification for exclusion. Questions often hide a missing element.
Tip 4: Risk owners approve the plan and accept residual risk. Not top management in general, not the ISMS manager by default, and not the auditor. If a question asks who accepts residual risk, the answer according to the standard is the risk owner.
Tip 5: Authority matters. In scenario questions, check whether the person accepting risk truly has the accountability and authority. A junior employee accepting a critical risk is a likely finding.
Tip 6: Accountability cannot be transferred. Insurance or outsourcing shares risk but does not remove the organization's responsibility. Choose answers recognizing new supplier risks.
Tip 7: Distinguish 6.1.3 from 8.3. Planning and deciding are in Clause 6.1.3. Doing and retaining results are in Clause 8.3. When a scenario shows a good plan but no implementation evidence, cite 8.3.
Tip 8: Distinguish 6.1.2 from 6.1.3. Identifying risk owners, setting acceptance criteria and analysing risks fall under 6.1.2. Treatment decisions and approval fall under 6.1.3. Cite the correct clause in nonconformity statements.
Tip 9: Write nonconformities in the proper structure. State the requirement (for example 'ISO/IEC 27001:2022 Clause 6.1.3 f) requires the organization to obtain risk owners' approval of the risk treatment plan and acceptance of residual risks'), the evidence observed (for example 'three of eight sampled high risks in risk register v2.3 had no recorded approval') and the nonconformity statement. Keep it factual, objective and traceable.
Tip 10: Use audit trails in your answers. When asked how you would audit treatment, describe sampling, tracing risks to the SoA and RTP and implementation evidence, tracing exclusions back to justification, and interviewing risk owners. Examiners reward a methodical approach.
Tip 11: Watch for absolute words. 'Must always', 'never', 'all controls' and 'only Annex A' are usually incorrect in risk treatment questions because ISO/IEC 27001 is flexible and risk-based.
Tip 12: Accepting risk is legitimate. Retaining a risk is a valid option when it meets acceptance criteria and is approved by the risk owner. Do not assume every risk must be reduced.
Tip 13: Know what is not required. The standard does not mandate a specific methodology, format for the RTP, risk scoring scale or software tool. Answers claiming ISO/IEC 27005 is mandatory for certification are incorrect, since it is guidance.
Tip 14: Connect to management review. The status of the risk treatment plan and risk assessment results are management review inputs (9.3). This link is a common multiple-choice or essay point.
Tip 15: Grade findings sensibly. Isolated lapses are usually minor. A systemic failure, such as no residual risk acceptance anywhere or an SoA unrelated to risk assessment, suggests the process is not achieving its intended outcome and may be major. Justify your grading with evidence.

Summary
Risk treatment converts risk assessment into concrete, justified controls. The SoA documents control decisions, the risk treatment plan describes how those decisions will be implemented, and risk owners, the people with accountability and authority, approve the plan and accept what remains. Clause 8.3 ensures the plan is actually carried out. As a Lead Auditor, your job is to verify the traceable chain from risk to option to control to SoA to plan to approval to implementation evidence. In the exam, anchor every answer to the correct clause, remember that Annex A is a cross-check, and always ask: who owns this risk, did they approve it, and is there evidence?