diff --git a/Corpus/Standards/ISO27x/Risk Treatment Plan.md b/Corpus/Standards/ISO27x/Risk Treatment Plan.md index 690ca4f..30c5cc9 100644 --- a/Corpus/Standards/ISO27x/Risk Treatment Plan.md +++ b/Corpus/Standards/ISO27x/Risk Treatment Plan.md @@ -5,6 +5,53 @@ Find faults or omissions in my reasoning. The Canonical Form of a policy is: >To mitigate the risk of R, control C will be implemented on asset A under the responsibility of asset owner AO. The effectiveness will be measured through method M and will be evaluated by risk owner RO, against established risk criteria RC. +**A Corrected Canonical Form (for a Risk Treatment Plan):** +> "To treat risk R (evaluated against Risk Criteria RC), Control C will be implemented by assigned Actor [Control Implementer], to protect Asset A (owned by Asset Owner AO). The effectiveness of Control C will be measured by Actor [Evaluator] using Method M against established Objectives/Performance Criteria, producing Artifact [Evidence]. Finally, Risk Owner RO will review the evidence to approve the treatment plan and accept the residual risk." + +### Faults in your reasoning + +**1. Misclassification as a "Policy"** Your canonical form reads as a highly specific operational directive, which belongs in a **Risk Treatment Plan** or a **Statement of Applicability (SoA)**, not a policy. + +- **Policies** formally express the high-level intentions and direction of top management (e.g., "We will manage access to our servers"). They are general or high-level. +- **Procedures** detail the _how_. +- The **Risk Treatment Plan** is the formal document where the organization specifies how it will treat identified risks by linking them to necessary controls, while the **SoA** justifies their inclusion. + +**2. "Mitigate" vs. "Modify or Maintain"** You state the control is implemented "to _mitigate_ the risk". While mitigation is a common treatment option, ISO 27002 explicitly defines a **control** as a measure that **modifies or maintains risk**. Some controls (like an overarching policy) only _maintain_ risk at a known level, while compliance with that policy _modifies_ it. Mitigation is just one outcome; controls can also support risk avoidance or risk sharing. + +**3. Responsibility: Asset Owner vs. Control Owner/Implementer** You assert the control is implemented "under the responsibility of asset owner AO". This conflates asset ownership with control implementation. + +- The **Asset Owner** is responsible for the proper management of the asset over its whole life cycle, ensuring it is classified and that access restrictions correspond with that classification. +- However, the responsibility for implementing specific **controls** (e.g., running backups, configuring firewalls) is allocated to various roles according to organizational needs. As illustrated in the TypeDB schema, an `actor` (like a specific IT manager or department) can play the `responsible-for` role for a control, independently of who owns the asset. + +**4. The Role of the Risk Owner in Evaluation** You state the effectiveness will be evaluated by the **Risk Owner (RO)**. This is a subtle fault in the division of duties. + +- Under ISO 27001, the organization must determine _who_ shall monitor and measure, and _who_ shall evaluate the results. This is often a security officer, an auditor, or an independent reviewer (as per control 5.35). +- The explicit responsibility of the **Risk Owner** in the standard is to **approve the information security risk treatment plan and accept the residual information security risks**. They consume the evaluation data to make acceptance decisions, but they do not necessarily execute the evaluation of the measurement method. + +**5. Evaluating Effectiveness against "Risk Criteria"** You state effectiveness is evaluated against "established risk criteria RC". This mixes two different clauses of the standard. + +- **Risk criteria** (which include risk acceptance criteria) are established to evaluate and prioritize _risks_ during the risk assessment phase. +- The **effectiveness of controls** and the ISMS itself is evaluated through monitoring and measurement methods to ensure the controls achieve their **information security objectives** and intended outcomes. +- +### Omissions in your reasoning + +**1. Artifacts and Evidence** To prove that a control has been implemented and measured effectively, the standard requires documented information as evidence. According to the TypeDB schema, an **artifact** (like a record or log) must be captured and linked via a `serves-as-evidence-for` relationship to the control or process. Your form omits the requirement to generate and maintain evidence. + +**2. Traceability to Clauses and Requirements** Your form connects a control directly to a risk, which is correct. However, ISO 27001 and the TypeDB schema also mandate that controls address specific **Requirements** defined within the standard's **Clauses**. An organization implements controls not _just_ to treat a risk, but also to satisfy mandatory compliance, legal, or standard requirements (e.g., ISO 27001 Annex A). + +### A Corrected Canonical Form (for a Risk Treatment Plan) + +If adapted to accurately reflect the framework's data model and terminology, the canonical form for a **Risk Treatment entry** would be: + +**"To treat risk R (evaluated against Risk Criteria RC), Control C will be implemented by assigned Actor [Control Implementer], to protect Asset A (owned by Asset Owner AO), fulfilling Requirement Req. The effectiveness of Control C will be measured by Actor [Evaluator] using Method M against established Objectives/Performance Criteria, producing Artifact [Evidence]. Finally, Risk Owner RO will review the evidence to approve the treatment plan and accept the residual risk."** + + + + + + +## Elements + To establish the compliance of the implementation of a specific control to the ISO 27001 standard, the auditor will look for the following: - the risk that the control is supposed to mitigate - the risk owner