top of page
  • Phil Venables

Are You Managing Your Risk Register Effectively?

Not all risks are possible to fully mitigate in every context, so you need to record and manage those residual risks. These are often put into a risk register along with the universe of risks that are mitigated. A better term to describe your log of residual risks might be Risk Inventory. Most organizations do not manage these risk inventories as well as they could. 

Before examining that, let’s look at what I think is a good, and simple, model of how to think about the overall risk process. Think of your process as being about managing a warehouse of risk “items”, these are just expressions of risk ranging from macro to micro, for example: the risk of a data breach due to insufficient mobile device protection or the risk of a web site breach due to a vulnerability that has not been fixed. 

There are various ways risks can flow through your "Information Risks" warehouse:

  • You can find a risk and after analysis realize that it has already been solved broadly by a set of architectural measures, current practices or existing controls you have in place.

  • You can find a risk and then determine you can quickly remediate it in some way, whether by implementing a control, adapting a control, resolving a vulnerability, eliminating the risk itself by adjusting your business process (for example: deciding to not collect some piece of data) or by implementing a compensating control upstream or downstream.

  • Or, you can find a risk and then determine you cannot, for many possible reasons, remediate it fully, or at all. This is recorded and stays in your warehouse as part of your Risk Inventory. 

Going with the warehouse analogy a bit more, your goal is to maintain a flow of inventory through the warehouse - to get high velocity across your Find Risk → Fix Risk flow. This is like in a physical warehouse where you want high inventory turn. You might say, given this is about risk, the goal should be to have zero inventory. Well, we can achieve that by not looking for risk at all, which is of course not optimal, so we need to balance this:

  • If we improve how well we Find Risk then have to improve how Fix Risk works otherwise we accumulate excess Risk Inventory. 

  • Improving Find Risk entails improving your risk identification, scenario planning, horizon scanning, risk and control assessment and continuous control monitoring processes across the full range of your assets. Find Risk is about sensory breadth/depth to detect issues and the imagination to contemplate new risks.  

  • Improving Fix Risk entails designing your environment for defensibility, prioritizing infrastructure investments, improving your developer/engineering integration and software development processes to fix issues quicker (what some might call DevSecOps). Fix Risk is about organization / environment design and process agility.

In all of this process, you are never going to be able to perfectly match your Find Risk and Fix Risk processes:

  • When Find Risk < Fix Risk then your Risk Inventory will be empty, but this will likely be a result of a failed Find Risk process and that will manifest as a lag before your attackers Find Risk for you in the form of security incidents.

  • When Find Risk > Fix Risk then your Risk Inventory will grow in the form of accepted risk. So now let's look at how to manage that Risk Inventory. 

Your Risk Inventory is simply the record of what residual risk remains. You may not like the phrase “Accepted Risk”, but the reality is whether you like it or not, what is in your Risk Inventory is accepted implicitly or explicitly. That is just reality. So, your first goal is to make sure all the risks in your Risk Inventory are in fact explicitly accepted and assigned to the right senior accountable leader (or designated Committee). This person or group will bear the consequences if the risk is realized and have the authority to drive a different outcome for that risk such as fund work to remediate it. It is also important to make sure that any risk in the Risk Inventory does not exceed any Board defined risk tolerances (if it does then that will require a Board escalation as well). 

A core part of ensuring that risk acceptance is explicit is also to contemplate other risk treatment options that lessen the risk consequences, for example: some form of insurance or other hedging/transfer, inherent risk reduction, limiting potential event blast radius, or using compensating controls elsewhere in the technology or business process. 

Having done this, the Risk Inventory is now well curated and typically made up of 2 types of item:

  • A risk that will be accepted for which there is no plan to fully remediate.

  • A risk that will be remediated according to some work program under a specific deadline.

Now, like any inventory, the Risk Inventory needs to be managed. Most organizations manage the Risk Inventory in one way: time. That is, at some interval e.g. 1 year, accepted risks are reexamined to see if they are still deemed acceptable, or risks pending remediation are tracked in the context of the deadline for the work that will implement the remediation. 

But, this is too simplistic. We should think of the Risk Inventory being constantly examined and managed according to a whole series of triggers, which can include:

  1. Time - typically the most or only used trigger, some fixed period or the deadline of the remediation.

  2. Owner - a change in the assigned executive who approved the risk acceptance. When a new person comes into a role it's important to review the risks their predecessor accepted. A new person may not be comfortable with that portfolio of accepted risks and will want to change stance. You also probably want to reduce the time window of plausible deniability of someone saying "I didn't accept that risk".

  3. Inherent Risk - the inherent risk may change in terms of the amount or nature of data at risk, the system or business scope, the financial consequences or breadth of risk exposure across the business services. Consequently, the residual risk may increase and no longer be deemed acceptable. 

  4. Reputation Consequences - there may be a shift in public opinion, a different attitude from stakeholders and many other possibilities that increase the reputation and brand consequences of a particular risk. 

  5. Legal or Regulatory Dictates - laws or regulations may be introduced, made more stringent or changed in scope such that mitigating the risk becomes an imperative irrespective of wider constraints.

  6. Threat and Vulnerability Environment - threats may have increased in sophistication or you are now more targeted thus making a risk more likely to be realized. New vulnerabilities may have been discovered which impact any compensating controls thus altering the level of residual risk. 

  7. Control Economics - new controls / technologies may be available that shifts the economic balance such that previously accepted risk vs. the cost or impact of remediation change to make it now more feasible to implement measures to mitigate that risk. 

Bottom line: drive a greater velocity in your Find Risk → Fix Risk flow. Actively manage your Risk Inventory and continuously examine that inventory across multiple triggers. Systemize these triggers as much as possible. Tune this machine constantly - like you would a manufacturing inventory process.  

3,572 views0 comments

Recent Posts

See All

Where the Wild Things Are: Second Order Risks of AI

Every major technological change is heralded with claims of significant, even apocalyptic, risks. These almost never turn out to be immediately correct. What often turns out to be riskier are the 2nd

Security and Ten Laws of Technology 

There are many well known, so called, laws of technology. Moore’s law being particularly emblematic. Let’s look at some of them and see what the security implications have been for each and what might


Los comentarios se han desactivado.
bottom of page