editione1.0.0
Updated October 9, 2023You have a great memory, you have made a successful company from your plucky spirit and ability to juggle many complex tasks at once … resisting the formalization and documentation of things like risks is a natural urge. After all, you haven’t been hacked yet, so why change?
Recording (or making a written record of) risks shouldn’t be a laborious process. It’s not about killing the joy and culture of your team, and it’s certainly not about slowing down or being more wary of the world. Recording risks is simply a mechanism for making consistent decisions about how you will approach a challenge, sharing that decision with those who need to be aware of it, and remembering that decision so that if times or circumstances change, it can be revisited and allow us to ensure it remains the right course of action.
Definition We call this documented record of risk decisions a risk register.
Like most things in the world of process, creating a risk register can be as simple or complex as you make it. The important part is the calculation and recording of risk decisions, not which fancy tool you have used to store this information.
Whether it’s a spreadsheet or a Trello board, a custom-built database or an off-the-shelf risk management system, there is no right or wrong tool. In fact, the right tool is the one you have at hand and remember to use.
Let’s take a look at the key items you need to record and why they are important.
Information | Why do we store it? | Example Entry |
---|---|---|
Date | Risks represent the results of an assessment at a specific moment in time. Having a date is key to being able to identify when a risk was first assessed. | 8 October 2021 |
Raised by | The person who raised or identified the risk. This is almost always someone within your organization. | Laura Bell |
Title | A short title that represents the risk identified. | Unpatched operating system on production server |
Description | A longer explanation of the risk and the context in which it was found. | When reviewing the software patching levels on our production servers, a server was identified with an outdated and unsupported version of the operating system. This system is the main processing server for our billing system and is externally exposed to the internet. |
Affected systems/data | The systems, technologies, processes, or people affected by this risk, should it be exploited. | The Billing Server |
Impact | The resulting effect that would be felt by the organization if this risk was exploited. | Unpatched and unsupported software can be used to compromise systems and move laterally through company networks, exposing data and key company systems. The impact is assessed as Critical. |
Likelihood | The probability of this risk being exploited given the complexity of the exploit needed, the resources required to do so, and the potential gain an attacker could achieve by doing so. | Unpatched software is a leading cause of systems compromise and exploits are widely available. The likelihood is assessed as High. |
Criticality | An assessment of how serious this risk is to the business. | Critical |
Potential mitigations | Suggested preventative, detective, and responsive controls that could be used to reduce the likelihood or impact of this risk being exploited. | Investigate how long this system has been exposed and consult forensics specialists to look for indications of compromise. Update the operating system for the billing component. Review all other systems for outdated software. Review the patch management processes to ensure that systems are patched in accordance with policy. Increase logging and monitoring. |
Status | A label to define progress made towards addressing this risk. Typical values would include: Accepted, Mitigated, Mitigation in Progress, Ignored, and New. | Under Investigation |
Implemented mitigations | The preventative, detective, and responsive controls that the company has chosen to apply to this risk. | To be decided. Awaiting forensics report. |
Comments | Any additional information that is relevant to this risk and not captured elsewhere. This could include progress updates. | The Forensics team was engaged on 10 October 2021. |
Last review date | The date this risk was last updated and reviewed. This is crucial to ensuring that risks are assessed regularly and that any change in the likelihood or impact is captured. | 12 October 2021 |
So you’ve created a wonderfully detailed risk register! Congratulations, auditors everywhere will rejoice. Just kidding.
important Creating your register is a great first step, but risk registers are living and evolving records. Just as your business, its operations, and operating environment change over time, so do the risks and their impacts.
Risks must be reviewed regularly to ensure that the assessment remains valid and to ensure the company is made aware if any changes are needed to their mitigations or controls.
When you are setting up your risk review process, here are some things to consider:
Choose the frequency. You need to review your risks regularly. This frequency will depend on the sensitivity, frequency of change, and environment your organization operates in. Quarterly is a good starting point.
Consult with the right people. Make sure you have senior representatives from key areas involved in the review. If the risk is specific to a project, keep this list of people related. If the risk involves the wider organization, ensure that the executive team is involved in the review.
Record your review. It’s important to update your risk register every time you identify a change. These notes will help to track the evolution of risks and when decisions regarding them are made.
Be prepared to do ad hoc reviews. Sometimes circumstances will change so suddenly and dramatically that we need to break from our review schedule and carry out an ad hoc review. Don’t be afraid to do this if you believe you need to. It’s better to review and find out it wasn’t serious after all, rather than to wait too long and miss your chance to take action.
At a high level, many people would agree that risk registers are simple documents that are fairly easy to understand and manage. After all, we are used to the idea of tracking issues with our systems or tracking items on our to-do list, and this is just another thing for us to record and manage.
While this is indeed true, there are a number of areas that trip people up when they are managing their risk registers.
Keeping them up to date. As we have covered on many occasions, your brain doesn’t like boring, repetitive tasks. Remembering to check and review your risk register is unlikely to excite it. However hard it might be, keeping them up to date and regularly reviewing them is essential. Risk changes as your business and its operating environment changes, this change can impact the severity of the issue and how it could affect your organization.
Reducing fear. Once upon a time, a security manager for a high-growth company was approached by the executive team about a risk register they had recently submitted. The manager was distraught, as they had worked hard on the document and thought it was pretty good, despite the high number of issues they had identified. The executive team had one comment: “Can you make it less … red?”
You see, for the executive team, the color red was so alarming that it shut down conversations and triggered fear responses in the discussions.
Whether it’s the fonts you use, the color code you implement, or the language you use, everything you do to communicate risk needs to be right. Too alarmist and you may cause people to shut down and disconnect, not strong enough and they may miss the important messages.
While you may handle the day-to-day responsibilities of managing security in your organization, your executive and board members hold the accountability and overall responsibility for them, and all other sorts of risks faced by the business.
This role is well defined by both national and international directors’ institutes and is governed by law in most countries. In fact, a director’s responsibility is so well defined and important that many organizations take out specific insurance to cover this risk.
important It is this legal responsibility that makes choosing when and how you communicate security risks with your board of directors and executive teams incredibly important. Once a director has been informed of a risk, they must take actions to either mitigate, reduce, or otherwise eliminate it. It’s not optional, it’s their legal obligation to do so.