Working In Uncertainty

When is it OK to use a risk register? (revised)

This revised edition (in 2015) is significantly expanded in scope and reorganized from the first edition (in 2011) to reflect research in 2015[1] showing that many organizations do not use risk registers within a pure Risk Listing[2] approach (despite almost always being expected to).

Risk registers are simply lists of 'risks' with additional information associated with each one. There are differences in the nature of the 'risks', in the associated information, and in the way the register is used.

The following sections discuss preconditions for using three common styles of risk register and associated design details. The three styles of risk register covered in this article, in what I think is descending order of frequency of use in the UK, are:

• high level risks used as a list of objectives;

• low level risk events used in Risk Listing; and

• variables in a decision model.

The article is concerned with the conditions in which risk registers are 'ok' and this does not make them the best choice. Risk registers are almost never the best choice of technique because they tend to promote risk management that is separate from core management activities. However, risk registers are expected of some people in some organizations, so our objectives here are just to (1) limit the damage done by using risk registers when they are worse than useless, and (2) suggest the design details for risk registers that make them more appropriate for the use that is being made of them.

High level risks used as a list of objectives

General description

In this style most of the 'risks' are stated with high level phrases such as 'Patient safety', 'Financial security', or 'Cyber risk'. Only rarely are they worded as events that might happen. Typically there are no more than 20 such risks on the register and I have heard 7 risks only recommended as good practice in one UK central government department.

These 'risks' are used as the basis for wide ranging conversations about what is being done about them and what actual performance has been. In effect, these 'risks' serve as objectives. Performance and progress are discussed periodically.

Conditions and recommendations for risk register design

This style of risk register is widely applicable but, as with any set of objectives, the scope of risk management driven by such a register is limited to decisions on those objectives only. This is a more limiting constraint than you might think because most of the important decisions we take at work involve a lot of factors, some uncertain and some uncertain, some related to 'risks' and some not (see Appendix A: The Scope Problem). The decisions that are just about risks (and money costs) tend to be quite small, narrow, and often remedial.

Here are some points to consider in designing this style of risk register:

• It is not appropriate to rate the risks for their probability of occurrence and impact if they do occur. If you consider some typical examples (e.g. "Health and safety") then it is obvious that probability and impact ratings are absurd. Instead use something sensible, such as the cumulative probability of impact greater than a given threshold level, a forecast range for actual performance, or just an overall rating of 'importance'.

• If you are confident that there will be no actions to consider that affect more than one of the risks on the register then you can use the side-by-side format of risk register, where actions are listed beside risks (see Appendix A: The Mapping Problem). Otherwise, it is better to use a matrix style[3], where risks and actions are the column and row headings of a matrix which can then be filled in to show which actions relate to which risks.

• Do not have a common, fixed level of risk that is the trigger for taking action or for upwards escalation or reporting. The wide range of actions and the flexibility over the boundaries of 'risks' mean that a fixed threshold is meaningless (see Appendix A: The Aggregation Problem). Instead, avoid such thresholds and just take whatever decisions are worthwhile, regardless of actual performance against each 'risk'. Alternatively, have target risk levels as you might have targets for other objectives (with all the issues that targets can bring).

Alternative techniques to use if you can

The obvious alternative technique is to have those 'risks' on the same lists as other objectives, worded as objectives, and treated in exactly the same manner as other objectives. Push all objectives through management as usual. In this way, things you want to increase (e.g. sales) and things you want to reduce (e.g. injuries) are considered together, as are certain consequences and uncertain consequences (sometimes also called 'risks').

Decisions and the reasons for them can be documented for these objectives/risks as usual and, if this is done, then nothing is gained by documenting them again in a risk register.

Low level risk events used in Risk Listing

General description

The 'risks' in this style are mostly worded as events that might or might not happen. There may also be material about causes and effects and, in some variations of this style, the risks are listed against objectives. In IT related risk registers it is common to have lists of vulnerabilities, which take the place of risks or are listed next to them.

These lists of risks tend to be quite detailed and there may be many risks on the list, potentially thousands.

The risk register is used within a Risk Listing process[2], which involves meetings and documents separate from core management activities and focused on managing the risks on the list.

Conditions and recommendations for risk register design

The conditions for this style of risk register to be 'ok' are quite stringent:

• The scope must be limited to decisions on actions seen as responses to the risks (see Appendix A: The Scope Problem). That again means a very limited set of decisions is involved and most of the important decisions in an organization are not in scope.

• There should not be causal connections between the risks on the list. Causal connections create difficulties in deciding probabilities and estimating potential impacts that cannot be resolved within a risk register format (see Appendix A: The Multiple Counting Problem). This again is quite a stringent condition because causal connections between risks on these lists are quite common.

Here are some points to consider in designing this style of risk register:

• Do not use ratings of probability and impact unless:

  • the consequences of the event are naturally black-or-white, with limited spread of impact (see Appendix A: The Shades of Grey Problem and The Impact Spread Problem);

  • potential consequences are not extreme (see Appendix A: The Extremes Problem); and

  • all consequences are negative or neutral (see Appendix A: The Two Tails Problem).

  Instead, use cumulative probability distributions (or a simplification of such) or just an overall rating of 'importance'.

• Unless you are confident that no action will be a response to more than one risk, do not use the side-by-side style of risk register (see Appendix A: The Mapping Problem). Instead use a matrix style[3].

• The importance of risks on a list like this depends on how widely each risk is defined. Consequently, it makes no sense to use a fixed, common trigger level of risk for deciding when to take action or escalate risks, unless the risks have a particular kind of equivalence (see Appendix A: The Aggregation Problem). For example, if the risks were a particular insurable event for each of a pool of motor vehicles, then it might be sensible to use a fixed threshold for some purpose. More often it is better to just take additional actions to respond to a risk when those actions are worthwhile, taking everything into account.

Here are some common applications of risk management classified according to whether they are suitable for risk registers used in this way or not.

Alternative techniques to use if you can

The best way to manage risk is, usually, as an integral part of core management activities such as planning, design, and objective-setting. There are many well established ways to do this. Typically, this means getting decisions right in the first place, rather than trying to correct badly made decisions after they have been taken.

Variables in a decision model

General description

In this style the risk register is really just documenting the elements of a model, where at least some of these have associated uncertainty. The centre of attention is the model, and the register is just a view of its variables. These variables include its inputs, intermediary variables, and the variables whose values we want to predict. They also include parameters for relationships between other variables. For example, we might think that better customer service drives increased sales, but by how much and after how much delay? Such crucial parameters are often highly uncertain.

A common form of such a list is the Tornado Diagram, which is a list of variables with a coloured bar next to each whose length indicates the importance of the uncertainty around the variable to the uncertainty in the final prediction. You could think of this as a form of 'risk rating' done automatically by the computer and reflecting the logic of a model that will ideally be coherent and based on our best thinking and research.

Models such as this go through several iterations of development and at each stage it can be helpful to review the major areas of uncertainty and consider further research and further actions that be taken to manage those. These ideas could be documented on the risk register.

Conditions and recommendations for risk register design

This style of risk register is appropriate for any situation where a decision support model is appropriate, which is most important decisions. However, it may not be necessary to document the model in the form of a risk register.

A model is required if this style is to be used, of course, but it need not be fully quantified and automated. It might be a conceptual model.

Here are some points to consider in designing this style of risk register:

• Unless your model only has binary variables, do not use probability and impact ratings. Models like this are quite rare but do occur in models of the reliability of machinery, for example, where components are often thought of as either ok or broken.

• For mapping to actions, use a matrix[3] style of risk register.

• Try to avoid threshold risk levels for triggering actions or escalation. In the past this has been done with some safety models where components have been deemed completely safe once they are deemed safe enough. The residual risk has been ignored. Unfortunately, the cumulative effect of many remote chances can be too big to ignore. It is better to let the model accumulate all those tiny probabilities.

Alternative techniques to use if you can

The more traditional way to document models is to write a paper using the language and symbols of mathematics.

References

[1] Leitch, M. (2015). Integration in future risk management guidance and standards: results from a Risk Improvement Group survey.

[2] Leitch, M. (2012). The Risk Listing school.

[3] Leitch, M. (2003). Matrix Mapping: the easiest and best way to map internal controls.

Appendix A: Problems

Made in England