Working in Information Security we see frequent references to the concepts of Risk Appetite and Tolerance, but they are often confused. Through this article we can hopefully clarify how the concepts of Risk Appetite and Tolerance can be practically applied.
The Limit of Acceptability
We often encounter people who are confused about the relationship between risk appetite and risk tolerance. Whilst Risk Appetite is defined by HM Treasury in “The Orange Book” as “the amount of risk that an organisation is prepared to accept, tolerate, or be exposed to at any point in time”, the publication does not explicitly define Risk Tolerance. The concept that many people are trying to articulate when they become confused between appetite and tolerance is the boundary between risks which can be accepted and risks which may be tolerated.
As part of an engagement working with some safety engineers I discovered they call the boundary between acceptable and tolerable risks the “Limit of Acceptability”. The graph shown to the left uses likelihood and impact on the axes and shows the “Limit of Acceptability”. The area between the “Limit of Acceptability” and the “Limit of Tolerance” is the risk tolerance. It is very important to understand that there is no strict relationship between the location of these two limits, other than the “Limit of Acceptability” being below the “Limit of Tolerance”.
In practice it is much easier to define the “Limit of Tolerance” in terms of unacceptable risks than it is to define what might be a tolerable risk. A simple example is to say “breaking the law is an unacceptable risk”, it is an unambiguous statement that is understandable to anybody.
In practical application the “Limit of Acceptability” in many organisations will be the point at which risks can no longer be accepted by delegated risk owners and will need to be escalated. This is the concept that many are trying to articulate with statements such as “Risk Tolerance for the system is Low”. This effectively means that the treatment of inherent risks assessed at Low or below does not require specific attention. This is not to suggest that treatment of these risks is specifically avoided. Inherent risks above Low will need to be considered for treatment. In many cases these risks will be treated so the residual risk falls to Low, or below. However, when the control to treat the risk is viewed as disproportionately expensive or is assessed to have a significant adverse effect on the functionality of the system it will need to be considered if the risk is tolerable.
Risk Appetite: How Big is your Bucket?
We often find that people struggle with the concept of risk appetite and overall risk exposure for an organisation. A simple analogy is that as an organisation you have a bucket in which you put all your risks. Appetite is the total size of the bucket and exposure is how much is in the bucket at a given time. This means that if the bucket is relatively empty (and current exposure is low) then you might choose to tolerate more risks, however if the bucket is nearly full (and current exposure is high) you either need to address some existing risks to make room in the bucket or tolerate fewer new risks. Some organisations choose to sub-divide their risk appetite and devolve responsibility, the model is still the same they just have several little buckets, which when combined hold the same as the one big bucket for the organisation.
Whilst in the previous section it has been proposed that acceptable risks can be identified ostensibly on their assessed severity, the decision to tolerate a risk needs to be considered in a much broader context. Graphs like the one used in the previous section can be viewed as being partially responsible for the confusion about assessing tolerable risks, since many attempt to illustrate risk appetite purely on the basis of the impact and likelihood. The graph to the right is a simplified version of that above and shows increasing Impact, Likelihood or both leads to increasing Exposure.
Risk Appetite, is often defined in an abstract way. The categories of risk appetite defined in “The Orange Book” and associated publications use classifications such as “Adverse”, “Open” and “Hungry” and the descriptions of these classifications are quite open, for example “Hungry” is described as “Eager to be innovative and to choose options offering potentially higher business rewards, despite greater inherent risk.”. These classifications rely on an assessment being made about the business rewards which result from tolerating a risk.
The concept of increasing Exposure is important to the graph to the left since it allows the two axes on the previous graphs to be combined on to one in this graph. This graph illustrates a range of risk appetite classifications associated with treatment cost. The basic concept of the graph is that for each risk appetite classification only those risks which fall under the line would be within Risk Appetite.
As the text on the graph states it is very important that treatment cost is understood to be not just the cost of implementing a security control, but also any loss of business functionality (dis-benefits) associated with the implementation of the control.
If an attempt is made to apply risk appetite purely in isolation, the lines on the graph would be drawn as horizontal rather than curved, indicating that a risk can be accepted purely on the basis of its exposure rather than as a balance with its treatment cost. This balance has a key part to play in pragmatic risk management, because the focus is on total exposure. In practice this is likely to mean addressing risks with a low treatment cost to reduce exposure allowing the potential to tolerate risks which have a much greater treatment cost.
In practical application it is important to have a standardised method to make an assessment if a risk can be tolerated since all the assessments need to feed into the overall exposure. The method also needs to be scalable so that the amount of effort required is proportionate to the severity of the risk. Since these assessments are likely to form part of a risk escalation process they must be comprehensible to senior risk owners in the organisation who often do not have a technical background.
Regency has considerable experience advising on both the management of specific risks and the design and implementation of risk escalation processes. An example of this is the design and implementation of a risk escalation procedure we created for a central government department. Five years later the process is still in use with the initial department and is known to be in active use by at least four other large public sector organisations.