working on the RTP

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