Writing Better Risk Statements

I found this post on my computer. I can’t remember where it originally was posted (if it was at all), but I found it useful and thought I’d repost it again.

Articulating risks in a clear and concise manner can greatly assist your company in making the right decisions. A typical example of poor communication of risk will go something like this:

You:  New vulnerability called heartbleed. It’s very serious.

Manager: What is the impact?

You: Anything that uses OpenSSL is potentially exposed.

Manager: What uses OpenSSL?

You: Everything

Manager: Are we hacked?

You: It’s not that simple.

Manager: Why is this more serious than the last one?

Let’s look at how we can improve it:

Step 1. Structure your message

Writing a risk statement is essentially storytelling. When it comes to figuring out how to structure one, it can often help to look at the world of news journalism.

There’s this one journalistic trope I really like called the Inverted Pyramid. This is used by virtually every newspaper in order to better structure and prioritize the facts of a given story.

Although I’m not telling you to write your risk assessment like something you would see in the Telegraph or The Times, this is something totally worth learning, as it’ll make it easier to understand by non-technical readers. Here’s how it works.

Step 2. The headline

In a piece of text written in the Inverted Pyramid style, the first paragraph essentially encapsulates the story. It contains the “5 Whys” (Who, What, Where, When & Why). The measure of a successful first paragraph will be whether it allows the reader to understand the essence of what’s going on, without having to read any further. If you were talking about Heartbleed, for example, it might look something like this:

“There was a vulnerability discovered moments ago called heartbleed. It exists in the OpenSSL cryptography library, which is used by millions of servers for secure communication.”

Step 3. Add detail

 The following paragraphs should then add more detail. The more pertinent the detail to the event or story, the further up it should appear in your risk assessment. Using the example of Heartbleed, you’d talk about the consequences of the vulnerability, and its impact:

“This flaw could see an attacker steal a server’s private keys, session cookies, and passwords, and poses a risk to secure online communication worldwide.”

“It is estimated that around 17% (or 500,000) of the Internet’s secure servers are vulnerable to Heartbleed. The vulnerability does not affect servers running other TLS implementations, such as GnuTLS, Mozilla’s Network Security Services, or Microsoft’s own TLS implementation.”

Step 4. Contextualize

With the pertinent details out of the way, now you have an opportunity to contextualize the vulnerability before you relate it back to the reader. Feel free to mention technical details, statements by other IT departments, or what you know about your environment.

One you’re happy that the reader is sufficiently informed about how the vulnerability works, and the risk it poses to affected systems, you should then highlight the relevance to the reader and to the organization.

“This vulnerability is present in a large percentage of our IT infrastructure. Presently, there is no known detection or audit mechanism available to determine if we are being attacked, or were attacked. The fact that our encrypted traffic could be read by others creates a high risk exposure.”

Step 5. Call to action

A call to action is essentially what it sounds like. You’re asking the reader to do a particular thing. In the context of a risk statement, it might read something like this:

“Right now, I am going to start an audit of our systems to see the severity of our exposure to Heartbleed. Once that’s finished, I will start patching immediately. Please arrange an all-hands meeting later this afternoon.”

The action itself depends on your needs. It could be as large as asking the reader to assign more funds or employees to a particular problem, or as small as simply asking them to email you if they have any further questions.

Whatever it is, if you include all of these elements, your risk statement will allow you to properly articulate the risk to your readers. They’re now in a better position to understand the risk, and act upon it.

Step 6. Perfecting your text

Before you wrap up and pat yourself on the back for a job well done, ensure that your risk assessment reads well. In addition to getting your grammar and spelling spot-on, you should always try to make sure your assessment flows well.

I know it sounds a little bit silly, but try reading your piece aloud to yourself. Whenever I do, I always catch a mistake that I missed in proofreading.

If you’re in a crowded office environment where that wouldn’t be possible, consider using a text to speech program. It has the same effect.

Although it can be a bit hit-or-miss at times, you might also want to use an automated proofreading program, like Hemingway Editor or Expresso App. These free web applications will identify areas of concern in your writing, such as use of passive voice, overly complicated sentences, misuse of adverbs, and paragraphs that are too long.

Finally, don’t be afraid to share your draft with colleagues before sending it to the intended recipients. They might catch something that you may have missed during editing, or have additional insight and detail to add to your document.

Conclusion

Putting it all together, our risk statement now looks like this:

There was a vulnerability discovered moments ago called heartbleed. It exists in the OpenSSL cryptography library, which is used by millions of servers for secure communication.

This flaw could see an attacker steal a server’s private keys, session cookies, and passwords, and poses a risk to secure online communication worldwide.

It is estimated that around 17% (or 500,000) of the Internet’s secure servers are vulnerable to Heartbleed. The vulnerability does not affect servers running other TLS implementations, such as GnuTLS, Mozilla’s Network Security Services, or Microsoft’s own TLS implementation.

This vulnerability is present in a large percentage of our IT infrastructure. Presently, there is no known detection or audit mechanism available to determine if we are being attacked, or were attacked. The fact that our encrypted traffic could be read by others creates a high risk exposure.

Right now, I am going to start an audit of our systems to see the severity of our exposure to Heartbleed. Once that’s finished, I will start patching immediately. Please arrange an all-hands meeting later this afternoon.

Communicating risk to management and non-technical users can be an uphill battle. However, by ensuring that details are structured properly and clearly, you can guarantee that your risk statements will have the maximum intended impact.