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.