We’ve written several blogs on risk assessments and controls assessments. However, these two terms are often co-mingled, used interchangeably, or incorrectly. Unfortunately, it’s very easy to do this and often if we aren’t careful even professionals in the security industry can slip up. Since it’s the start of a new year I figured it was as good a time to try and get these two sorted out and create a reference point, we can all fall back on should they start to get co-mingled again! To start off, let’s review a little background on each to cover what they are and what they are not.
A controls assessment can be either an independent assessment or self-assessment. At its most basic, it is a review of an entity’s controls. These controls typically are based on an industry framework but don’t necessarily have to be. For instance, sometimes smaller firms in an unregulated industry may have controls they’ve implemented out of operational necessity or because they wanted to be “safer” or “do the right thing”. There’s nothing wrong with this but with the number of security frameworks currently out there, there’s no reason to start from scratch if you don’t have to. Some popular frameworks include:
- NIST 800-53
- NIST Cybersecurity Framework
- COBIT 5
- ISO 270001 Annex A
- IRS Pub 1075
- HIPAA Security Rule
If your risk assessment consists of looking at a control framework and assessing whether you are compliant, then I hate to be the bearer of bad news, but you are not doing a risk assessment. If you’re starting with a control framework, a control matrix, a list of things you do, or anything other than the concept of risk, it’s unlikely that you are performing a risk assessment. These can be valuable activities but should not be described as a risk assessment!
Not to be overly simplistic, but with a risk assessment we really need to start by looking at the name. For an assessment to be a risk assessment it needs to start with risk! This is where a risk management framework such as NIST 800-30 makes life infinitely easier as risk can mean many different things to different people. NIST 800-30 breaks risk down into four risk factors:
Now we can go through the process to identify potential risks (i.e. identify potential threats, potential vulnerabilities, potential impact, and likelihood). Once we’ve calculated inherent risk, we come to the step that causes the most confusion between control and risk assessments. To go from inherent risk to residual risk, we need to identify whether we have a control in place to address the risk. This is where the real value of a risk assessment comes into play. If we don’t have a control in place, we now have justification for implementing a new control. After all, the risk is right there in the open now (sorry folks, no more “ignorance is bliss”). This also can be flipped on its head. What if we were to say, “Wait how come we have so many gaps in our risk assessment, we have all these other controls, but they weren’t mapped to any risks”? This could be for a couple reasons and we need to be careful not to jump to conclusions. Once we’ve done due diligence to ensure that the unmapped control does not apply to an identified risk, we may have an opportunity to start saving some time (and $$$!) by sunsetting unneeded controls!
To summarize what we’ve talked about:
- Risk Assessments identify applicable risks thereby serving to inform control decisions.
- Control assessments give us insight into our control performance, which can help with the tail-end of a risk assessment when we need to determine how to treat risk.
- Both are valuable related activities but are not the same thing!
For more detail on the risk assessment process itself see some of our other posts on the topic: