Common Criteria 3.2

While organizations must consider the risks to their operations, finances, and reputation caused by threats inside their organization, they must also consider outside risks from business partners and third-party vendors. During a SOC 2 audit, organizations will have to demonstrate that they consider the risks from business partners and third-party vendors in order to comply with the SOC 2 common criteria 3.2, which states, “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.” Let’s take a look at the reasoning behind this, other frameworks that have vendor compliance requirements, and what can happen if an organization fails to manage the risks from business partners and third-party vendors.

Vendor Compliance Management for SOC 2 Compliance

As organizations increasingly outsource components of their business, it’s more crucial than ever to have a strong vendor compliance management program. Why? Because working with vendors puts your organization at a greater risk for data breaches or security incidents. By having an effective vendor compliance management program, you will be able to identify, mitigate, and better control risks from business partners and improve the security of your organization.

Think about it this way: what happens if your operations depend on the availability of your vendor’s services, but their service has an outage? If your vendor goes out of business, how does your organization continue to operate? If your organization shares cardholder data with a vendor and that vendor has a breach, what liability is held to your organization? These are the types of scenarios that your organization must consider when selecting vendors and effectively managing vendor risk, especially in order to comply with common criteria 3.2.

Vendor Compliance Management for Other Information Security Frameworks

Vendor compliance is a hot topic in the information security industry. Aside from SOC 2 compliance, having a vendor compliance management program in place is a critical component of many other information security frameworks, such as:

• PCI DSS: PCI Requirement 12.8 asks organizations to maintain and implement policies and procedures to manage service providers with whom cardholder data is shared, or that could negatively impact the security of cardholder data. PCI Requirement 12.8.1 also specifically asks that entities maintain a list of service providers including a description of the service provided.
• HIPAA: In order to comply with the HIPAA Privacy and Security Rules, covered entities must enter into Business Associate Agreements with their business associates or vendors. Such agreements must adhere to the standards set forth in 45 CFR 164.504(e), which addresses proper uses and disclosures, safeguards, incident reporting, and termination rights.
• NY CRR 500: NY CRR 500 requires two elements for effective vendor compliance management: a cybersecurity policy (Section 500.03) and a third-party service provider security policy (Section 500.11).

Vendor-Caused Breaches

It’s no surprise that so many frameworks require that organizations must have a vendor compliance management program in place; breaches caused by vendors have skyrocketed recently. In June 2018, Ticketmaster UK discovered that its customer support chatbot software from Inbenta was hacked. It was later discovered that this breach exposed a much greater one: a massive credit card skimming campaign by the threat group Magecart, something that may have been prevented if a vendor compliance management program was effectively in place. That is just one example; the list goes on and on. Companies like Best Buy, Delta Air Lines, and Sears, as well as Lord & Taylor and Saks Fifth Avenue all experienced vendor-related breaches that could have been prevented.

More SOC 2 Resources

SOC 2 Academy

Understanding Your SOC 2 Report

SOC 2 Compliance Handbook: The 5 Trust Services Criteria

[av_toggle_container initial=’1′ mode=’accordion’ sort=” styling=” colors=” font_color=” background_color=” border_color=” custom_class=”]
[av_toggle title=’Video Transcription’ tags=”]

A very common thing that we find missing in risk assessments when we’re trying to comply with SOC 2 common criteria 3.2 (CC3.2) is not including risks from business partners and vendors. This is a hot topic these days. All of the information security frameworks have been updated to include the issues that affect us from third-party vendors who might have security issues that impact us. You need to make sure that you include that as one of the risks that you consider in your own risk assessment.

[/av_toggle]

[/av_toggle_container]

Common Criteria 3.2

During a SOC 2 audit, auditors will validate that organizations comply with the common criteria listed in the 2017 SOC 2 Trust Services Criteria. Common criteria 3.2 states, “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.” When an auditor is assessing an organization’s compliance with this, they will observe how an organization is assessing the significance of risks found in their risk assessment. Let’s take a look at what organizations need to do to demonstrate compliance with common criteria 3.2.

Quantifying or Qualifying the Significance of Risks

In order for an organization to demonstrate that they comply with common criteria 3.2, they’ll need to show their auditor how they go about assessing the significance of risks identified in their risk assessment. This can be done by implementing processes that allow an organization to quantify or qualify the significance of risks. During the beginning stages of a risk assessment, qualifying the likelihood of a risk and the potential impact that the risk has to the organization is helpful in risk-ranking the threats. On the other hand, once an organization has qualified the likelihood and impact of each risk, quantifying them takes risk-ranking to the next level. An organization may opt to quantifiably risk-rank the threats by high, medium, or low or they may choose to use numerical values to demonstrate the level of risk. While qualifying the risks may not be as accurate as quantifying them, both options help an organization in assessing the significance of risks.

For instance, let’s say that an organization has conducted their risk assessment and they found these risks: an open door that could allow a malicious intruder to access a sensitive area and a vulnerability in the network that could allow malicious hackers to access secure data. The organization is now tasked with assessing the significance of these risks, plus they must consider the likelihood and impact. The organization decides to quantifiably risk-rank the likelihood and impact of these threats based on a scale of one to ten. They determine that the likelihood of a malicious intruder entering through the open door is a four and the impact would be a seven, whereas the likelihood of a malicious hacker infiltrating the network and accessing sensitive data would be a seven and the impact a nine. By allocating a figure to the likelihood and impact of these risks, an organization can calculate the significance or severity of the risks by multiplying the likelihood by the impact. In this case, the significance of the malicious intruder would be 28 and the malicious hacker would be 63. By assessing the significance of risks, the organization would know to prioritize the vulnerability in the network over the open door.

More SOC 2 Resources

SOC 2 Academy

Understanding Your SOC 2 Report

SOC 2 Compliance Handbook: The 5 Trust Services Criteria

[av_toggle_container initial=’1′ mode=’accordion’ sort=” styling=” colors=” font_color=” background_color=” border_color=” custom_class=”]
[av_toggle title=’Video Transcription’ tags=”]

A very important element in your risk assessment that you must have in place to comply with SOC 2 common criteria 3.2 (CC3.2) is a way to quantify or qualify the significance of your risk. You want to make sure that you put a figure in there for the impact of a threat to that risk. For example, if you have a risk of an open door to an area in your location and the threat is an intruder, what would the impact be if that intruder came into that sensitive area? You need to qualify that somehow. The second aspect of this is to quantify or qualify the likelihood of that happening. What would be the likelihood of an intruder coming in and doing that? You have to make sure that that is considered within the risk assessment and that you have some way of ranking things according to that impact and that likelihood, so that you can make the best decisions going forward on how you’re going to address those risks.

[/av_toggle]

[/av_toggle_container]

Common Criteria 3.2

When a service organization undergoes a SOC 2 audit, auditors will be looking to validate that they comply with the common criteria listed in the 2017 SOC 2 Trust Services Criteria. Common criteria 3.2 (CC3.2) states, “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.” We’ve discussed the different types of risks organizations can face and the importance of using the findings of a risk assessment, so let’s take a look at how to manage risks and what organizations need to do to demonstrate compliance with common criteria 3.2.

Managing Organizational Risks

A major component of using your risk assessment is assessing how to manage risks identified during the assessment. This includes evaluating the significance of the risks, assessing the likelihood of the risks, and determining how to respond to those risks. Ultimately, management must decide if they will accept, avoid, reduce, or share the risks found and how they will go about doing that. For instance, when an organization’s management meets to discuss the findings of the risk assessment, they’ll determine whether or not they want to accept certain risks or share them with someone else. This might be the case when an organization has partnered with a third-party vendor to perform part of their business process. If a risk is identified because of that partnership, the organization might reject that risk and place the responsibility on the vendor to mitigate it. Organizations might also opt to accept certain risks and will then have to determine additional controls to put into place to alleviate them.

So, how can an organization demonstrate compliance with common criteria 3.2 during a SOC 2 audit? Organizations should formally document how they plan to use their risk assessment to manage risk. In doing so,organizations are able to provide clear evidence to an auditor that they have performed a risk assessment, evaluated the significance of the risks to the organization,and have determined a plan to manage the risks identified. By having a process in place of how to manage risks, organizations are more likely to achieve their business objectives and maintain a strong security posture.

More SOC 2 Resources

SOC 2 Academy

Understanding Your SOC 2 Report

SOC 2 Compliance Handbook: The 5 Trust Services Criteria

[av_toggle_container initial=’1′ mode=’accordion’ sort=” styling=” colors=” font_color=” background_color=” border_color=” custom_class=”]
[av_toggle title=’Video Transcription’ tags=”]

After your organization sits down and documents their risk assessment, the questions “So what? What do we do with this?” might be asked. The purpose of common criteria 3.2 is to look at how you used your risk assessment in order to make choices about how those risks were going to be managed. For example, you’ll have a meeting where you discuss your risks and you’ll decide whether or not to accept or avoid certain risks. We’re going to reduce this risk by putting additional controls in place, or we’re going to share this risk with someone else. You might look at insurance as a way to transfer risk away. Ultimately, as an auditor, we’re going to be looking at the decisions that you’ve made about how you are going to manage those risks. Having it documented in your risk assessment is a very important place to start.

[/av_toggle]

[/av_toggle_container]