This post describes how to structure and populate a good risk register. I will describe the key components, how they interlink and the recommended information requirements.
the risk register – what is it?
When you internet-search the term “risk register”, plenty of examples and tutorials will yield. Often, these samples are very well presented, easy to comprehend and relatively simple to adapt to your organisation’s specific circumstances. Having said that, at closer inspection many of them don’t pass muster even for the smallest and minimally complex organisations.
The image below represents a sample of what you will find with an internet search:
- has a clear structure
- outlines a risk of possibly loosing key employees
- assigns a medium impact to it
- allocates responsibility to the HR department
- and leaves room for more risks
So you might wonder what is missing. After all, a risk is identified, its potential impact is being considered, and somebody is assigned to the risk. All sounds good, or doesn’t it?
The good news is that risk identification has taken place in this imaginary organisation. Furthermore, all three statements shown in this example are valid statements. However, they need to be brought into proper context and quantified. Additionally, some key ingredients need to be added. Hence, it is highly likely that this organisation needs to upgrade the register to reap the benefits of good ERM.
The risk of “loosing key staff” – as shown in the table above – is a real issue for many organisations. However, the statement needs context and explanation.
- what does “key” really mean?
- how does the “medium” fit into the strategy/priorities of the organisation. In other words, what would “low” or “high” signify?
- and finally, what is the duty of the HR-department?
The model risk register
Let’s leave this example aside and move on to the build-up of a comprehensive, clear and more tangible risk register. How does a good risk register look like? I focus on content and the key building blocks. IT-considerations and data analytics are the subject of a different conversation.
High Level Structure
|The header describes the risk at sufficient level of detail. I call this the “ID” block.|
|Right underneath the ID-block we draw three vertical blocks. They encompass quantification, risk treatment undertakings and the respective outcomes. This is the “quant/mod” block.|
|In the blocks at the bottom we record and store important additional information, such as follow-up actions and access rights. I call one of them the “add-on” block and the other one the “gov” block.|
Key components are:
- A unique risk identification. This can be a number or an alphanumeric code; you can decide to use existing internal codes or just a plain integer. Both approaches have advantages and disadvantages.
- classification: risks need to be grouped following a pre-determined nomenclature and structure. You can use your own one or you can follow the guidance of the respective regulatory body or any other system that is suitable. Important is to cover ALL activities that your company is undertaking! The classification should span 2-3 levels for easy grouping and identification. Going back to our example, level 1 could be “operational risk”; level 2 “human resource risks” and level 3 “staff”.
- description: provide a basic description of the risk in free text form.
- impact: qualitative comments pertaining to expected impact should the risk materialise.
- And importantly, who is responsible for managing this risk.
|“quant & mod” blocks|
quant block 1
The block on the very left displays estimates of likelihood and corresponding severity should the risk under consideration materialise. These values – as the name implies – should be numeric. Best practice and knowledge must be applied when determining them. Preferably, a solid probabilistic model is used. Alternatively, deterministic scenarios might be used or past experience is taken as a reference.
Generic statements like “often” or “expensive” are easy to come up with. However, they are very vague. Hence, try to use quantitative statements as often as possible.
Having said that, it is crucial to be cognisant and explicitly note uncertainties associated with any projections (regardless of method) made in this section.
In a next step, benchmark the outcome against your organisation’s risk appetite to determine whether any treatment is necessary. This benchmarking is important to ensure that treatment efforts are spent on risks that really matter.
The middle block describes the chosen treatment actions in detail; furthermore, treatment costs are elaborated on.
quant block 2
The block to the right contains similar information as the one on the very left. However, all values and conclusions are recorded POST the mitigation/treatment efforts have taken place. Again, scale the values against the risk appetite. Furthermore, compare the outcomes to the actual cost of treatment. And lastly, note the the effectiveness and efficiency of the treatment.
These latter points are crucial. One needs to determine and decide whether the treatment(s) achieve their objectives and what the cost/benefit of the treatment is. For instance, if the treatment of a certain risk costs “1.25” to cure a non-recurring impact of “1”, then it is likely not worth the effort!
In our example we would have specified what we mean by “key staff”. Henceforth, it will be easier to assign a probability and an impact should that individual or team leave. As a mitigant, you can think about development opportunities, flexible work arrangements, incentives and other measures.
Certainly, the “ID” and the “quant/mod” blocks are the most challenging and interesting components of the risk register. Populating those blocks often leads to in-depth discussions and sometimes heated arguments amongst all the contributors. But it’s always interesting and often fun to travel this segment of the ERM-journey. Having said that, a risk register without the remaining two blocks is almost like a house without basement! Hence, I strongly recommend completing the bottom two blocks as well.
You need to determine how often you will review each entry. Some risks change very rapidly. Take Cyber, where the risk landscape evolves constantly. Hence, Cyber-related risks need to be reviewed very frequently. At the other end of the spectrum, certain operational risks (under most circumstances) evolve much slower. Hence, your organisation can review these less frequently.
The second component of the add-on block are considerations are about additional classifications. Whilst we have grouped risks already in the “ID” block, it is advisable to do some more classification at this stage. Highly recommended is to classify or rank risks according to impact on strategy and materiality. Importantly, you should generate a “top 10” list of the risks that really really matter to your organisation. I borrow a term from a global consulting company: McKinsey make explicit reference to “the company’s big bets”.
And last but absolutely not least: you need to establish linkages between individual risks should they correlate. This is key, even if the correlation at first sight appears marginal only.
And finally, some important “housekeeping” matters complete the register:
- assign an “owner” of the entire risk register. This person/function is the overall owner of the risk register. Note though, that the owner of the register is (in most cases) different from the risk owner!
- state the author of the current register (in smaller organisations, this might be the same person/function as the “owner)
- add a version number, and a date(s) for upcoming general revisions
- make reference to the register’s exact storage location
- determine “access rights” and “confidentiality”; the challenge is to find the right balance between being transparent and inclusive, whilst keeping some key strategic matters confidential. For instance, in the case of a key strategic risk, most information, especially the treatment and the impact, might be kept strictly confidential.
the gist of it
In this blogpost, I describe the set-up and design of a functional and comprehensive risk register. Six interlinked core components make up a complete register. If you have questions, kindly contact us via the social media buttons below.