Writing a good risk statement

I often review documents describing risks that fail to either make an impression as to the seriousness of the risks or fail to explain the cause and impact of those risks, both results leading to a less well informed risk decision by a non-specialist executive.

It is vital when stating a risk to be clear in communicating the various characteristics and components of the risk without assuming previous knowledge on the part of the reader. Here is the guidance that I often offer as part of my feedback.

A risk stated as “The data leakage prevention system may fail.” isn’t a risk. It’s just a statement of the failure of the control, similarly a risk stated as “There are no custom rules in the data leakage prevention system” or “The data leakage prevention system is not following vendor best practice” are both statements that tell us nothing about the Outcome or the Impact from the stated conditions.

There are a number of components or characteristics that may make up a risk including:

• Event – The conditions that must be present for the risk to occur.
• Likelihood – The probability that the conditions for the event will occur.
• Outcome – What will happen when the conditions are present.
• Impact – So what. What is the harm that will result from the outcome.
• Risk Factors – The conditions that increase the likelihood of the event and/or the harm from the impact.
• Control – A limiting factor that reduced the likelihood of the event and/or the harm from the impact.

At a minimum, a risk needs an Event that leads to an Outcome that results in Impact. So a minimal risk statement could be formed as:

There is a risk that <event> occurs leading to <outcome> that causes <impact> .

There are other ways to structure the order of the statement but without Event, Outcome and Harm there isn’t enough information for the uninformed reader to understand the risk. An example of a minimal risk structured as above is:

“There is a risk that a member of staff accidentally emails financially sensitive data to an external recipient leading to a data breach which results in regulatory enforcement.”

This risk statement could be supported with risk factors and control characteristics such as:

“The financially sensitive data is market sensitive information before the annual report is published, but the data leakage control is configured to look for financial reports and to prevent their external transmission, and the Outlook autocomplete function is disabled for the period of the production of the annual report.”

At this point, the statement of risk is clear about how the risk occurs, what it does if it occurs and how it is exacerbated or limited. What this risk statement doesn’t do is discuss the likelihood or expected occurrence of the risk. Where data exists to support the assertion the word risk can be replaced with a statement of the likelihood of the event as follows:

“There is a good chance that a member of staff will accidentally email financially sensitive data to an external recipient leading to a data breach which results in regulatory enforcement.”

This is difficult territory as there are no common definitions of the percentage quantification of the relevant terms such as: definite, almost certain, highly probably, quite likely, good chance, likely, probable, better than even, possible, unlikely, improbable, seldom, highly unlikely, rare, impossible. It is better to rely on numerical probability ranges rather than natural language to describe likelihood. For example:

“There is a 60%-70% probability that a member of staff will accidentally email financially sensitive data to an external recipient leading to a data breach which results in regulatory enforcement.”

If generating a numerical probability range is difficult due to uncertainty in the underlying data then it is better to avoid attempting to express that uncertainty by using less precise natural language estimates as these are likely to be misunderstood by the reader. Similarly, if the Impact can be reliably estimated it should be quantified in the relevant terms, such as how much a fine would be in a regulatory sanction.

“There is a 60%-70% probability that a member of staff will accidentally email financially sensitive data to an external recipient leading to a data breach which results in regulatory enforcement of a £450,000 fine.”

However, if the Impact estimation carries a high level of uncertainty then stating the possible range of Impacts is more useful to the reader than suppressing the uncertainty by misusing precise quantitative estimation.

In summary a risk statement such as:

“There is a 60%-70% probability that a member of staff will accidentally email financially sensitive data to an external recipient leading to a data breach which results in regulatory enforcement of a fine between £200,000-£450,000.”

is much better than:

“There is a good chance that a member of staff will accidentally email financially sensitive data to an external recipient leading to a data breach which results in regulatory enforcement of a large fine.”

But if you can’t reliably estimate the Likelihood or Impact the following works well enough to communicate the nature of the risk, even if it leaves the reader to prioritise against other similar risks competing for investment or resource to manage them:

“There is a risk that a member of staff accidentally emails financially sensitive data to an external recipient leading to a data breach which results in regulatory enforcement.”

NOTE: Since writing this blog I have developed my approach to identifying security risks using a ‘security risk universe’ that works well with these formalised risk statements. See my related blog here.

UPDATE: I have transformed the risk universe described in the blog post in the previous NOTE into the Open Information Security Risk Universe (OISRU) hosted on Github. This is an editable form that we can change and update, the licence is free. Please read, review, edit and send PRs! There is another description of risk statements and risk scenarios and how to use them with bow-tie diagrams in the ‘How to Use’ section of the OISRU that extends this blog post and you should read.