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

7.8 KiB Raw Blame History