Communicating Risks: A 3-part Statement

Stating risks in a clear, concise, and consistent manner enables more effective communication and risk prioritization.

why care?

How many times have you tried to explain a risk and for it not to be understood? How many times have you had to listen to someone talk for many minutes (or more!) to try to grasp the issue that they are trying to tell you? When you are sharing risks with people from outside of your area of expertise this only gets more difficult. Time is wasted and risks are not understood. Imagine if there was an easier way…

The 3-part statement

Formatting the risk into a consistent statement not only forces you to really clarify what the risk is, it also greatly improves its consumption by others.

Because of <a cause>

There is a risk that <an event will occur>

Resulting in <a consequence>

The Single Responsibility Principle (SRP)

Yes, the SRP is one of the SOLID principles, but it is equally valid for many other situations, including communication of risks.

Each risk statement should only be concerned with one thing. This makes it clearer to reason with, prioritize, and mitigate.

The Cause

What is the reason that something could happen?

There are many ways to identify both known and unknown causes, and we will cover that in another article. Just try to be as specific as you can. A couple of examples:

Because of our use of the third party library X…

Because of our storage of PII in our production db…

The Event

What is the thing that could happen?

A given cause can lead to many different events, and so many risk statements. This is good! Don’t try to consolidate them, and at this point don’t try to prioritize or remove statements. Also, you could have the same event occurring from different causes. Again, capture them all as they may have different priorities and mitigation strategies.

Examples of potential events for the cause “Because of our use of the third party library X…”:

there is a risk that there will be dependency issues…

there is a risk that the library will be removed…

there is a risk that security vulnerabilities exist…

The Consequence

What will the result be if the event occurs?

Again, any given event could result in multiple consequences, so these should become separate risk statements.

Examples of potential consequences for the cause and event “Because of our use of the third party library X, there is a risk that there will be incompatible dependencies…”:

resulting in an inability to upversion

resulting in an inability to use other libraries

resulting in an inability to access all features

Next Steps

With a clear and consistent risk statement format it is now much easier to prioritize which risks to tackle and identify mitigation strategies for them. We’ll look at effective ways to do this in a future article.

The bottom line

Because of unclear, verbose, and inconsistent risk communication, 

there is a risk that your most critical risks are not shared, understood, or prioritized, 

resulting in severe damage to your business.