The risk appetite modelling is the most important element of any risk management framework, regardless of industry or location since it enables management to articulate their control environment. As they are willing to take more risk, they can increase the risk appetite. If they wish to take less risk, they will reduce their risk appetite.
However, to be able to do this in any consistent basis will require the development of a consistent risk register. While this is easy to state, in practice, it has been hard to implement. In this chapter, we will look at why this has been a problem and the solutions.
What Is a Risk Register?
A risk register is certainly not a regulatory construct. Rather, it is one of the key tools used to ensure that risk management is embedded within the organization. To meet its objectives the register needs to include all the risks that are faced by the firm in a language that is common to all its users. A register needs to be embedded and used as well as owned by every business unit management and not by some mythical risk department.
While it is easy to say that all risks must be included, this is not easy to achieve in practice. There are some risks that will be common to all business units within a firm and others will be specific to a single business unit. The management grouping needs to think through the common elements of risk that which will apply to all business units. These will be items such as:
- The risk of internal fraud
- The risk of customers failing to meet contractual obligations
- The risk of running out of money
- The risk of losing key skills
The first risk is typically one of the risks included within operational risk. However, the term operational risk is rarely well understood and is too frequently confused with operations risk, more of which later.
The second risk is clearly a credit risk, but one of a series of credit risks that a firm needs to consider.
The third risk is essentially liquidity risk and it is often due to problems with liquidity risk that firms most frequently fail. This can occur when a firm is growing or recovering as well as when it is failing.
The final risk initially might be thought to be part of each risk, but is not. Loss of key skills may cause many other risks to increase, but that is a consequence, not a cause. Operational risk normally is defined as covering people, process, systems and external risk. As such, this risk is included within operational risk.
By using specific language that is likely to resonate with the audience that is using the information and avoiding generalizations, the risk appears to be relevant to the user. If it is obviously relevant, then the management of a specific business unit may be willing to assist with establishing the extent of the risk. However, for the governance grouping, it will be important to bring all of this together through the medium of risk appetite, so a mapping to a small number of risk is still required. This list is often as follows:
- Credit risk
- Liquidity risk
- Operational risk
- Market risk
- Reputational risk
- Strategic risk
The management team will work together on deciding on the risks that will be common to all business areas and will agree these definitions. When developing the definitions, they should ensure that the language they use is appropriate for the audience for which it is intended. Too often, quality risk programs fail due to lack of implementation within the business, and appropriate use of language is crucial in achieving this.
Developing the Risk Register
At this stage, all you have developed is a list of key risks developed by the management grouping. This needs to articulate both internal and external risks—that is, the risks that the business is able to manage and those that it cannot. Failure to recognize risks that a business cannot manage can often be a cause of failure as the firm has failed to plan to manage a risk that is outside of their sphere of control, such as government action, for example.
The next stage is to complete the list of risks that the firm is subject to. As mentioned, some of these will be within the control perjure of the firm itself whereas others will not. Some will be general to all business units and others will be specific to a single business unit. This is where the workshops come in.
Firms are often too ambitious in their objectives for risk workshops, and from experience you should separate work on risk identification from work conducted on quantification and control. By separating the tasks into something that is manageable, you are able to work with unitary management using a language that means something to them.
Developing the Unitary Risk Appetite
The workshop conducted with the business unit will need to look at the general risks that have been identified by the senior management grouping and then start to consider what this really means to the business unit. Sometimes, the general risk will essentially be redefined into the language of the business unit. In other cases, new risks will be identified, which are more relevant to the business unit management and these will also need to be mapped to the general risks identified by the management grouping.
Local management will not have any real understanding of risk. As we discuss in the next chapter, they have not normally been properly trained to think about risk. Now they are being encouraged to do so. This means that the workshop that is to be used to identify the unitary risks needs to be properly planned and deal effectively with the limited risk understanding of the audience. They know what they are controlling, not what they should be controlling.
The first issue is who should run the workshop. The role of the facilitator is crucial since the success of the workshop will hinge on the ability of the facilitator to engage with the unit management and tease out the risks that they either do or do not control. Before the facilitator commences the workshop, they will need to do a lot of planning.
This will include looking at the things that have gone wrong in the unit to learn which risks they face and do not currently adequately control. They will need to understand the nature of the activity conducted and look at the way that risks are currently controlled.
The next task is to think through the totality of the risks faced by the business unit, regardless of whether or not they are controlled. Workshops frequently fail through focusing on the risks that the business currently controls, rather than those that it fails to recognize at all.
Structure of the Risk Register
There are some elements that are common to all risk registers. These are as follows:
- The name of the risk
- The description of the risk in a language that unitary management will understand
- The owner of the risk
- How the risk is managed and controlled
- How the risk is measured
The risk owner should be the person who has responsibility for the risk. They should have the ability to manage the risk and receive sufficient reliable reporting to enable them to know when problems are likely to occur.
How the risk is currently controlled and managed should be recorded in the register. This should be a statement of what is currently achieved, not a view about what might potentially be achieved in the future. The risk register is a live document used by management on a regular basis, not something that is imposed upon them and is theoretical.
The real problem comes with measurement, as we shall discuss in more detail later. Some risks have agreed methodologies for measurement and these should clearly be used. However, some risks are not easy to measure with any degree of accuracy. How would you measure the risk of government intervention or a terrorist event? Of course, not everything can be measured accurately.
Unless the risks are measured, how could you track the effectiveness of your control strategy? Measurement will probably involve a combination of judgment and measurement, but some form of numeric format for judgment is still required.
There are some real challenges here, not the least of which is dealing with both relevance and scaling, but more of this later.