Step 0: Create A Risk Register

A risk register is just a fancy cybersecurity term for “a list of things that introduce risk to the company”. In the post, I will walk you through why you need one, how to create it, and what to avoid

In this issue…

Table of Contents

Step 0 for almost any Information Security program is to create a Risk Register. A risk register is just a fancy cybersecurity term for “a list of things that introduce risk to the company”. In the post, I will walk you through why you need one, how to create it, and mistakes to avoid.

Why A Risk Register

A risk register helps gather all the risks you think exist in one place. This in turn will help communicate with other stakeholders that these risks exist (in your opinion). Once these risks are identified, you can then work with them on validating these risks, and come up with possible treatments (solutions) for these risks.

Putting A Risk Register Together

You don’t need a fancy tool to put a risk register together. It can be a simple spreadsheet to begin with.

Basic elements of a risk register include:

  • Name Of Risk

    • Try to be very succinct and descriptive of the risk here. Avoid being general or vague

  • Description

    • Provide a detailed description of the risk

  • Impact

    • What is the impact of this risk if it is not dealt with. This can be in terms of any of the following:

      • Financial Impact

      • Reputational Impact

      • Availability Impact

      • Data Lost Impact

  • Likelihood of Exploit

    • How often can we expect this risk to be taken advantage of? If it’s been taken advantage of previously at your current organization, then there’s precedent. How about your industry?

  • Overall Risk Rating

    • This would be an overall risk score that calculates Risk Impact and Likelihood together.

    • It’s important to be transparent in how you came to this decision or calculation

  • Risk Treatment

    • The golden question…. What is being done about this risk?

    • Option can include

      • Triaged

      • Accepted - This means the business is aware of this and has accepted the risk, which is totally acceptable (no pun intended)

      • Remediation In Progress

      • Remediated

So to summarize, an example would look like this:

Quantifiable or Quantitative?

An age old question in the security community is how do we better quantify and communicate risks and vulnerabilities to executives. Since our industry is still nascent compared to other industries, this is a work in progress.

My overall recommendation would be to use the language already existing in your organization. For example, if your team uses “Today, Tomorrow, or Later” in their product release terminology, then that might be a good thing to adapt. This helps you speak the same language to your stakeholders.

Quantifiable Examples

The traditional infosec approach has been to use some of the following terms:

  • Informational

  • Low

  • Medium

  • High

  • Critical

There is nothing wrong with using this, however it can appear to be a little handwavy.

So to prevent the appearance of so, it’s good to come up with defined criteria on how these ratings are assessed.

In addition, you can always increase or decrease the rating based on additional context.

Quantitative Examples

  • Users or Organizational count

  • Financial Assets

  • Number of Hours

  • Number of Days

  • Potential Stock Price or Valuation Affect ($, % change, etc)

  • Estimated Percentage %

turned on monitoring screen

A good book on the subject is “How to Measure Anything in Cybersecurity Risk”

Mistakes To Avoid When Using A Risk Register

Under or Over Estimating the risk

This is the challenge of any security assessment… how to accurately measure the risk of something.

One one hand, if you overestimate the risk you look like chicken little and the sky is falling.

On the other hand, if you underestimate the risk and it gets exploited you get blamed for not raising the issue early enough.

Welcome to our world!

The key here is to have a good communication path with your stakeholders such that they are on your side and will help you accurately measure the risk. Data is your friend here.

Coming up with a solution for risks without the involved parties

woman and man sitting in front of monitor

Doing anything in a vacuum is not recommended in any business. Making security solutions without good context or if you don’t own the system can be challenging to say the least.

In technology, there are tons of solutions out there. Yes, come up with suggestions if you are familiar with the systems and controls. The more options, the better. But insisting on a particular solution without knowing the roadmap or engineering impact can be detrimental.

Assigning deadlines you can’t control

As with the above, if you are not the one implementing the fix, then how can you determine when it will be fixed? If you are under compliance and regulation requirements, then yeah, that makes sense.

Now, if there is an already agreed upon timeline for things to be fixed, such as a critical vulnerability in a public web application, then yeah. However, a risk in a risk register is sometimes a little more complex like a process not in place or being followed.

Conclusion: Starting A Risk Register

If you read between the lines, you’ll soon realize that starting and managing a Risk Register is more about communication and people than a spreadsheet.

Our job as security people is about communicating risk and our security posture to the business as well as leading the charge towards protecting company and customer data. It’s not a simple task.

Having a Risk Register in place adds additional transparency to other groups or leadership on where we are regarding our security posture and what’s been done about it.

Join the conversation

or to participate.