A pragmatic approach to risk assessment and risk treatment that works for all disciplines
  
  “IMS-Smart On-Line is indeed a product of the 21st Century”, as an ISO/IEC 27001/ISO 9001 assessor said at the conclusion of an initial audit in 2008
 

Risk treatment plans

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.

Take a look at Gamma’s paper "Insights into the ISO/IEC 27001 Annex A" which presents the original research into this subject on our behalf.

Want to know the relationship with ISO/IEC 27001?

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.

Risk squares

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:

  1. Avoiding the risk by deciding not to start or continue with the activity that gives rise to the risk;
  2. Taking or increasing risk in order to pursue an opportunity;
  3. Removing the source of the risk;
  4. Changing the FoL of occurrence;
  5. Changing the severity;
  6. Sharing the risk with another party or parties (including contracts and risk financing); and
  7. 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:

  1. Residual risks may not be less than 2½ (why spend money on unnecessary controls?)
  2. Risks where the frequency or likelihood is greater than 4 is unacceptable (i.e. the events are too frequent, regardless of their consequences;
  3. Risks where the consequence is greater than 5½ are academic and are therefore uninteresting;
  4. 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
© IMS-Smart Limited, 2008-2025
Page last updated: June 25, 2025