The third risk register example, like the second, seems quite good as a practical tool. It does have a column beside the Likelihood and Consequence to calculate the resultant risk ranking (‘risk grade’ as they call it). I’m not sure about how they’re using risk category; also, there’s nothing on tolerance or controls.

But what jumps out at me is how they are using the Describe Risk column (circled). In the first item I count at least 5 issues that could be separate risk statements. That would be better, otherwise you don’t know what you’re assessing. If you compiled a list of 50 risks in a similar discursive manner, you would have a lot of text impossible either to rank accurately, or effectively manage.

In this case, where they are talking about developing courses overseas, some analysis offline might let them formulate precise risk statements addressing upstream causes. Then they could devise mitigation plans to engage with the foreign university and help ensure the viability of the offshore activity. But the concept of risk implied here is not one focused on objectives; but rather the traditional one of exposure to assets.

Back to our review of sample risk registers. The last one has the sixth column labeled Contingency/Action. There is a difference, and it’s helpful to sort out all the various ways to respond to risk. For example, people often characterize risk financing as a transfer of risk – it’s not.

In any case, these finer distinctions are not indicated in this particular risk register. Nor (like two of the others) does it have columns for controls, tolerance, and the valuation and allocation of residual risks, which you would need in a project management risk register.

In conclusion, this review of sample risk registers shows that risk managers need to pay attention to detail in two ways:

a. Number of Columns. The number of columns will generally indicate the depth of analysis and must correspond to the business requirements. Too few columns will give you just lists of general information, without incisive analysis to support decision-making, or ways to track progress on mitigation.

b. Column Labels. Column headings are telling, and the examples discussed revealed some confusion in the interpretation of terms. Your choice of headings should reflect a clear idea of the risk process.

The new Risk & Insurance Management Society online course Special Case Studies in Risk Management contains a fuller discussion of the risk register, its associated ERM tools and templates, and the implications for selecting ERM software. We provide a comprehensive risk register for project management and discuss each of the 17 columns of analysis in detail.

Link the two clauses by a phrase such as “leads to”; “causing’; “results in” (without using conditional terms like “might”; “may”; “could”).

State the cause as an event, or as a set of conditions.

State the effect upon the program goal, objective, or value criterion under consideration.

Identify and state the risk that lies as far upstream as is practical to manage in the chain of cause and effect.

Risk Statement Examples

context A:
Manufacturing process, using a critical fabricated aluminum part sourced from a supplier which has just been bought out.
risk statement:
Changes to management of supplier X leads to faulty weld, heat treat and QA of our special-order welded 6061-T6 aluminum part.

context B:
Private school language program, expecting foreign student contingent from a country where political unrest is imminent.
risk statement:
Communication ties severed with institutional contact Mr. X within next 3 weeks results in inability to arrange permissions, visas and travel for September cohort.

context C:
Custom web security firm plans to set up a new office in Hong Kong. They are inexperienced in international business and getting help to apply for a business license.
risk statement:
Professional services Co. XYZ prepares deficient business license application, causing delay to planned September launch.

Explanation of Risk Statements

Notice that the statements could easily have read, for example, in Context A: “Customers injured” (characterizing this as a product liability issue); or in Context B: “September students don’t show up”; and in Context C: “Office opens late.” But the offhand, short keyword approach to risk ID doesn’t serve you very well.

I identified causal events, as far upstream, so to speak, as I could, in the hope of taking action to prevent the risk before it even matures.

So in Context A, I didn’t focus on the end product failing; nor on the faulty part entering our plant. I focused on the supplier’s new management somehow compromising the weld, heat treat and QA process. Can we take steps to guarantee that process?

In Context B, it was the communications drop that was going to cause our risk to manifest. Therefore, could we look at back-up communications channels?

In Context C, there is still time to do due diligence on firm XYZ and explore options, and so build extra assurance that the Hong Kong business license application will succeed.

At the same time, by describing the effect on our plan, I have made it possible to think more clearly of alternatives to the plan and post-event mitigation (contingencies).

You can imagine a risk register of, say, 50 risks on a critical initiative. If they are all just vague keyword phrases, then their assessment and associated treatment plans will be just as vague. But if the risk statements are complete, time-specific, directly targeted to goals, and indicate upstream opportunities for prevention and mitigation – then you will have a tightly defined risk profile that you can act on.

Risk Statements vs Risk Categories

I’m creating the first draft of the exam for an upcoming Enterprise Risk Management certification, and in the text they are using, the idea of writing a cogent risk statement is not addressed. But I think it is relevant: recent years’ risk management surveys show that people have little confidence in the effectiveness of their risk methodology.

There is a distinction between a risk category and a risk statement. Many people identify risks with two-word phrases: “reputation risk”; “construction risk”, and so on. These are not risk statements, they are general rubrics within which you must specify the risk. I’ve heard of consultants presenting lists of risk categories as if they represented the sum total of identified risks. The trouble with that is, while a two-word phrase is fast and easy to say, the threat that it denotes in relation to your organization is unsaid.

Now lists of risk categories, derived from loss history in a given industry (often sourced from brokers) are undoubtedly useful to help you identify relevant risks – but you have to use them correctly. They are not a substitute either for a comprehensive risk identification exercise, nor for writing complete risk statements.

A complete risk statement, whether or not inspired by or derived from a risk category, is formulated in direct association with a task, goal, objective or value criterion in your business or organizational plan. In the context of Enterprise Risk Management, the concept of risk goes beyond potential loss due to exposure of assets to hazards. The ISO 31000 defines risk as the “effect of uncertainty on objectives”. The older AS/NZS 4360 says: “the chance of something happening that will have an impact on objectives”.

You can find further discussion, with examples of good and poor risk statements, in the prior version of the ERM Guideline I wrote for BC government (section 2.3.2, page 20). You can email me if you want to see this — the current version doesn’t have it.

In this series on risk methodology, so far I’ve covered:

How to do Risk Assessment-Establish the Context–Part 1
How to do Risk Assessment-Establish the Context–Part 2
Pitfalls in Writing the Risk Context
Using Risk Categories

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.

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.