# Risk Treatment Plan

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
- the scope of the control, in terms of organizational scope (certain business activities, organizational units) and asset(s) protected
- the control owner
- a description of the 'how' or the activities involved in the implementation, including roles and responsibilities
- how the effectiveness of the control will be established, when, and by whom
- how the effectiveness of the control will be evaluated, when, and by whom
- possible exemptions to the policy
- how exceptions will be handled
- where all this is documented (policies, logs etc., evaluation)
- for this documentation: Version information and who has authoured and signed off on the policy, Revision dates (+ next evaluation) 
- what the change procedure is for a relevant policy



**"Formally":**
- A policy formally expresses the intentions and direction of management. Rather than detailing exactly _how_ a task should be executed, the overarching information security policy is supported by "topic-specific policies" **as needed** to mandate the implementation of controls for specific target groups or security areas (such as access control, physical security, or secure development).
- **The Role of a Procedure (The "How"):** The specific steps on _how_ to carry out an activity or process are defined in a **procedure**. For example, Control 5.37 requires organizations to maintain "documented operating procedures" that provide personnel with the detailed, step-by-step instructions needed to ensure the correct and secure operation of information processing facilities
- It is also important to note that a control is broadly defined as **any measure that modifies or maintains risk**. Therefore, a control itself can take the form of a policy, a procedure, a process, or a technical hardware/software function


Version Control

| Type            | Value |
| --------------- | ----- |
| Version number: | x.xx  |
| Version date:   | x.xx  |
| Document owner: | name  |
| Approved by:    | name  |
| Approved on:    | date  |
| Next review:    | date  |

The Document Owner is responsible for development and implementation of the policy.

- [ ] Check Standard on documentation and ownership


## Approved
Name: | name
--- | ---
Signature: | signature
Date: | date