- Last Week As A vCISO
- Posts
- Step 0: Create A Risk Register
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 %
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
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.
Reply