How to do Risk Assessment-Using Risk Categories


/ June 3rd, 2010/ Posted in How to do Risk Assessment / 2 Comments »

Risk Categories: Strategic and Operational

A client sent me a question today, which I quote with permission:

I’ve been tasked to go over the strategic (corporate) risk register done by the exec… The question I have is, there are 14 separate risk categories, while the operating depts. have been using 4.  Is it worthwhile to keep them consistent, or would it make sense in any universe to use different ones for strategic vs. operating risks?

I definitely want to cut the number of categories down from 14 to 4 or 5; please advise if this makes sense also.

Here is the short answer: there is no strict rule about whether operational and strategic risk assessment can use the same risk categories. Nor is there a prescription about the number of categories you must use. Rather, you would make those decisions based on how you need to manage your information. First, you work to identify risk using categories; then, the categories work for you to manage the results. Let me explain.

Risk Categories: Generic and Specialized

Aside from the question of scope (operational/strategic), risk categories fall into two classes: generic and specialized. The generic risk categories are the familiar ones that apply to any organization; here’s a partial list drawn from the Guidelines for Managing Risk in the Western Australia Public Sector:

  • economic
  • socio-political
  • national and international events
  • personnel/human behaviour
  • financial/market

Specialized risk categories are the ones that belong to a specific vertical (industry, profession, field or practice). They are categories of analysis that subject matter experts can bring to the table. Project risk categories are a good example – especially useful if they are arranged by project stage. Here is just a sample of risk categories that would be relevant to the analysis of, for example, an IT implementation initiative:

  • process and system training
  • process compliance and user acceptance
  • security and privacy
  • release management

How to Use Risk Categories

Use risk categories in two stages; there’s a kind of shifting gears in the way you use them.

Stage 1:  Peruse risk categories and consider each one to identify risk and create risk statements. As facilitator of the risk ID session, you present all of the risk categories that you can get your hands on (that are relevant), and that you have time to cover.

Get the session participants to consider the whole list, so that you “map” each individual viewpoint against each of the categories. It’s unlikely you’ll have time to do this line-by-line: send out the lists ahead of time, and then do a walk-through at the session. The idea is to use the risk categories to inspire people’s thinking and jog their work-related memories, so that they can formulate risk statements about the project at hand.

Stage 2: Once you have completed your risk ID, you may have a list of, say, 30 to 50 risks within a specific context. Now that you and the group have worked so hard to delve into each of the categories, you have to decide: how do you want categories to work for you?

Are they an administrative tool? You will likely want to sort on the material by department, business unit, risk owner, or by project stage. You might therefore need to create new categories or spreadsheet columns, and re-categorize certain risks. For example: something originally identified under the rubric of “Financial” may belong more properly under “HR” or “Marketing”, depending upon who is looking after mitigation. You could invent a code or category to coordinate mitigation, such as a communication plan to address 30% of the risks identified across various departments.

Are categories an analytical tool? It makes sense to arrange categories to reflect the perceived source of the risk – good for analyzing the strategic view of things. You might be able to discern where the most critical risks are coming from, or what function they are affecting, and draw useful conclusions. You can imagine the richness of the analysis if your department heads agree to categorize (accurately, with consistent criteria) an aggregated 250 risks across the organization in several columns.

There is no end to the nature and number of categories, nor a minimum. It all depends upon the number of risks, the complexity of your risk information, and what you want to get out of it. Sorting by categories helps you manage mitigation, as well as to interpret the risk profile and write your report.

You work to extract the risks from categories. Then you make the categories work for you.

If you enjoyed this post, make sure you subscribe to my RSS feed!

Tags: , , , ,

2Comments

  1. Edward
    2014/08/09 at 15:51:18
      How to Write a Risk Control Statement

    It is beneficial to constrain Risk Statements to a simple conceptual model (cause + effect) to better rank and manage the risks. It is a way to impose structure on complex reality.

    “Controls” could, similarly, be stated according to some consistent model.

    First, I believe that the audit function should be differentiated from the risk management function. See: http://riskcommentary.com/relationship-between-audit-and-risk-management/

    The definition of “controls” has expanded to encompass just about any action or function. As a consequence, the function of audit and control is confused with managing uncertainty (risk management).

    In my view, a “control” in a strict technical sense, such as a signing authority, is one element within all risk treatment/risk mitigation (synonymous).

    Mitigation can be literally anything that addresses the risk at the strategic or operational level. It could be a one-time simple action (such as calling a meeting between 2 persons); it could be a complex project that needs to be developed offline; etc. Risk financing is itself a treatment (hopefully the solution of last resort).

    Now, a model to guide the statement of a control — or any sort of treatment or mitigation — would show all the elements that you need to manage: how the control addresses the probability of occurrence, or the magnitude of the impact; whether it is put in place pre-event, or enacted post-event; etc.

    The question is, what level of detail is needed? Take Business Continuity Planning, for example. BCP needs to differentiate between preventative measures versus action taken during the emergency. Or take risk financing. Solutions in that domain need to quantify ‘residual risk’. But unnecessary analytical detail in the risk register will be a burden.

    Therefore it is up to the risk manager to strike the appropriate balance and capture the right degree of detail. It will vary with the type of business context.

    In my experience, what is critical in most administrative contexts is to list in the risk register:

    a) a summary description of the mitigation measure;
    b) the responsible lead;
    c) the due date;
    d) the status (to track progress on the mitigation);
    e) the cost/benefit.

  2. Sydney Lewis-Picard
    2014/07/31 at 12:16:18

    How about “How to Write a Control Statement”? We have PLENTY here on how to write a Risk Statement, but there should also be instructions on how to describe a control. Should it be a complete scentence that reveals wheather its detective or preventative? Should it refer to the “leads to” in the risk its accociated with?
    What are the rules for writing the scentence? Let’s get to it.

    Thanks.

Leave a Reply

Name required

Mail (will not be published) required

Website