risk = magnitude + uncertainty<\/pre>\r\nIf we refer back to the first example, this isn\u2019t so different from\r\nrisk = likelihood + severity<\/pre>\r\nWe just have the terms in a different order.\r\n\r\nHowever, it's sometimes more complicated. Remember that standard I struggled with? Well, here\u2019s the eventual methodology I pulled from a several page-long description.\r\nrisk = L2 * C \r\nwhere<\/em> L2 = L1 * V \r\nand<\/em> L1 = A * T<\/pre>\r\nOr...\r\nrisk = (((A*T)*V)*C)<\/pre>\r\n(Actually, this formula is even more complicated than it seems but that\u2019s a discussion for another time.)\r\n\r\nAgain, 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\u2019t been done and you will have to decipher the standard yourself.\r\n\r\nIf I didn't understand how to unpick a text to find the methodology, then I couldn\u2019t 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.\r\n\r\nSo 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\u2019m 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.\r\nMetrics<\/h1>\r\nFinally, whichever risk assessment methodology we use, we need a set of values\u00a0to apply to each factor to help us determine a rating\u00a0for 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.\r\n\r\n \t- Quantitative values allow you to easily order and compare risks<\/li>\r\n \t
- Qualitative statements make it easier to discuss or describe factors<\/li>\r\n \t
- Color coding provides a visual key to\u00a0differentiate between different ratings<\/li>\r\n<\/ul>\r\nFor ease, I will refer to these collectively as metrics. An example set of basic metrics is shown below.\r\n
\r\n\r\n\r\nValue<\/strong><\/td>\r\nDescription<\/strong><\/td>\r\nColor code<\/strong><\/td>\r\n<\/tr>\r\n\r\n| 1<\/td>\r\n | Low<\/td>\r\n | Green<\/span><\/td>\r\n<\/tr>\r\n\r\n| 2<\/td>\r\n | Medium<\/td>\r\n | Amber<\/span><\/td>\r\n<\/tr>\r\n\r\n| 3<\/td>\r\n | High<\/td>\r\n | Red<\/span><\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\nAlthough it might seem more complicated initially, having all three options available to start with makes your assessment easier in the long run. This\u00a0allows you to use the appropriate value or description to suit the\u00a0stages of the process\u00a0while ensuring that these are consistent throughout your assessment.\r\n\r\nFor 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.\u00a0The important point\u00a0here is that 'Low' now has a distinct and fixed meaning\u00a0and is just as explicit as a value of 1.\r\n\r\nThe same basic approach can be used for sets of metrics with more variables or options. Metrics with values from 1 - 5 are quite common.\u00a0For simplicity, we are going\u00a0to stick with three values for the rest of this section.\r\n\r\nOnce you have your metrics, you just insert these into whatever tool or template you are using.","rendered":"
\nThe 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\u2019re going to be successful.<\/em><\/p>\n
\n <\/p>\n 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\u2019s worth clarifying what I mean by designing the framework because this is different from the scoping we conducted at the beginning of the project.<\/p>\n Here, I\u2019m 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\u2019t 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.<\/p>\n In many ways, this is the critical part of the whole process so couldn\u2019t we have covered this earlier?<\/p>\n 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\u2019t 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.<\/p>\n 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.<\/p>\n But if you are just getting started as a risk manager and haven\u2019t a standard to follow, there are a few benefits in leaving the question of methodology and metrics until late run the process.<\/p>\n The first is that you don\u2019t 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.<\/p>\n Another reason to wait is that you may discover that there is already a standard in use. It\u2019s 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.<\/p>\n The last reason is that if there\u2019s 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\u2019t know what\u2019s going to be more appropriate until you have reached this point in the process.<\/p>\n However, no matter whether it\u2019s before you get started or once you\u2019ve 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\u2019ve identified to give each a value and subsequently put these into order.<\/p>\n \n The elements of a framework<\/h1>\nCategories<\/strong> –\u00a0 a set of imaginary buckets or folders into which you can group similar threats.<\/p>\nMethodology<\/strong> – the formulaic definition of risk you will use for your actual calculations. This defines risk as a set of components and describes how they interact.<\/p>\nMetrics<\/strong> – the values you will use to describe and \u2018measure\u2019 each component and the risk itself.<\/p>\n<\/div>\n <\/p>\n It\u2019s 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\u2019t always as straightforward as it seems.<\/p>\n 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\u2019t the only time an SOP or guide has required significant effort to unpick. But if you can\u2019t define these elements clearly – whether you\u2019re the designer or the user – then your evaluation will be shaky and might not work at all.<\/p>\n Luckily, there\u2019s a simple way to tackle each of these. Let\u2019s start with categories.<\/p>\n Categorization<\/h1>\nTo 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.<\/p>\n 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\u2019s 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.<\/p>\n It\u2019s 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.<\/p>\n But deciding upon these categories can be deceptively difficult. There are three reasons for this.<\/p>\n Firstly, categorization can be interpreted as reflecting ownership.\u00a0 So if you have a category called \u2018financial\u2019 then it\u2019s 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.<\/p>\n 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.\u00a0 For example, if you have \u2018flooding\u2019 as a category, you\u2019re 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.<\/p>\n 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.\u00a0 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.<\/p>\n 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.\u00a0 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\u2019s still valid today, more than 15 years later.<\/p>\n Thirdly, it can be hard to get the right balance between categories that are too broad and categories that are too specific. There\u2019s a \u2018Goldilocks\u2019 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.<\/p>\n
\nImagine you needed a way to categorize sports teams. \u2018US Sports teams\u2019 would be a very broad category, but \u2018The New York Giants\u2019 or ‘The Mets\u2019 are specific teams. Instead, ‘NFL Teams\u2019 and \u2018MLB Teams\u2019 might be useful categories.<\/em><\/p>\n
\nA simple way to help keep things under control is to just count the number of categories.\u00a0 If you only have two (e.g. internal or external threats) it\u2019s probably too few.\u00a0 On the other hand, if you have 25 categories, that\u2019s probably too many.<\/p>\n I think that somewhere between six and ten is usually enough. When I designed DCDR, I felt that the six below covered most eventualities<\/p>\n \n- Market \/ Financial<\/li>\n
- Statutory (regulatory) \/ political<\/li>\n
- Safety \/ security \/ health<\/li>\n
- Environment<\/li>\n
- License to operate \/ reputation<\/li>\n
- Infrastructure<\/li>\n<\/ul>\n
(There\u2019s also an \u2018other\u2019 option for users to add their own.)<\/p>\n This isn\u2019t a hard and fast set of categories but I don\u2019t think I have had to use the other category so far: most of what I\u2019ve been considering can be slotted into one of these categories.<\/p>\n So spend some time thinking about what the right categories are for your organization.\u00a0 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.<\/p>\n Methodologies<\/h1>\nNext is the methodology. The methodology is essentially the formula you\u2019re 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.<\/p>\n 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<\/p>\n risk = likelihood + severity<\/pre>\nAll I need to do is add the metrics and off I go.<\/p>\n However, although this definition is easy to use as a methodology, it\u2019s not as useful for more general discussions about risk as we haven\u2019t actually defined what risk is.<\/p>\n 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\u2019s made of. Essentially it\u2019s the difference between describing a car as a machine that has an engine, wheels and seats (what it\u2019s made of) instead of saying it\u2019s something for moving people over long distances on land (what it is).<\/p>\n 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 \u201cthe effect of uncertainty on objectives.<\/em>\u201d (ISO 73) That obviously requires a bit more work than the previous example. However it\u2019s not as complicated as it might seem at first. If we take a closer look, two main components jump out :<\/p>\nthe effect (1) of uncertainty (2) on objectives<\/p>\n 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<\/p>\n risk = magnitude + uncertainty<\/pre>\nIf we refer back to the first example, this isn\u2019t so different from<\/p>\n risk = likelihood + severity<\/pre>\nWe just have the terms in a different order.<\/p>\n However, it’s sometimes more complicated. Remember that standard I struggled with? Well, here\u2019s the eventual methodology I pulled from a several page-long description.<\/p>\n risk = L2 * C \r\nwhere<\/em> L2 = L1 * V \r\nand<\/em> L1 = A * T<\/pre>\nOr…<\/p>\n risk = (((A*T)*V)*C)<\/pre>\n(Actually, this formula is even more complicated than it seems but that\u2019s a discussion for another time.)<\/p>\n 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\u2019t been done and you will have to decipher the standard yourself.<\/p>\n If I didn’t understand how to unpick a text to find the methodology, then I couldn\u2019t 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.<\/p>\n 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\u2019m 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.<\/p>\n Metrics<\/h1>\nFinally, whichever risk assessment methodology we use, we need a set of values\u00a0to apply to each factor to help us determine a rating\u00a0for 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.<\/p>\n | | | | | |