Defining your risk appetite
I was recently working with a client who wanted to improve how they do IT change management. This organization had a one-size-fits-all approach to assessing changes, so that every change, however minor, had to go through the same very long-winded bureaucratic process. One piece of advice that I offered was that they should define their risk appetite in a way that would help people understand what risks were acceptable, and when they needed to be more cautious.
Who says you need to define a risk appetite?
You can find guidance on how to manage risks in many different places.
- ISO 31000 standard. Risk management: principles and guidelines
- ITIL 4 risk management practice (Described in the ITIL 4 Foundation publication, and in more detail in the Risk Management Practice guide which can be downloaded by subscribers only)
- ISO/IEC 27001: Information security management
- COSO Enterprise Risk Management – Integrated Framework
All of these standards and frameworks have one thing in common, they stress the importance of defining a risk appetite so that people carrying out risk assessment know the types of risk the organization finds acceptable. For example, if you are creating a new start-up organization you may be prepared to accept a high risk of failure, if there is a higher probability of enormous success. In contrast if you are designing the control system for a nuclear power plant you will not want to take any avoidable risks, even if this means spending a lot of money to prevent a highly unlikely failure.
Risk assessment is an essential part of many different things that an IT organization does. It is especially relevant to assessing changes, managing projects, resolving incidents and problems, planning availability and continuity, but is also important for nearly every other IT service management practice. Whenever you assess a risk, you need to understand what the organization’s risk appetite is, otherwise you can go badly wrong.
I wanted to offer my customer some guidance on how to define their risk appetite, but a quick web search didn’t offer much that was helpful at all. It appears that, while everyone knows that they need to define a risk appetite, there is little readily available advice on how to actually do it, so here is an approach you can use to get started.
How to get started
Most organizations don’t have a single risk appetite that applies to everything they do. There are usually some parts of the organization that will not work effectively unless some risks are acceptable, and others that must be more careful. What is required is a way to express this variable level of risk appetite in a way that people will find helpful.
The approach that I recommended was that my customer should define and document five levels of risk appetite, and then assign each aspect of how they work to one of these levels. I offered some definitions for my customer to think about; they may be useful as a starting point for defining your own organization’s risk appetite. Please don’t just copy them. To be useful they need to be adapted to meet the organization’s specific requirements. Think about your own organization and define your own risk levels. You may not even want to define five levels, maybe three will be enough for you.
Here are the levels that you can use as a starting point:
Appetite name |
Description |
Hungry |
We want to be innovative. We will accept significant risk to get the best chance of high rewards. |
Accepting |
We are prepared to accept a fairly high level of risk if there is a high likelihood of success and a high level of reward. |
Balanced |
We are willing to accept a moderate amount of risk if there is scope for significant rewards. Risks must be understood and controllable. |
Cautious |
We are willing to do things that have some level of risk, but only if they are needed to achieve key deliverables. We do not accept risks simply because there is an opportunity for reward. |
Averse |
Avoiding risk is essential. We will only do things that have a negligible amount of risk. |
You can modify these definitions in any way that works for you, they are simply offered as a starting point for your risk appetite definitions. In fact, I used the risk appetite levels defined by another organization[1] as my starting point for these definitions, but I modified them to be more appropriate for my customer.
After you have defined your risk appetite levels, you need to assign appropriate risk appetite levels to the things that they will be used to help manage. In the case of an IT organization, you could assign risk appetite levels to:
- Projects
- Services
- Applications
- Systems
Or any other aspects of your IT where you need to assess risks. This means that you could have some projects in your organization that are Hungry, they represent significant opportunities for growth, while simultaneously having projects that are Cautious, they are essential to running the business. This risk appetite level can then be used when assessing changes, planning problem resolutions, designing service continuity arrangements, or carrying out any other risk assessment.
At an enterprise level, an organization might assign risk appetite levels to different organizational units, as well as to projects and programmes. For example, the finance department might be Cautious while the R&D department is Accepting. These risk levels can be used in a similar way, to help people making decisions understand what level of risk is acceptable in each case.
Summary and Next Steps
Risk assessment is an essential part of most things we do in IT service management, and a clearly defined risk appetite is needed to help people assessing risks to understand what level of risk is acceptable.
You can create reasonably simple definitions of risk appetite levels, and then assign one of these levels to each of your organization’s various activities, whether these are projects, services, business units or any other clearly identifiable part of your work. Then when you need to make decisions that involve risk (as, of course, so many of them do) you will have the guidance you need to help you consider how best to manage that risk.
As always, if you try the ideas in this blog, please let me know how well they work out for you.
[1] ICO risk-management-policy-and-appetite-statement-v4-5.pdf
Image credit: Graeme Maclean
This work is licensed under CC BY-SA 4.0