2.3 Planning, Risk Assessment, and Risk Treatment (Clause 6)

2.3 Planning, Risk Assessment, and Risk Treatment (Clause 6)

Clause 6 forms the analytical engine of ISO/IEC 27001:2022. Rather than prescribing a static list of mandatory security controls for all companies, ISO/IEC 27001 relies on a risk-driven philosophy: controls must be selected and implemented based on a rigorous, repeatable risk assessment tailored to the organization's unique context (Clause 4).

For a Lead Auditor, Clause 6 represents one of the highest-weight audit domains. Auditors must evaluate the establishment of the risk process (6.1.2 and 6.1.3), verify the completeness of the Statement of Applicability (SoA), review security objectives (6.2), and assess structured change management (6.3).

---

1. Information Security Risk Assessment Process (Clause 6.1.2)

Clause 6.1.2 mandates that the organization define and apply an information security risk assessment process that produces consistent, valid, and comparable results over repeated executions.

Essential Requirements of the Risk Assessment Methodology

The methodology must establish:

1. Risk Criteria: Risk acceptance criteria and criteria for performing risk assessments (e.g., establishing a $5\times5$ risk matrix based on quantitative financial thresholds or qualitative operational impact levels).
2. Repeatability & Validity: Ensuring that two different assessors applying the methodology to the same scenario arrive at comparable risk scoring results.
3. Risk Identification: Identifying risks associated with the loss of confidentiality, integrity, and availability (CIA) for information assets within the ISMS scope.
4. Risk Ownership Identification: Assigning a specific Risk Owner (an individual with the appropriate authority and accountability to manage the risk) for every identified risk.
5. Risk Analysis & Evaluation: Estimating potential consequences and realistic likelihoods to calculate level of risk, then comparing results against pre-established risk acceptance thresholds.

---

2. Information Security Risk Treatment Process (Clause 6.1.3)

Once risks are identified and evaluated, Clause 6.1.3 requires the organization to define and apply a risk treatment process.

Risk Treatment Options

Organizations select one or more treatment options for each evaluated risk:

• Modify / Mitigate: Implementing controls to reduce likelihood or impact (e.g., deploying encryption, multi-factor authentication, or security training).
• Retain / Accept: Consciously accepting the risk provided it falls within established risk acceptance criteria.
• Avoid: Eliminating the risk by discontinuing the risky activity, process, or asset (e.g., shutting down a legacy unpatched server).
• Share / Transfer: Transferring financial or operational risk to a third party (e.g., purchasing cyber insurance or contracting a cloud security provider).

Selecting Controls & Annex A Comparison

Organizations must compare the controls selected during risk treatment against the 93 controls in Annex A of ISO/IEC 27001:2022 to verify that no necessary controls have been omitted.

+-------------------------------------------------------------------------+
|                   RISK ASSESSMENT TO TREATMENT FLOW                     |
+-------------------------------------------------------------------------+
|  Identify Risks (CIA Loss)  --->  Score Inherent Risk vs. Criteria      |
|                                              |                          |
|  Formulate Risk Treatment Plan (RTP) <--------+                          |
|           |                                                             |
|           v                                                             |
|  Select Annex A Controls <---> Produce Statement of Applicability (SoA) |
|           |                                                             |
|           v                                                             |
|  Risk Owners Approve RTP & Formally Accept Residual Risk                |
+-------------------------------------------------------------------------+

---

3. The Statement of Applicability (SoA)

The Statement of Applicability (SoA) is one of the most critical mandatory documented information items in ISO/IEC 27001:2022. It serves as the primary bridge between risk assessment findings and control implementation.

Mandatory SoA Content Requirements

Under Clause 6.1.3 (d), the SoA MUST include:

1. Complete Control Listing: All 93 Annex A controls (categorized across Organizational, People, Physical, and Technological themes).
2. Inclusion or Exclusion Status: Explicit determination of whether each control is included or excluded.
3. Justifications for Inclusion: Reasons why controls are included (e.g., risk treatment result, legal compliance, contractual requirement).
4. Justifications for Exclusion: Clear, documented justifications for any excluded Annex A control (e.g., "Control A.7.4 Physical security monitoring is excluded because the organization operates 100% cloud-native with no physical servers or offices").
5. Implementation Status: State of implementation for each included control (e.g., Implemented, In Progress, Planned).

Auditor Rule for Exclusions: An organization cannot exclude an Annex A control simply because it has not yet implemented it. If a risk exists, the control MUST be included in the SoA, listed as "In Progress" or "Planned," and tracked in the Risk Treatment Plan.

---

4. Information Security Objectives and Planning to Achieve Them (Clause 6.2)

Clause 6.2 requires the organization to establish information security objectives at relevant functions and levels.

Criteria for Valid Security Objectives

Objectives must be:

• Consistent with the Information Security Policy.
• Measurable (if practicable) using quantitative or qualitative metrics.
• Taking into account applicable information security requirements and risk assessment results.
• Monitored, communicated, and updated as appropriate.
• Maintained as documented information.

Action Plans for Achieving Objectives

When planning how to achieve its objectives, the organization must document: $\text{Objective Plan} = \text{What will be done} + \text{Resources required} + \text{Who is responsible} + \text{Completion target} + \text{Evaluation method}$

---

5. Planning of Changes (Clause 6.3)

Clause 6.3 is a feature introduced in the ISO harmonized structure. When the organization determines the need for changes to the ISMS, the changes must be carried out in a planned manner.

Auditors verify that structural changes (e.g., cloud migrations, corporate mergers, implementation of new ERP systems) undergo formal change management risk evaluations to prevent unmonitored security degradation during operational transitions.

---

6. Lead Auditor Verification & SoA Audit Methodology

Step-by-Step SoA Audit Protocol

1. Cross-Reference Risk Register to SoA: Sample 10 high-rated risks from the Risk Register and verify that corresponding mitigating controls are marked as Included in the SoA.
2. Audit Exclusions Rigorously: Examine every excluded control in the SoA. Verify that physical exclusions match real-world physical infrastructure and that technological exclusions match network architecture.
3. Inspect Risk Owner Signatures: Confirm that Risk Owners have formally signed off on the Risk Treatment Plan and accepted calculated residual risks.

Real-World Audit Scenario: Unjustified Control Exclusion

Scenario: During a Stage 2 audit of a SaaS provider, the auditor inspects the SoA and notes that Control A.8.28 (Secure Coding) is marked as "Excluded" with the written justification: "Software development is outsourced to a vendor in Vietnam." However, audit interviews reveal that internal engineers write API integration code connecting client databases to cloud storage.

Auditor Finding: Major Nonconformity against Clause 6.1.3 and Clause 8.1. The exclusion justification in the SoA is invalid because internal software development occurs. Furthermore, even if 100% outsourced, secure coding standards and supplier development oversight (Control A.5.37) must be selected to treat development risks.