The IMS-Smart approach to risk assessment and risk treatment makes use of the time theory by relating events to consequences through a series of Risk Treatment Plans (RTPs). The objective of creating the RTP is to identify the controls that we need and how they are to work together in concert to reduce risk to an acceptable level. There are three types of control:
Preventive controls act to prevent the event (or act so fast that they effectively achieve exactly the same effect).
Detective controls act to detect the event thereby allowing action to be taken in attempt to prevent the occurrence of the consequence.
Reactive controls act on the occurrence of the consequence and attempt to first reduce its severity and subsequently to restore normality.
In practice, events and consequences form sequences, where the consequence resulting from one event can be reconsidered as the triggering event for other consequences.
The IMS-Smart approach to risk assessment and risk treatment conforms to the principles and guidelines given in ISO 31000:2009 Risk Management - Principles and guidelines.
Consequences
We formally define an consequence as a happening that results in a reduction in the value of an organisation or the quality of life. Often value is measured in terms of money, but other dimensions can be used such as reputation.
Examples of consequences are:
Adverse press coverage
Court action against and employee and/or the organisation
Failure to prosecute
Failure to win business
Fraud
Inability to carry out some or all of the organisation’s business
Loss of customer confidence
Loss of revenue
Loss of life, disability and illness
Loss of supplier confidence
Loss of the monetary value of assets
Loss or lack of information integrity
Pollution
Resource wastage
Unanticipated costs
Undesirable disclosure of information.
Some of these (e.g. the inability to carry out some or all of the organisation’s business; fraud, the loss of life, disability and illness; and resource wastage) often feature as the primary consequences of a RTP, the others featuring as consequential consequences. However, for RTPs that focus on incident management and recovery the primary consequence has already occurred and may be thought of as the triggering event for incident management and recovery. In this case, an objective of the RTP is to prevent the consequential consequences. ISO 22301, the management system standard for business continuity has a requirement for handling the media (e.g. the press and television). This is an example that having suffered the primary consequence, e.g. the inability to carry out some or all of the organisation’s business due, say, to a massive gas explosion, effort has to be spent in preventing the consequential consequence of adverse press coverage.
Events
An event is a happening that leads to the occurrence of an consequence.
Study of ISO/IEC 27002:2022 concerning information security reveals that there are just three triggering events that cover the whole of that standard’s guidance on best practice (i.e. all 114 controls). These three triggering events are:
Exploitation of a vulnerability
IT failure
Dispossession
In the first case, an attacker may exploit a security vulnerability to cause the undesirable disclosure of information, fraud or denial of service. That attacker could be an authorised user of an organisation’s IT, whereby they abuse their authority and do things that they should not. Alternatively, the attacker might not be an authorised user but they might attempt to masquerade as one. It might also be possible that the attacker could gain access by some other means (e.g. hacking), or simply eavesdrop (e.g. just overhear something said in a public place). In the second case, IT fails because of a hardware or software malfunction. The malfunction can be brought about in a variety of ways, such as lack of power, adverse operating conditions (fire, flood etc.), unreliability and specification/ design/ implementation errors. In the third case, a physical container of information is dispossessed. Typical containers are documents, envelopes, briefcases, laptops, desktops, servers, PDAs, mobile phones, cameras, magnetic tapes, CDs, DVDs, USB sticks etc. Dispossession could be because the container is lost, stolen, damaged or destroyed, misappropriated (e.g. lost in the post), or dispossessed of and perhaps reused. In all cases the owner, or rightful user, of the container no longer has the container in their possession. The immediate consequences of this are therefore the loss of the monetary value of the container (e.g. the replacement cost of a laptop and its software); the inability to continue working and the undesirable disclosure of the information that the container contained.
In practice, however, the RTPs that derive from these three triggering events are unwieldy and it is sensible to break the event down into sub events. IMS-Smart On-Line does this.
There is a requirement in ISO/IEC 27001 to produce a “risk treatment plan”. This expandable panel explains the relationship between this clause and the RTPs described in the main body of this page.
What does ISO/IEC 27001 say?
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 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?
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-1: Hand-crafted RTP for the theft or loss or mobile devices
RISK TREATMENT PLAN S1 [Theft/loss of mobile devices]
Event description
A mobile container of information is lost, stolen or otherwise dispossessed. In all cases the rightful user of the container no longer has the container in their possession.
Risks before treatment
Likelihood
Consequence
Severity
Risk
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
Risk treatment plan
Preventing the event
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»)
Detecting the event
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.
Reacting to the consequences
Undesirable disclosure of information
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.
Inability to carry some or all of one’s business
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.
Risks after treatment
Consequence
Likelihood
Severity
Risk
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
«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
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
Excess
Limit: 1/100 as much
Reactive controls for: Inability to carry out some or all of one’s business
Excess
Limit: 1/100 as much
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
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).
Wireless endpoint connections are encrypted (e.g. by using a VPN particularly when secure wireless connections are unavailable).
We have policies and procedures that specify the conditions and restrictions necessary for secure remote working.
All assets in the inventory are assigned to an owner or custodian.
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.
We ensure that equipment, information and software is not taken off site without approval.
Media is protected against unauthorised access, corruption and misuse whilst in transit.
We have rules for the secure use, reuse and disposal of removable media (e.g. USB sticks, memory cards, portable disc drives).
The rules for handling removable media consistent with our classification scheme.
When disposing of equipment, we ensure that any sensitive data and licensed software has been removed or securely overwritten.
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).
We apply the rules that we have defined for the use of cryptography.
Our rules cover the management of cryptographic keys.
We encrypt data stored on media to prevent unauthorised access to such information.
Remote access software is configured to prevent copy and paste, and downloading of data.
Detecting the event
We maintain an inventory of assets (information processing facilities, buildings, physical security devices, etc.) and the information they contain.
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
Our rules cover the management of cryptographic keys.
When required by our access control rules, authentication is required first.
Authentication techniques are used to verify the claimed identity of users and other entities.
We have the means to ensure that quality passwords are used, and enforce changes as needed.
We have a process for the allocation, management and protection of authentication information.
Personnel are advised on the appropriate handling of authentication information.
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.
We have the means to classify events as incidents and prioritise them for action.
We have an incident handling procedure.
The procedure gives instructions on how to contain the situation; communicate with relevant interested parties; remedy the situation; and formally close the incident.
We are able to conduct information security forensics analysis if necessary.
We apply the rules that we have defined for the use of cryptography.
We encrypt data stored on media to prevent unauthorised access to such information.
We are able to remotely delete the content of mobile devices.
Inability to carry out some or all of one’s business
We have and apply a policy for backing up information and verifying that the backed-up information can be successfully restored.
We ensure that inadvertent data loss is detected before backups are taken.
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:
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:
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.
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.
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;
Study of ISO 9001 also reveals three families of triggering events:
Supply of the wrong product
The introduction of a nonconformity into an organisation’s product
A bad customer experience.
Supply of the wrong product
Nonconforming product
Bad customer experience (images are Microsoft Clip Art)
The triggering events associated with other management system standards can also be expressed as event families, or more correctly event sets. Of importance, however, that that ISO 22301 effectively has to deal with all the triggering events of all other management system standards plus those that are not covered by any management system standard plus the one that nobody expected.
Risk
Provided we use meaningful scales, risk can be expressed as the product of the frequency or likelihood (FoL) of the occurrence of an consequence and the severity (Sev) of the consequence, i.e.
Risk = FoL * Sev
It is convenient to use logarithmic scales so that the level of risk can be expressed as the sum of the individual levels of FoL and Sev.
The units of FoL are reciprocal time (time-1) while the units of Sev, as we said previously, are either money, quality of life or some other parameter.
Note that preventive and detective controls act to reduce the frequency or likelihood (FoL) of the occurrence of an consequence, whereas reactive controls act to reduce the severity (Sev) of the consequence.
Calculations of risk should have no upper or lower bounds, although in expressing risk in a graphical form it is convenient to express risk on a five or seven point scale. Examples of five point scales for FoL and Sev are:
Scale value
Frequency or likelihood (FoL)
Severity (Sev)
5
Several times a day*
£10,000,000
4
Once every 2-3 days*
£1,000,000
3
Once a month*
£100,000
2
Once a year
£10,000
1
Once a decade
£1,000
Note here that the descriptions marked with an asterisk (*) are convenient approximations. As we are using a logarithmic scale the actual FoL values for the scale values of 3, 4 and 5 are respectively 36.5 days, 3.65 days and 8hrs 46 mins. As risk calculations have no upper or lower bounds, extrapolating downwards a scale value of -1 gives a FoL of once a millennium and a Sev of £10, and extrapolating upwards a scale value of 7.8 gives a FoL of once per second and a Sev of £6,309,573,445.
Inherent, residual and acceptable risks
The inherent risk is the risk that exists in the absence of any controls. Residual risk is the risk that should remain once the applicable controls are deployed. The residual risk is deemed to be acceptable if it is less than or equal to some value that should be defined by the risk owners, e.g. the executive board, as a matter of policy.
In the graphs on the right, acceptable risk is indicated by the orange and green areas. The solid squares represent the inherent (upper right) and residual (lower left) risks and the dotted squares represent areas of uncertainty in assessing the inherent and residual risks. The squares containing arrows indicate off-scale values.
It is possible, either during the course of developing the RTP, or at some other time to discover that the actual risk exposure is unacceptable. For example an audit or incident may reveal that the controls are wanting in practice and that you are thereby exposed to an unacceptable risk. Action must be taken, and it is prudent to decide what that action should be prior to its occurrence.
It should be noted that once an unacceptable risk has been identified, either the operations that give rise to the event must cease or the risk owner’s risk appetite must be increased. However, it must be remembered that if the risk appetite is increased it ought not to be a significant increase in terms of log(LoF) + lof(I), since each unary increment represents an order of magnitude.
Risk treatment
ISO 31000 identifies seven options for treating risk:
Avoiding the risk by deciding not to start or continue with the activity that gives rise to the risk;
Taking or increasing risk in order to pursue an opportunity;
Removing the source of the risk;
Changing the FoL of occurrence;
Changing the severity;
Sharing the risk with another party or parties (including contracts and risk financing); and
Retaining the risk by informed choice.
Note that the off-scale risks in the above inherent risk graph are candidates for the application of the second option, as it may be possible to increase risk whilst still keeping it in the orange and green areas. Note that in accordance with ISO Guide 73, a control is a measure that modifies risk.
Risk criteria
Whilst in principle one could elect to define a criterion for acceptable risk as being a number, in practice risk acceptability is better represented by an envelop as shown in the diagram. In this case, in addition to the simple criterion that a risk is acceptable if FoL + Sev ≤ 6:
Residual risks may not be less than 2½ (why spend money on unnecessary controls?)
Risks where the frequency or likelihood is greater than 4 is unacceptable (i.e. the events are too frequent, regardless of their consequences;
Risks where the consequence is greater than 5½ are academic and are therefore uninteresting;
Risks where the frequency or likelihood, or the consequence is less than ½ are too small.
Moreover, rather than then have a criterion that requires risks to be treated until the resultant residual risks lie in such an envelope, it is better to use criteria which impose conditions on the risk treatment plan, e.g.
In cases where the likelihood is [some condition, e.g., greater or less than some value, or within some range], then use must be made of approved preventive technologies, supported by approved detective technologies that are able to provide an alert within of the event. In cases where the consequence is [some other condition], then use must be made of approved reactive technologies.
This approach is fully conformant to the requirements of ISO/IEC 27001:2022.
If this is not done, then one might be tempted to try to measure, estimate or otherwise determine the effectiveness of individual controls and then combine them to determine the residual risk. If the result lies within the risk acceptability envelope then the risk is deemed acceptable otherwise the treatment process must be repeated until it does.
RTP layout
IMS-Smart has a standard way to lay out RTPs. Each considers an event set and their corresponding primary consequences (as described above). Each event set is often broken down into sets of sub-events, referred to as event-circumstances. Thus for dispossession, the event-circumstances could be: (a) theft from office premises; (b) theft from outside office premises; (c) mislaid within office premises; (d) lost whilst outside office premises; (e) accidental damage; (f) wilful damage; (g) damage caused by fire or flood, etc; (h) misappropriation from the office; (i) lost in transit; and (j) disposal. However, organisations are not compelled to do this and may create RTPs for whatever events they see fit.
Each RTP:
Identifies the consequences (both primary and consequential), that might then result;
Estimates the FoL of the event-circumstance and the severity of the resultant consequence in the absence of any controls;
Treats the risk by choosing one or more of the seven risk treatment options together with an appropriate modelling control;
Determines the effect that these applicable controls have on modifying the FoL of the consequence and/or the severity of the consequence (which is, of course, the residual risk).
Tell it like a story
The identification of controls and the treatment of risk is presented in the form of a "story". An example, taken from a Vulnerability Exploitation RTP is:
We have an up to date set of rules. They cover all our legal, regulatory and contractual obligations, and are proportional to our risks. All security data (such as the cryptographic keys used for internal email) financial and personal information, our products and that concerning our client’s business is regarded as sensitive. We oblige our employees, contractors, customers etc, to follow them and we carefully select our employees and contractors before engaging and deploying them. There are penalties for not following the rules. If someone breaks the rules, they therefore cannot reasonably claim that they did not know that such rules existed. However, they might break them because they do not fully understand them.
A design tool
Thus, each RTP presents the overall design of a suite of controls, showing how the individual controls work together to prevent an event, or if that cannot be done or a control fails, how the event can be detected in good time to do something about it, and if that fails how to mitigate and/or recover from the resultant consequence. Where appropriate, controls should be used to anticipate events (i.e., the use of tell-tale signs, based on past experiences, to predict the onset of an event). Thus, each RTP constitutes a design for reducing risk to an acceptable level and it is usual to take decisions on the acceptability (or otherwise) of the residual risk during the process of creating that design.
Sequence and interaction
Collation of all your RTPs will identify the sequence and interaction of your controls. In using this approach in the context of ISO 9001 we have been able to determine what the necessary quality controls are from first principles and establish their interaction.
This site does not use cookies, but if you logon to an IMS-Smart product
you consent to that site setting authentication session cookies