Undoubtedly, use designer RTPs and deal with implementation plans through a To-Do-List

Risk treatment plans

What are they?

Risk treatment is “…process to modify risk” (ISO/IEC 27000). A risk treatment plan is therefore your plan to modify risk. It is a requirement of ISO/IEC 27001, Clause 6.1.3 e): “The organisation shall define and apply an information security risk treatment process to formulate an information security risk treatment plan.” The general idea is that one:

• performs a risk assessment;
• decide which risks require treatment (e.g. because they do not meet your risk acceptance criteria);
• decide your approach to risk treatment (ISO/IEC 27001 calls this “selecting your risk treatment options”);
• determine the controls that you need to modify risk (i.e., so that the risks after treatment do meet your risk acceptance criteria); and
• produce your plan for treating risk.

Are there different types of plan?

Yes. In excess of twenty international experts, well-versed in ISO/IEC 27001, were consulted about this in 2018, and their responses showed that there are two broad interpretations of the term Risk Treatment Plan (RTP) in use:

• An RTP is a project plan specifying what the organisation plans to do (e.g., in terms of resources, timescales and activities) to implement the controls that it has determined as being necessary for the preservation of the confidentiality, integrity, and availability of the information within scope of its ISMS.
• An RTP is a design specifying how these necessary controls work together (e.g. in terms of their temporal and geographic relationships) to modify risk and thereby render the residual risks acceptable to the organisation.

What do the standards say?

BS7799-3:2017 and ISO/IEC 27003:2017 do not draw a clear distinction between these two interpretations (which should not be surprising since the consultation reported after these two standards had been published. Nevertheless, the new edition of ISO/IEC 27005 is expected to draw the distinction. ISO 31000 only refers to project plans. However, ISO 31000 is not a management system standard and it is incorrect to interpret its content as only relating to ISO/IEC 27001 Clause 6.1 as there are other clauses in ISO/IEC 27001 that deal with planning, resourcing, integration and related activities.

What is the difference?

Once a project plan has been implemented, it ceases to have anything other than historical significance. A designer plan, on the other hand, will always explain how the necessary controls are intended to co-operate and modify risk. As an analogy, consider the distinction between the project plan for implementing a software project, and the software design documentation, or a project plan for building a house extension and the architect’s drawings specifying the dimensions and other relevant details of extension.

One plan or many?

Although ISO/IEC 27001 refers to the risk treatment plan (singular), BS7799-3:2017 points out that organisations may choose to have several plans, e.g., one plan per event-scenario. IMS‑Smart On‑Line uses a set of nine event scenarios, hence a ‘regular’ set of nine RTPs.

If I use designer RTPs, what do I do about project plans?

No problem: some organisations use the concept of a To-Do-List. This is used to record all significant ISMS actions, and would be used as a link to any relevant implementation plans. Moreover, a new requirement has appeared in ISO/IEC 27001:2022 which requires all changes to the ISMS to be planned.

If I use project planning RTPs, what do I do about design?

Hopefully, your implementation plan will specify the location of your necessary controls, so at least their geographic relationships can be determined. However, you might be missing out on their temporal relationships. Moreover, if your organisation is well established but you are new to ISMS, you are not starting with a blank sheet of paper and will already have controls in place. In this case you are unlikely to have a recent implementation plan, and it is therefore best to construct a designer RTP, working in reverse from your existing controls and then supplementing the plan with any missing controls (which are likely to be detective and reactive in nature).

Show me an example?

BS 7799-3 points out that a robust RTP will include an appropriate mixture of preventive, detective and reactive controls. Moreover, rather than have a single plan covering all risks, why not have one plan for each event-scenario?

The following two examples are for scenarios concerning the theft or loss of mobile devices. The first example is a hand-crafted RTP using the tell-it-like-a-story approach. The second example, is computer generated by the IMS-Smart On-Line SAAS. Both RTPs share a common layout:

	a definition of the event;
	estimation of the risks before treatment (in tabular and graphical formats);
	the risk treatment plan, specifying:
	1)	what is done in attempt to prevent the event from occurring;
	2)	what is done to detect the event should it occur;
	3)	what is done to react to the consequence to minimise or otherwise modify its severity;
	estimation of the risks after treatment (in tabular and graphical formats), including an explanation of how the risk acceptance criteria are met;
	evidence that the risk owner has approved the plan and has accepted the residual risks;
	a reference to previous plan (if any); and
	details on how the residual risk has been determined.

Example-2: Auto-generated RTP for the theft or loss or mobile devices

RTP-S1 [Theft/loss of mobile devices]

Event description

A mobile container of information is lost, stolen, reused or otherwise dispossessed.

Likelihood	Consequence	Severity	Risk
3.3 [18 days]	Undesirable disclosure of information	4.73 [£500,000]	8.03
	Inability to carry out some or all of one’s business	4.1 [£100,000]	7.4

Risk treatment plan

Preventing the event

1. We have rules for the secure configuration and handling of endpoint devices, whether those devices belong to our organisation or not (e.g. BYOD or hotel/Internet cafe equipment).
2. Wireless endpoint connections are encrypted (e.g. by using a VPN particularly when secure wireless connections are unavailable).
3. We have policies and procedures that specify the conditions and restrictions necessary for secure remote working.
4. All assets in the inventory are assigned to an owner or custodian.
5. We perform asset musters to confirm that all assets listed in the inventories are present and correct, and that there are no relevant organisational assets that are not included in the inventory.
6. We ensure that equipment, information and software is not taken off site without approval.
7. Media is protected against unauthorised access, corruption and misuse whilst in transit.
8. We have rules for the secure use, reuse and disposal of removable media (e.g. USB sticks, memory cards, portable disc drives).
9. The rules for handling removable media consistent with our classification scheme.
10. When disposing of equipment, we ensure that any sensitive data and licensed software has been removed or securely overwritten.
11. We have rules for the secure use of ICT offsite, whether that ICT belongs to our organisation or not (e.g. BYOD or hotel/Internet cafe equipment).
12. We apply the rules that we have defined for the use of cryptography.
13. Our rules cover the management of cryptographic keys.
14. We encrypt data stored on media to prevent unauthorised access to such information.
15. Remote access software is configured to prevent copy and paste, and downloading of data.

Detecting the event

1. We maintain an inventory of assets (information processing facilities, buildings, physical security devices, etc.) and the information they contain.
2. Personnel and users are made aware of the importance of the reporting information security events and incidents, and how to do that in a timely manner.

Reacting to the consequences

Undesirable disclosure of information

1. Our rules cover the management of cryptographic keys.
2. When required by our access control rules, authentication is required first.
3. Authentication techniques are used to verify the claimed identity of users and other entities.
4. We have the means to ensure that quality passwords are used, and enforce changes as needed.
5. We have a process for the allocation, management and protection of authentication information.
6. Personnel are advised on the appropriate handling of authentication information.
7. We have the contact details for the police, other emergency services, the Data Protection Commissioner and relevant regulatory bodies to hand, ready to use when necessary.
8. We have the means to classify events as incidents and prioritise them for action.
9. We have an incident handling procedure.
10. The procedure gives instructions on how to contain the situation; communicate with relevant interested parties; remedy the situation; and formally close the incident.
11. We are able to conduct information security forensics analysis if necessary.
12. We apply the rules that we have defined for the use of cryptography.
13. We encrypt data stored on media to prevent unauthorised access to such information.
14. We are able to remotely delete the content of mobile devices.

Inability to carry out some or all of one’s business

1. We have and apply a policy for backing up information and verifying that the backed-up information can be successfully restored.
2. We ensure that inadvertent data loss is detected before backups are taken.
3. We restore the appropriate backup(s) to recover all essential information and software following a disaster or media failure.

Risks after treatment

Likelihood	Consequence	Severity	Risk
2.3	Undesirable disclosure of information	2	4.3
	Inability to carry out some or all of one’s business	2	4.3

«Enter your rationale for why the risk criteria, and in particular, the risk acceptance criteria are met.»

«Provide evidence that the risk owner has approved the plan and has accepted the residual risk. A hyperlink to a management review meeting minute will suffice.»

Previous plans

«Use this region as an index to earlier versions of this risk treatment plan.»

Effectiveness of risk treatment

What does IMS-Smart recommend?

Undoubtedly, use designer RTPs and deal with implementation plans through a To-Do-List. Do this regardless of whether you already have information security controls in place, or if you are starting afresh. The prevent–detect–react discipline will supplement the ISO/IEC 27001 SOA safety-net mechanism to determine missing necessary controls.

Designer RTPs have been used successfully as a design tool for new ICT systems. Even though the RTP stories are presented in the order: prevent, detect, react; it is better to start with detect. If you cannot detect the occurrence of an event, you might never know if your preventive controls are working. The next step is to consider reactive measures, and finally the preventive measures. This will naturally lead to a more robust design, well able to cope with control failures and unexpected events.

How does it relate to the SOA?

Necessary controls

There is a close relationship between RTPs and the SOA. ISO/IEC 27001 Clause 6.1.3 d) requires organisations to produce a SOA that includes all necessary controls. The RTPs specify the necessary controls. Thus, the controls specified by the RTPs, all of which are necessary, must be included in the SOA. Conversely, all the necessary controls included in the SOA must be specified in the RTPs. Hence, one benefit of the SOA is that it acts as a summary of necessary controls. This is useful checklist for auditing purposes, and can be used for informing interested parties about the organisation’s security controls without revealing the details of the RTPs.

Annex A controls

Note that Annex A controls do not feature in the explanation of this of this relationship.

Nevertheless, ISO/IEC 27001 Clause 6.1.3 c) requires organisations to compare its necessary controls with those in ISO/IEC 27001 Annex A to determine if any necessary controls have been overlooked. Thus, there should be a relationship between the necessary controls in the RTPs and the controls in ISO/IEC 27001 Annex A. Using the terminology given in ISO/IEC 27003 and 27007 (which respectively explain the requirements of ISO/IEC 27001 and give guidance how to audit for ISO/IEC 27001 conformity) the possible relationships are:

As evidence of fulfilment of the Clause 6.1.3 c) requirement, it is prudent to record this relationship.

This is illustrated in the two RTP examples above:

• Example 1 (hand-crafted RTP): the necessary controls are highlighted (dark purple) and a tooltip (hover over the highlighted text to reveal) shows the mapping to Annex A controls and custom controls.
• Example 2 (auto-generated RTP): each story line corresponds to a necessary control. The tooltip presents the necessary control specification (which coincidentally is the same as the display text in this example) and the mapping to Annex A controls if the mapping exists.

Please remember that Annex A controls are not ISO/IEC 27001 requirements.

Excluded Annex A controls

Any unmapped Annex A controls are either:

• inadvertently omitted necessary controls, in which case the RTPs should be reworked until there are none; or
• excluded Annex A controls.

It is also a requirement of ISO/IEC 27001 Clause 6.1.3 d) to include (with justification) all excluded Annex A controls in the SOA. There are two types of exclusion:

• the Annex A control is obviated by a custom control (see ISO/IEC 27005); or
• the Annex A control mitigates a risk that either the organisation has accepted or is irrelevant (e.g., risks attendant on some aspect of business in which the organisation does not engage).

Strengthening the SOA safety-net

If a necessary control has been inadvertently omitted, but that control is not in ISO/IEC 27001 Annex A, the comparison process will not find it. A detailed explanation of this issue is given in David Brewer’s book “An introduction to ISO/IEC 27001:2022/Amd 1:2024”, pages 124-126, Available on Amazon.

Consequently, it is important to keep the Annex A reference control set up-to-date. The new edition of ISO/IEC 27002 has done this. To supplement this, there are a several other ISO/IEC 270xx standards that augment the Annex A reference control set for sector-specific interests, e.g. ISO/IEC 27011 for telecoms, and ISO/IEC 27017 for cloud computing. However, all of these suffer from the same issue — if the necessary control you have inadvertently omitted in not in the reference set, no matter how extensive you have made it, the comparison process will not find it. Given that the revision of ISO/IEC 27002 only identified the need for 11 new controls since the then current edition was published in 2013, perhaps the issue is not overly significant.

A equally effective, but different test is the prevent–detect–react discipline. In developing “An introduction to ISO/IEC 27001:2022/Amd 1:2024”, (fifth edition) additional controls were identified through the discovery of gaps in the detective and reactive components of some of the standard event-scenarios. Users of the IMS-Smart On-Line SAAS enjoy the benefit of this enhanced reference control set.

How do I produce a RTP?

The process is described in “An introduction to ISO/IEC 27001:2022/Amd 1:2024”) but essentially:

• pick an event-consequence scenario;
• write the story of how the organisation currently detects the event (or, if it doesn’t already do it, or you don’t consider that what it does is not sufficiently effective, how it plans to do it in the future);
• continue by considering reacting to the consequences and finally preventing the event;
• ensure that there is a sufficiency of preventive, detective and reactive controls, so that a failure of one control is protected by others (sometimes this is referred to as defence-in-depth);
• ensure that you are content with all residual risks (i.e., the residual risks meet your risk acceptace criteria);
• perform the Annex A safety-net check, reworking the story writing process if you discover any unmapped Annex A controls for which you cannot provide an objective justification for excluding;
• seek the risk owner’s approval (note that the plan, being written as a story should be readily understandable), and rework as necessary;
• top and tail with the other RTP components — job done.