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:
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:
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 and IMS‑Smart Assistant both use a standard set of twelve event scenarios, hence a standard set of twelve 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.
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 Assistant software. Both RTPs share a common layout:
Example-1: Hand-crafted RTP for the theft or loss or mobile devices
RISK TREATMENT PLAN S1
|Once in three weeks (3.24)||C - Undesirable disclosure of information||4.7||7.94|
|A - Inability to carry out some or all of one’s business||4||7.24|
We take precautions against damage, theft and loss for all physical information containers, whilst travelling and working away from the office (on a temporary or extended basis), or at home, or in transit (in person or by courier or post). Our staff are responsible for the assets in their care, having been allowed to remove them from our office premises. They are therefore are careful to keep equipment with them (e.g., in our cabin luggage when travelling by air), or in a locked room.
If we are sending electronic data by post, e.g. a DVD or USB, it will be encrypted, as indeed are our laptops and any USB sticks we might have on our person.
Containers may also be deliberately discarded and then reused by someone who is not permitted to see the original contents. However, we have a procedure that ensures that the risk of improper disclosure of information, following disposal or reuse, is acceptable.
Off-site back-up tapes are kept in secure storage («name facility»)
Damage, theft and loss is usually obvious. In any case, we have an asset inventory and a muster will reveal loses, and tell us precisely what was lost or stolen. If a container has been lost, where feasible, we will attempt recovery, e.g. by contacting the appropriate lost property department. As our employees and contractors are not permitted to put themselves in danger, it is accepted that the detection of these events whilst they are in progress will not normally allow the consequences to be prevented.
We use couriers because of the speed and guaranteed of delivery, and we would therefore expect to be notified by the couriers if the container was somehow lost in transit. We will also request the recipient to confirm delivery.
Not to know that a mobile container has been dispossessed is an acceptable risk.
If the device is registered with our Mobile Device Management System, it will be deactivated and wiped of all data.
We use hard disc encryption on our laptops, combined with strong twelve-character log-on passwords. We are reliant on the strength of the encryption that we use («say what, e.g. PGP, Bitlocker»). It might be possible to crack, but we consider that an acceptable risk.
There is also a risk that a laptop could be seized whilst it is actually being used and before the time it takes for the user to switch it off. We consider that this also represents an acceptable risk, particularly in view of our policy of not letting our staff put themselves in danger.
Our off-site backups are encrypted.
Loss or theft would be reported to the police and, depending on the content, to the Data Protection Office.
The inability to carry out some or all of our business as a result of the dispossession is first countered by the fact that the encrypted data that might be dispossessed is only a copy. If necessary, we would hire a replacement equipment locally, and use it to connect the to our office servers via VPN. Replacement equipment would be acquired and the software and data replaced via re-installation and backups. The delays and costs involved in recovery are acceptable.
|C - Undesirable disclosure of information||~Twice a year (2.3)||2||4.3|
|A - Inability to carry out some or all of one’s business||~Twice a year (2.3)||2||4.3|
Risk treatment plans will, in general, describe a mixture of preventive, detective and reactive controls to modify risk. Preventive and detective controls act to modify the occurrence of a consequence, whilst reactive controls act to modify the severity of the consequence. Start by selecting the control behaviour and then the values for risk reduction. Only consequences associated with this event are shown.
|Treatment pair||Control behaviour||Risk modification parameters|
|Preventive and detective controls||Strangulation|
FoL modification: 1/10 as many occurences
Limit: Once a year
|Reactive controls for:|
Undesirable disclosure of information
Limit: 1/100 as much
|Reactive controls for:|
Inability to carry out some or all of one’s business
Limit: 1/100 as much
Example-2: Auto-generated RTP for the theft or loss or mobile devices
A mobile container of information is lost, stolen, reused or otherwise dispossessed.
|Undesirable disclosure of information||4.73|
|8.03||Inability to carry out some or all of one’s business||4.1|
|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.»
«Use this region as an index to earlier versions of this risk treatment plan.»
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.
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.
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:
|Relationship||Name given to the necessary control|
|The specification of the necessary control is identical to a control in ISO/IEC 27001 Annex A||Annex A control|
|The specification of the necessary control is similar to a control in ISO/IEC 27001 Annex A||Variant control|
|The specification of the necessary control has no correspondence with any of the controls in ISO/IEC 27001 Annex A||Custom control|
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:
Please remember that Annex A controls are not ISO/IEC 27001 requirements.
Any unmapped Annex A controls are either:
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:
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:2013”, pages 104-106, Available on Amazon, and subsequently in BS 7799-3:2017, pages 21-23.
Consequently, it is important to keep the Annex A reference control set up-to-date. A new edition of ISO/IEC 27002 is being prepared. 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 (as evidenced in the draft for public commentThis was available on the BSI website over the period 28 January until 22 March 2021.) only identified the need for 11 new controls since the 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 “ISO/IEC 27001 — Mastering Risk Assessment and the Statement of Applicability” (available on Amazon and in the Assistant), an additional ten controls were identified through the discovery of gaps in the detective and reactive components of some of the standard event-scenarios. Users of the Assistant software will enjoy the benefit of this enhanced reference control set.
Detailed step by step instructions are given in “ISO/IEC 27001 — Mastering Risk Assessment and the Statement of Applicability” (and the process is also described in “An introduction to ISO/IEC 27001:2013”) but essentially: