A very common question we get asked here at SimpleRisk is around the calculation of Residual Risk. I covered the subject a little bit in my blog post on How to Calculate Inherent vs Residual Risk, but I wanted to delve a bit deeper into this topic due to some differences in how we handle it versus how some other GRC platforms might do it.
First, consider the fact that we currently support six different scoring methodologies in SimpleRisk:
- Classic: A simple calculation of likelihood x impact with the ability to use weighted modifiers for each.
- CVSS: The Common Vulnerability Scoring System focused on evaluating and ranking vulnerabilities in a standardized and repeatable way.
- DREAD: A system for assessing security threats formerly used by Microsoft.
- OWASP: Developed by OWASP as a way to systematically evaluate and prioritize primarily application security risks.
- Contributing Risk: Used by a SimpleRisk customer to evaluate a single likelihood against multiple, weighted, impact values.
- Custom: A simple 0 through 10 rating of a risk.
Each of these different risk scoring methodologies has multiple variables that give you a final quantitative score. In SimpleRisk, we then normalize that score so that you can use these methods interchangeably. I talk about this more in my Normalizing Risk Scoring Across Different Methodologies blog post, but the end result is that each of these has a quantitative score between 0 and 10. After all, risk management is simply a prioritization process to determine where to spend our limited resources and this gets us to that goal.
The next step, however, is where things get a bit more complicated because our goal now becomes reducing our organization's risk exposure. There are several ways to accomplish a reduction in risk. You could decide to simply stop doing the risky activity. You could purchase insurance to cover your organization in the event of a loss. But, for the purpose of this blog post, we are going to focus on risk reduction by applying mitigating controls.
For each risk that we evaluate, we come up with a list of things that we can do to either reduce the likelihood of the event happening or the impact if it did. Let's take a simple example of home security. If the risk we are trying to reduce is "Theft of valuables due to a home break-in", what kind of mitigating controls could we apply? Well, we could reduce the likelihood of somebody breaking in maybe by putting a sign in our yard stating that we have a home security system or a guard dog. We could make sure that we never leave valuables in a location that is in view from our windows. We could make sure that when somebody comes to the door, we never invite them in or allow them to view inside of our house. We could lock our doors and leave lights on while we are away. Additionally, even if none of these deterred someone from breaking into our house, we could do some things to reduce the impact if they did. Perhaps we have an alarm system that reduces the time they have in our house before the police show up. Maybe we have a big scary guard dog that makes them not want to stick around. We could even ensure that all of our valuables are locked away in a hidden safe. We could pick any combination of these mitigating controls, or even all of these controls, to reduce our risk exposure. Deciding on which controls make the most sense is a cost-benefit decision. Risk mitigation for your organization is no different.
Once our mitigating controls have been determined, the next step is calculating what is known as our "Residual Risk". Some people see residual risk as the risk we will have in the future after our controls are applied. Personally, I like to think of it more as the current state of our risks, as I feel that it gives us a better ability to gauge the risk when a control fails us. Unfortunately, calculating the residual risk can get really complicated, very quickly. In my break-in example, above, I proposed seven independent mitigating controls. You certainly could attempt to re-evaluate the risk scoring based on each independent control, but it would never be able gauge the cumulative effect of having multiple controls working together. This is where I'd lean back on what I said earlier, that "risk management is simply a prioritization process to determine where to spend our limited resources and this gets us to that goal". As risk managers, we look at the cost associated with the selected controls versus the overall risk reduction they provide and re-prioritize based on our new score. Maybe that means that we decide that our reduction efforts weren't enough and we need to add more or better controls. Maybe that means that we decide that we have mitigated our risk to an acceptable level based on our risk appetite. Either way, we know now where this risk stands against all of our other risks.
In SimpleRisk, we handle this risk mitigation process through the use of a mitigation percent. We used a percent because, as described above, determining risk reduction is an art, not a science. Yes, you could use the initial assessment methodology to re-score your risk, and we have items on our roadmap to do that, but it creates complication that really isn't necessarily for this process. A mitigation percent is subjective, but it's also incredibly easy to understand, requires less overall effort, works across multiple scoring methodologies, and still yields the same desired result.
There are three places in SimpleRisk where you can define a mitigation percent:
- Under Governance -> Define Control Frameworks, under the "Controls" tab, you can define the "Mitigation Percent" value for any of your controls. Using our example above, did you know that 83% of would-be burglars check for the presence of an alarm system before attempting a break-in? Assuming that means that 83% of break-ins could be prevented by having an alarm system, we could say that every time we apply an alarm system as a control for a risk, it reduces that risk by at least 83%. So we would enter a mitigation percent of 83 for that control so that it is automatically set for the risks it gets applied to. In the situation where you select more than one control, the highest mitigation percent is the one that will be used to calculate the residual risk since only you know what the impact of multiple controls will be (see #3, below).
- When planning a mitigation for a risk, and selecting your mitigating controls, there is a "Control Validation" section at the bottom of each control. In this section, you will also see a "Mitigation Percent" field. Use this if the effect of applying this control is specific to the risk it is being applied to. Let's say that we own two houses, one is our primary residence in the suburbs and the other is a log cabin in a remote part of the mountains. We could apply that same alarm system control to each of them, but the police response for the log cabin will be drastically slower to non-existent at your cabin. Thus, while that alarm system might still provide the 83% risk reduction for your suburban home, it will be far less effective for your cabin. This option enables you to manage this situation by changing the mitigation percentage for that control, as applied to that risk, to a different value.
- When planning a mitigation for a risk, there is a "Mitigation Percent" field. Remember how I mentioned that there is a cumulative effect when you have multiple independent controls working together? This field handles the situation where the sum total is greater than the parts. Take that suburban home we talked about already. Did you know that the front door is the access point for 34% of burglars? Let's assume that by reenforcing and locking our front door we have a 34% reduction in this risk. But we also have an alarm system with the aforementioned 83% reduction in risk. I think we could agree that having both of these won't fully mitigate our risk (ie. 100% risk reduction), but the two controls is probably more than the 83% of only having an alarm system. This field overrides both of the previous mitigation percentages and is the value used to determine the cumulative effect of all of your controls.
Now, once the appropriate mitigation percent value has been set, your residual risk will reflect how much risk is left after the selected mitigations have been applied to the risk. From here, ensure that your Risk Appetite value on the Configure -> Settings page has been set to reflect your organization's level of risk appetite and then take a look at the Risk Appetite Report, located under the Reporting menu, to determine the prioritization of any remaining risks.
