The assessment needs a clear framework to help you process the information you have and analyze the risks. Sometimes you will have one prepared but at other times, you need to do this yourself. Whatever the situation, you need to know what goes into designing and building a framework if you’re going to be successful.

This guide is broadly chronological, laying out the steps to follow from start to finish for your risk assessment. So it may seem odd that designing the framework appears this late in the process. There are a couple of reasons for this. But first, it’s worth clarifying what I mean by designing the framework because this is different from the scoping we conducted at the beginning of the project.

Here, I’m talking about the process for the actual evaluation itself: the methodology and metrics you will use to generate values for each risk and the categories you will divide these into. Without this step, you will still have gained a great deal of insight into the organization and there will be some risks that clearly require attention. However, without the evaluation, you don’t have a way to compare risks quantitatively nor a way to put them into order. Grading and ordering risks like this is a key to producing an actionable risk management plan.

In many ways, this is the critical part of the whole process so couldn’t we have covered this earlier?

The short answer is yes and there will often be times when the methodology is already decided for you. For example, where there is an existing risk management procedure or an industry standard to follow. In these cases, you wouldn’t have to make the decision about the approach to use yourself. Instead, you will spend time in your interviews ensuring that people are familiar with the terminology and methodology you are using as this will help them understand the final report.

Moreover, as you become more experienced you will tend to favor a methodology and approach which you will use where there is no industry or corporate standard to apply. Therefore, you will know the answer to many of the following questions before you get to this stage.

But if you are just getting started as a risk manager and haven’t a standard to follow, there are a few benefits in leaving the question of methodology and metrics until late run the process.

The first is that you don’t get distracted and use up a lot of time trying to come up with an approach. Finding or developing a methodology and set of metrics can take a lot of time which can delay the start of your research and interview, delaying the assessment itself.

Another reason to wait is that you may discover that there is already a standard in use. It’s not uncommon to find that health and safety, operations or finance have risk management processes in place which you can adapt for your assessment. This saves the time and effort of building something new and makes things much more efficient as people will be using terms and process with which they are already familiar.

The last reason is that if there’s absolutely nothing in place, you will be able to determine the kind of approach the organization will be most comfortable with as you conduct your research and interviews. For example, a process-driven engineering firm like XYZ Co will be familiar with data-heavy reporting so a more quantitative approach would be appropriate. However, if you were working with a more creative team like a design firm, then a more qualitative approach might be a better fit. The point is that you won’t know what’s going to be more appropriate until you have reached this point in the process.

However, no matter whether it’s before you get started or once you’ve developed a good understanding of the firm, at some point you have to define the framework for the evaluation. This framework is what you are going to use to analyze the risks you’ve identified to give each a value and subsequently put these into order.

It’s important that you understand how these different parts of the framework interact because you are either going to be the person who has to design them, the person who has to explain them to others or the person that has to unpick a standard or SOP to turn it into something workable. This last point isn’t always as straightforward as it seems.

There was one US standard that probably took me 20 hours over a period of weeks to decipher and turn into a clear framework and that certainly wasn’t the only time an SOP or guide has required significant effort to unpick. But if you can’t define these elements clearly – whether you’re the designer or the user – then your evaluation will be shaky and might not work at all.

Luckily, there’s a simple way to tackle each of these. Let’s start with categories.

Categorization

To manage your risk management system, you need to have a way to categorize your threats. This is a key part of being able to structure your risk assessments and you need to identify a set of imaginary buckets or folders into which you can group similar threats.

This also helps with information gathering, as data on a specific threat category might be grouped together, and it can be extremely useful when it’s time to address the risks, since one action could help mitigate a whole category of threats. Finally, these categories will also help you identify trends and patterns and start to develop an overall picture of your risk environment.

It’s worth spending some time getting this right as it will have an influence on your risk management system and once you start using a set of categories, changing them can be messy.

But deciding upon these categories can be deceptively difficult. There are three reasons for this.

Firstly, categorization can be interpreted as reflecting ownership.  So if you have a category called ‘financial’ then it’s not going to be a surprise if the CFO assumes that this is her responsibility. Sometimes, as with the CFO example, ownership could be straightforward but sometimes it leads to turf wars over who owns a set of risks. Trying to get people to agree can therefore become complicated.

The second reason is more problematic. Depending upon how you describe the threat category you can end up talking about the impact and not the threat itself.  For example, if you have ‘flooding’ as a category, you’re talking about the effect (the impact), not the cause (the threat from hurricanes). This will influence all of your thinking throughout the process and it can make discussions very complicated and sometimes result in you talking around in circles.

This happened to me once when a co-worker and I sat in a room for two days with a whiteboard and lots of sticky notes, trying to design a series of threat categories.  By the end of day one, we were confusing ourselves, going around in circles and had stopped talking to each other so we had to quit for the day.

When we came back in on day two, we realized that we had stopped talking about threats at one point and had started to add effects and impacts.  We had flummoxed ourselves by mixing threat categories in with impact descriptions. Once we identified this problem, we were quickly able to fix things and built a system that’s still valid today, more than 15 years later.

Thirdly, it can be hard to get the right balance between categories that are too broad and categories that are too specific. There’s a ‘Goldilocks’ point at which the categories are specific enough to keep similar items together but not so specific that you end up with a list of individual threats.

Imagine you needed a way to categorize sports teams. ‘US Sports teams’ would be a very broad category, but ‘The New York Giants’ or ‘The Mets’ are specific teams. Instead, ‘NFL Teams’ and ‘MLB Teams’ might be useful categories.

A simple way to help keep things under control is to just count the number of categories.  If you only have two (e.g. internal or external threats) it’s probably too few.  On the other hand, if you have 25 categories, that’s probably too many.

I think that somewhere between six and ten is usually enough. When I designed DCDR, I felt that the six below covered most eventualities

• Market / Financial
• Statutory (regulatory) / political
• Safety / security / health
• Environment
• License to operate / reputation
• Infrastructure

(There’s also an ‘other’ option for users to add their own.)

This isn’t a hard and fast set of categories but I don’t think I have had to use the other category so far: most of what I’ve been considering can be slotted into one of these categories.

So spend some time thinking about what the right categories are for your organization.  Getting this right will help shape your discussions and make it easier to analyze the results without becoming too specific: that’s what the individual threat description is for.

Methodologies

Next is the methodology. The methodology is essentially the formula you’re going to use to calculate the risk and this is going to be based on your definition for risk. Sometimes the definition does the work for you but at other times, you need to do a little work yourself.

For example, in many cases the definition of risk is likelihood plus severity which is great for methodology because I just add the two components together. Therefore I can write out my methodology like this

risk = likelihood + severity

All I need to do is add the metrics and off I go.

However, although this definition is easy to use as a methodology, it’s not as useful for more general discussions about risk as we haven’t actually defined what risk is.

So you will often come across definitions that address risk more as a concept which makes it easier for people to understand what a risk is, rather than what it’s made of. Essentially it’s the difference between describing a car as a machine that has an engine, wheels and seats (what it’s made of) instead of saying it’s something for moving people over long distances on land (what it is).

Unfortunately, a description of risk as a concept might need some extra work to turn it into a methodology. For example, if we use the ISO definition, we get risk is “the effect of uncertainty on objectives.” (ISO 73) That obviously requires a bit more work than the previous example. However it’s not as complicated as it might seem at first. If we take a closer look, two main components jump out :

the effect (1) of uncertainty (2) on objectives

If we want to turn this into a methodology we need to know how much of an effect we are talking about and how much uncertainty is involved. So we can combine the magnitude of the effect plus the degree of uncertainty to determine our risk which gives us

risk = magnitude + uncertainty

If we refer back to the first example, this isn’t so different from

risk = likelihood + severity

We just have the terms in a different order.

However, it’s sometimes more complicated. Remember that standard I struggled with? Well, here’s the eventual methodology I pulled from a several page-long description.

risk = L2 * C 
where L2 = L1 * V 
and L1 = A * T

Or…

risk = (((A*T)*V)*C)

(Actually, this formula is even more complicated than it seems but that’s a discussion for another time.)

Again, if you are using a standard or pre-existing procedure, then this work should have been done for you. However, you should still be able to unpick things yourself because you need to be able to link the standard to the process and there are times when the work hasn’t been done and you will have to decipher the standard yourself.

If I didn’t understand how to unpick a text to find the methodology, then I couldn’t have pulled that horrific formula from the standard. Also, if I’d given someone the formula and asked them to check it, they’d need to be able to work backwards to the standard in order to check that my formula fits with the description.

So even though this might seem unnecessarily detailed and it might feel as though we just ditched the last S in KISS, this is a situation where the explanation is more complicated than the process. In a moment, I’m going to show you how everything gets pulled together but before that, we need to talk about the final part of the framework: grading and metrics.

Metrics

Finally, whichever risk assessment methodology we use, we need a set of values to apply to each factor to help us determine a rating for individual factors and the overall risk. This can be achieved using numerical values, qualitative statements or color coding. Applying scales like these allows us to grade and order our risks which helps with prioritization and comparative analysis.

• Quantitative values allow you to easily order and compare risks
• Qualitative statements make it easier to discuss or describe factors
• Color coding provides a visual key to differentiate between different ratings

For ease, I will refer to these collectively as metrics. An example set of basic metrics is shown below.

Although it might seem more complicated initially, having all three options available to start with makes your assessment easier in the long run. This allows you to use the appropriate value or description to suit the stages of the process while ensuring that these are consistent throughout your assessment.

For example, you can use Low / Medium / High as descriptive terms during discussions which then become numeric values in your assessment template. These are then highlighted with the appropriate color to provide a visual key. The important point here is that ‘Low’ now has a distinct and fixed meaning and is just as explicit as a value of 1.

The same basic approach can be used for sets of metrics with more variables or options. Metrics with values from 1 – 5 are quite common. For simplicity, we are going to stick with three values for the rest of this section.

Once you have your metrics, you just insert these into whatever tool or template you are using.