All SOC 2 examinations must include security common criteria. This includes reviewing a company’s (i.e. entity’s) risk assessment process (risks identified, risk matrix, controls in place to address the risks, etc.). However, one of the challenges that the AICPA has found when it comes to doing risk assessments is that companies are unclear on what the requirements are. In this week’s blog post, we will cover three common questions that play an important part in a risk assessment:
- What is a risk matrix?
- How do you create a risk matrix?
- What is a risk matrix used for?
Fundamental Overview of a Risk Assessment
Before we get into what a risk matrix is, we will start with a general overview of the steps involved in a risk assessment and where the risk matrix falls within the risk assessment lifecycle. Depending on which risk assessment methodology/framework a company elects to use (e.g. NIST SP 800-30, ISACA’s Risk IT, Carnegie Mellon’s OCTAVE, etc.), there may be a slightly different set of steps to follow as part of their risk assessment process. However, risk assessment frameworks generally cover the following four steps:
- Identify risks
- Analyze risks
- Address risks
- Monitor risks
When identifying risks, a risk assessment team should begin by considering the company’s overall objectives, the IT systems that support those objectives, and those systems’ underlying data. The team will want to ask those involved in the risk assessment process about the internal and external threats that exist; specifically, what do they think could cause an adverse effect on the company’s objectives and assets’ security, confidentiality, availability, processing integrity, and/or privacy?
In addition to threats, the risk assessment team will also want to consider the various vulnerabilities that exist in the company’s objectives and IT assets. Vulnerability considerations may include the underlying assets’ infrastructure, the systems themselves, their operating systems, their physical environment, and/or supply chain vulnerabilities from upstream service providers.
After the risks have been identified, the risk assessment team can move on to step two: analyzing the risks. The AICPA’s common criteria 3.2 (which aligns with COSO principle 7), states that as part of an entity’s controls around a risk assessment, “The entity identifies risks to the achievement of its objectives across the entity and analyzes risks as a basis for determining how the risks should be managed.” So, how does a company go about analyzing its identified risks?
The answer to this question can be found in the AICPA’s trust services criteria, where an additional point of focus explains what an entity needs to consider when analyzing each risk: “Considers the Significance of the Risk — The entity’s consideration of the potential significance of the identified risks includes (1) determining the criticality of identified assets in meeting objectives; (2) assessing the impact of identified threats and vulnerabilities in meeting objectives; (3) assessing the likelihood of identified threats; and (4) determining the risk associated with assets based on asset criticality, threat impact, and likelihood.” Steps 2 (impact) and 3 (likelihood) are where the risk matrix comes in.
What is a Risk Matrix & How Does One Work?
A risk matrix plots both the impact and likelihood levels of each identified risk so a company can arrive at an overall risk rating/level. Just as there are different risk assessment frameworks a company can choose to follow, a risk matrix can have multiple levels of impact and likelihood, along with different naming conventions. Let’s look at an example set of risk impact levels from NIST SP 800-30:
While NIST 800-30 defines five different impact levels, the qualitative naming convention, quantitative numbering scales, and descriptions can vary, depending on the risk assessment methodology used and each company’s needs. One entity may choose to use a more simple, three-level approach (high, medium, and low) while another company may opt to use nine impact levels. Regardless of how detailed an entity decides to document its risk impacts, the levels of impact should be clearly defined to ensure consistency in impact ratings across those who are involved in the risk assessment and rating process.
Once the impact has been defined, likelihoods should follow a similar approach of determining how many levels the entity will use and clearly defining what each likelihood level means. NIST provides another example of likelihood values (both qualitative and quantitative) and related descriptions:
How to Create a Risk Matrix
Now that risks have been identified and impacts and likelihoods defined, the risk matrix can be created. As with any part of the risk assessment process, the final risk levels and naming conventions may vary, depending on the entity’s definitions. Take a look at the risk matrix examples from NIST below.
Even if the likelihood of a risk occurring is very high, but the impact is very low, the overall risk matrix specifies the risk to be very low. While that may be true for one company’s objectives, IT assets, and related data, it may not be true for another company. The entity’s final risk matrix, including definitions/descriptions of each risk level, is what will help those involved in the risk assessment process determine the final risk level of each identified risk.
What Do You Use a Risk Matrix For?
Companies do not have an infinite amount of resources (human and monetary) or time to address every risk that exists to their company’s objectives and IT assets. A risk matrix can be used to help senior management prioritize which risks will have resources allocated to them and which will not, while considering the entity’s risk tolerance. Companies with a high-risk tolerance may accept low and medium risks; providing no or limited time/attention/resources to those risks. However, other companies with a lower risk tolerance may implement some level of detective, preventative, compensating, and/or corrective controls for their medium and low-level risks. The value of a risk matrix is that it provides senior management with an easy illustration to review, understand, and start making decisions on how to proceed with the third step in the risk assessment process: addressing risk.
Doing all of this work to arrive at a decision-making tool is helpful to the team leading the risk assessment, but there is still more value that the risk matrix can provide. A risk matrix can also be used in the last phase of the risk assessment lifecycle (monitoring risks) by taking the original risk matrix that management used to prioritize which risks to address and updating it after controls have been put in place to address those risks. This type of monitoring, or comparison, focuses on what are called inherent and residual risks. Inherent risk is the level of risk that exists if the company does nothing to address the risk. Residual risk is the level of risk that exists after the company addresses the risk by allocating resources and time by implementing controls to lower the inherent risk. To learn more about inherent risk, read our article on inherent risk vs control risk.
Using a before and after snapshot of the risk matrix can be used to report the benefits of performing the risk assessment and implementing controls to senior management. For example, if a risk had been identified and rated to be a very high risk before any controls had been implemented, but subsequently the company addressed the risk by implementing controls to reduce the likelihood and/or impact of that risk (thus lowering the overall risk level) the result may be that the residual risk was reduced to a moderate level that is more aligned with the company’s risk tolerance level.
Summary
We covered what a risk matrix is (impact and likelihood), how to create one (defining various levels of impacts, likelihoods, and overall risks), and how a risk matrix can be used throughout the risk assessment lifecycle. Creating a risk matrix provides senior management with an illustration to be able to quickly and easily understand risks to the company’s objectives and make decisions on which risks to address.
If you are considering a SOC 2 examination, performing a risk assessment is a key element that will be covered during the audit. If you have any questions about the SOC 2 audit services offered by Linford & Co or the risk assessment trust services criteria, please contact us.
Since 2004, Jason has performed and managed global IT SOX and operational audits including IT General Controls and SDLC audits, ISO 27001 internal assessments, and cybersecurity and privacy compliance audits. At HP Inc., he was involved in developing SOC report review training and guidance. Jason began his IT audit career in 2004 at PwC in the Systems and Process Assurance team and focused on internal and external SOX audits for various clients in the oil & gas, chemical, pipeline, electrical, and medical industries, in the Greater Houston area. Jason holds a Bachelor’s degree in Business Administration (Information Systems) and a Master’s degree of Information Systems Management.