Service Organization Control 2 (SOC 2) is a framework aimed at service organizations such as SaaS providers that store and process customer data in the cloud. The framework enables these organizations to implement and demonstrate sufficient data protection practices and controls and build trust.
SOC 2 practices also shape your third-party risk management (TPRM) program because relationships with third parties come with notable information security risks. In this guide, we’ll explain how to meet the SOC 2 third-party risk requirements to achieve compliance effortlessly.
Specifically, you’ll learn the following:
- Benefits of SOC 2.
- SOC 2’sTrust Service Criteria (TSC).
- Specific criteria applicable to third parties.
Benefits of SOC 2
SOC 2 isn’t mandatory, but it’s highly beneficial for service organizations for several reasons, most notably:
- Attestation of firm security controls that offer clarity to both internal and external users.
- Increased customer confidence in your ability to protect data from cybersecurity threats.
- Greater sales opportunities by demonstrating security and assurance through SOC 2 reports.
How do risk managers benefit from SOC 2 reports?
SOC 2 attestations are a common part of vendor risk management (VRM). The standard prescribes numerous activities that ultimately help risk managers fine-tune their VRM strategies.
However, from a TPRM perspective, risk managers can benefit the most from SOC 2 reports submitted by their vendors as these reports help determine the effectiveness of a vendor’s security practices, which can simplify due diligence processes and reduce procurement time.
There are two types of SOC 2 reports risk teams use:
- Type 1: Addresses a vendor’s systems and controls, checking whether they meet the necessary criteria for a point in time.
- Type 2: Builds on the Type I report by describing the operating effectiveness of the organization’s systems and controls over a period of time.
Type 2 reports may offer more reassurance to risk teams. Unlike Type 1, which only addresses security controls at a specific point in time, Type 2 encompasses a longer timeframe and focuses on the controls’ effectiveness.
Both reports are generated after third-party compliance audits performed by a CPA and are usually valid for 12 months.
{{cta_withimage20="/cta-modules"}}
Using SOC 2 Trust Service Criteria (TSC) to guide audits
SOC 2 is an interpretive framework, so you don’t have to stick to a strict compliance checklist. Still, the framework is comprised of five Trust Service Criteria (TSCs) you can use to inform your compliance strategy:
- Security, also known as Common Criteria (CC): System resources and data should be protected from unauthorized access, damage, and disclosure of information. Such protection can be ensured through controls like endpoint security and firewall management. This criteria is the minimum required to implement for a SOC 2 attestation.
- Availability (A): Systems and data should be available for operational activities.
- Confidentiality (C): Information deemed confidential (customer data, contracts, IP, etc.) should be protected in a way that enables an organization to meet its objectives.
- Processing integrity (PI): System processing should be accurate, timely, valid, complete, and authorized.
- Privacy (P): PII, PHI, and other personal information should be protected at every stage during collection, use, retention, and disposal, and customers should be informed about this.
Security is a core TSC and is included in all SOC 2 reports. The remaining four are optional and can be added according to factors like the organization’s nature of services and business goals. For example, confidentiality and privacy requirements are crucial for healthcare companies, while hosting providers and software vendors should also prioritize availability requirements.
6 TPRM-related SOC 2 requirements your organization should meet
SOC 2 addresses third-party risk through a specific set of security (Common Criteria) and privacy TSCs, outlined in the following table:
Each TSC has a set of focus points that clarify the corresponding criterion and provide precise guidelines for meeting it.
1. CC2.3
CC2.3 outlines the importance of communication with external parties regarding any issues that can impact internal control operations.
Meeting the requirements of CC2.3 involves establishing open, two-way communication channels for the regular exchange of relevant information. You should maintain the efficacy of the communication system throughout the duration of a third party’s engagement with your organization, particularly during the onboarding process.
Effective communication should cover not only routine operational updates but also any potential risks, changes in control environments, or incidents that could affect your internal controls. Doing so can be challenging if you work with numerous third parties. A good practice here can be to streamline the process through a centralized platform for hosting correspondence submissions, including all supporting third party documentation.
{{cta_withimage1="/cta-modules"}} | The SOC 2 Compliance Checklist
2. CC3.2
The CC3.2 criterion outlines an organization’s responsibilities regarding risk assessments. Specifically, it requires you to identify all risks and use them as a basis for developing relevant remediation measures. This exercise involves identifying threats and vulnerabilities arising from both internal and external factors, including vendors, business partners, and other third parties.
Since the TSC expands your scope for third-party reviews, the best practice is to have an elaborate risk assessment process supported by the right software. The goal is to avoid inefficient, manually driven review workflows, especially if you work with many third parties.
Ideally, you should opt for a platform that streamlines the following risk assessment activities:
- Evidence collection
- Security reviews
- Risk score calculation
If you want more structured and comparable due diligence, you can also use a well-designed risk assessment template to get started.
3. CC3.4
Besides identifying risks, your organization must track any changes that could threaten its well-being, and this supervision also expands to vendor and business partner relationships.
While assessing and managing internal changes is straightforward, the same can’t be said for external changes. You don’t have much control over third party operations—you can either request that they share the relevant information or react to changes as they occur. Many organizations define terms in their SLAs to ensure the third party communicates the relevant changes in the desired manner.
You can also be a little more proactive if you set up an ongoing monitoring system to track these changes. For example, if you record all third-party data in a centralized inventory and configure alerts for metrics you want to track, you can observe any notable changes to their risk profile right away.
4. CC9.2
The CC9.2 criterion addresses TPRM directly and requires an organization to manage any risk coming from vendors and business partners, i.e., your third parties.
This criterion involves establishing clear policies and procedures for onboarding new vendors and partners, conducting ongoing due diligence, and regularly reviewing the security practices of your third-party service providers.
Organizations must ensure that their third parties adhere to the same security standards as they do, especially regarding the handling and protection of sensitive data. If your TPRM program or compliance software offers a SOC 2 checklist, you can utilize it to streamline extensive compliance processes.
{{cta_withimage5="/cta-modules"}} | How to minimize third-party risk with vendor management guide
5. P6.4
SOC 2 has two significant TPRM-related privacy criteria. The first one is P6.4, which discusses privacy commitments.
The P6.4 criterion requires your organization to obtain privacy-related commitments from all third parties that can access personal information, and you also need to assess their compliance with the defined practices periodically.
At the core of this criterion is the intention to implement strategies for comprehensive due diligence of your third parties and see that they uphold your personal data protection commitments. For instance, you need to evaluate from time to time whether a third party has sufficient security measures and practices in place to safeguard your personal data.
You should then implement the monitoring procedures mentioned in CC3.4 to ensure the third party handles the data responsibly. Ideally, you’ll also come up with remediation strategies to address any potential misuse of personal information proactively.
6. P6.5
P6.5 is the second TPRM-related privacy criterion in SOC 2 and it outlines the requirements related to obtaining commitments to notify privacy incidents.
Despite a third party’s efforts to safeguard an organization’s data, incidents may occur. If there is an actual or suspected disclosure of personal information, a third party is obligated to report it as per SOC 2 P6.5.
To adhere to P6.5 fully, your organization must not only establish clear incident notification requirements with your third parties but also develop a robust incident response plan.
Ideally, the plan should outline procedures for handling unauthorized data disclosures, leaks, and cybersecurity breaches. It should also include predefined protocols for third-party notifications, specifying the timeframe within which they must report incidents and the required information that should be included in such reports.
{{cta_testimonial2="/cta-modules"}} | Stormboard customer story
Streamline yourSOC 2 attestation with Vanta
SOC 2 attestations require a high level of detail and continuous efforts, from data collection and monitoring to frequent risk assessments. Vanta can streamline these tasks significantly with its SOC 2 product suite.
Vanta integrates with 300+ tools, including task trackers and cloud services, to help you set up continuous monitoring workflows. You can use pre-built processes, automated gap analysis and risk assessments, and checklists to tick off your compliance tasks and get certified in no time.
If you need support building a robust TPRM program, you may want to explore Vanta’s Vendor Risk Management product. It automates several of your routine third-party risk management tasks with features like:
- Centralized vendor inventory with defined and customizable risk scores.
- Comprehensive dashboards for tracking vendor metrics.
- Risk auto-scoring based on predetermined or custom parameters.
- Shadow IT discovery.
You can watch this webinar to understand how Vanta’s AI and automation functionalities help you manage a cost-efficient, SOC 2-attested TPRM program—or you can request a custom Vanta demo.
{{cta_simple1="/cta-modules"}} | The SOC 2 product page
Regulatory compliance and industry standards
How to meet the SOC 2 third-party requirements
Regulatory compliance and industry standards
Service Organization Control 2 (SOC 2) is a framework aimed at service organizations such as SaaS providers that store and process customer data in the cloud. The framework enables these organizations to implement and demonstrate sufficient data protection practices and controls and build trust.
SOC 2 practices also shape your third-party risk management (TPRM) program because relationships with third parties come with notable information security risks. In this guide, we’ll explain how to meet the SOC 2 third-party risk requirements to achieve compliance effortlessly.
Specifically, you’ll learn the following:
- Benefits of SOC 2.
- SOC 2’sTrust Service Criteria (TSC).
- Specific criteria applicable to third parties.
Benefits of SOC 2
SOC 2 isn’t mandatory, but it’s highly beneficial for service organizations for several reasons, most notably:
- Attestation of firm security controls that offer clarity to both internal and external users.
- Increased customer confidence in your ability to protect data from cybersecurity threats.
- Greater sales opportunities by demonstrating security and assurance through SOC 2 reports.
How do risk managers benefit from SOC 2 reports?
SOC 2 attestations are a common part of vendor risk management (VRM). The standard prescribes numerous activities that ultimately help risk managers fine-tune their VRM strategies.
However, from a TPRM perspective, risk managers can benefit the most from SOC 2 reports submitted by their vendors as these reports help determine the effectiveness of a vendor’s security practices, which can simplify due diligence processes and reduce procurement time.
There are two types of SOC 2 reports risk teams use:
- Type 1: Addresses a vendor’s systems and controls, checking whether they meet the necessary criteria for a point in time.
- Type 2: Builds on the Type I report by describing the operating effectiveness of the organization’s systems and controls over a period of time.
Type 2 reports may offer more reassurance to risk teams. Unlike Type 1, which only addresses security controls at a specific point in time, Type 2 encompasses a longer timeframe and focuses on the controls’ effectiveness.
Both reports are generated after third-party compliance audits performed by a CPA and are usually valid for 12 months.
{{cta_withimage20="/cta-modules"}}
Using SOC 2 Trust Service Criteria (TSC) to guide audits
SOC 2 is an interpretive framework, so you don’t have to stick to a strict compliance checklist. Still, the framework is comprised of five Trust Service Criteria (TSCs) you can use to inform your compliance strategy:
- Security, also known as Common Criteria (CC): System resources and data should be protected from unauthorized access, damage, and disclosure of information. Such protection can be ensured through controls like endpoint security and firewall management. This criteria is the minimum required to implement for a SOC 2 attestation.
- Availability (A): Systems and data should be available for operational activities.
- Confidentiality (C): Information deemed confidential (customer data, contracts, IP, etc.) should be protected in a way that enables an organization to meet its objectives.
- Processing integrity (PI): System processing should be accurate, timely, valid, complete, and authorized.
- Privacy (P): PII, PHI, and other personal information should be protected at every stage during collection, use, retention, and disposal, and customers should be informed about this.
Security is a core TSC and is included in all SOC 2 reports. The remaining four are optional and can be added according to factors like the organization’s nature of services and business goals. For example, confidentiality and privacy requirements are crucial for healthcare companies, while hosting providers and software vendors should also prioritize availability requirements.
6 TPRM-related SOC 2 requirements your organization should meet
SOC 2 addresses third-party risk through a specific set of security (Common Criteria) and privacy TSCs, outlined in the following table:
Each TSC has a set of focus points that clarify the corresponding criterion and provide precise guidelines for meeting it.
1. CC2.3
CC2.3 outlines the importance of communication with external parties regarding any issues that can impact internal control operations.
Meeting the requirements of CC2.3 involves establishing open, two-way communication channels for the regular exchange of relevant information. You should maintain the efficacy of the communication system throughout the duration of a third party’s engagement with your organization, particularly during the onboarding process.
Effective communication should cover not only routine operational updates but also any potential risks, changes in control environments, or incidents that could affect your internal controls. Doing so can be challenging if you work with numerous third parties. A good practice here can be to streamline the process through a centralized platform for hosting correspondence submissions, including all supporting third party documentation.
{{cta_withimage1="/cta-modules"}} | The SOC 2 Compliance Checklist
2. CC3.2
The CC3.2 criterion outlines an organization’s responsibilities regarding risk assessments. Specifically, it requires you to identify all risks and use them as a basis for developing relevant remediation measures. This exercise involves identifying threats and vulnerabilities arising from both internal and external factors, including vendors, business partners, and other third parties.
Since the TSC expands your scope for third-party reviews, the best practice is to have an elaborate risk assessment process supported by the right software. The goal is to avoid inefficient, manually driven review workflows, especially if you work with many third parties.
Ideally, you should opt for a platform that streamlines the following risk assessment activities:
- Evidence collection
- Security reviews
- Risk score calculation
If you want more structured and comparable due diligence, you can also use a well-designed risk assessment template to get started.
3. CC3.4
Besides identifying risks, your organization must track any changes that could threaten its well-being, and this supervision also expands to vendor and business partner relationships.
While assessing and managing internal changes is straightforward, the same can’t be said for external changes. You don’t have much control over third party operations—you can either request that they share the relevant information or react to changes as they occur. Many organizations define terms in their SLAs to ensure the third party communicates the relevant changes in the desired manner.
You can also be a little more proactive if you set up an ongoing monitoring system to track these changes. For example, if you record all third-party data in a centralized inventory and configure alerts for metrics you want to track, you can observe any notable changes to their risk profile right away.
4. CC9.2
The CC9.2 criterion addresses TPRM directly and requires an organization to manage any risk coming from vendors and business partners, i.e., your third parties.
This criterion involves establishing clear policies and procedures for onboarding new vendors and partners, conducting ongoing due diligence, and regularly reviewing the security practices of your third-party service providers.
Organizations must ensure that their third parties adhere to the same security standards as they do, especially regarding the handling and protection of sensitive data. If your TPRM program or compliance software offers a SOC 2 checklist, you can utilize it to streamline extensive compliance processes.
{{cta_withimage5="/cta-modules"}} | How to minimize third-party risk with vendor management guide
5. P6.4
SOC 2 has two significant TPRM-related privacy criteria. The first one is P6.4, which discusses privacy commitments.
The P6.4 criterion requires your organization to obtain privacy-related commitments from all third parties that can access personal information, and you also need to assess their compliance with the defined practices periodically.
At the core of this criterion is the intention to implement strategies for comprehensive due diligence of your third parties and see that they uphold your personal data protection commitments. For instance, you need to evaluate from time to time whether a third party has sufficient security measures and practices in place to safeguard your personal data.
You should then implement the monitoring procedures mentioned in CC3.4 to ensure the third party handles the data responsibly. Ideally, you’ll also come up with remediation strategies to address any potential misuse of personal information proactively.
6. P6.5
P6.5 is the second TPRM-related privacy criterion in SOC 2 and it outlines the requirements related to obtaining commitments to notify privacy incidents.
Despite a third party’s efforts to safeguard an organization’s data, incidents may occur. If there is an actual or suspected disclosure of personal information, a third party is obligated to report it as per SOC 2 P6.5.
To adhere to P6.5 fully, your organization must not only establish clear incident notification requirements with your third parties but also develop a robust incident response plan.
Ideally, the plan should outline procedures for handling unauthorized data disclosures, leaks, and cybersecurity breaches. It should also include predefined protocols for third-party notifications, specifying the timeframe within which they must report incidents and the required information that should be included in such reports.
{{cta_testimonial2="/cta-modules"}} | Stormboard customer story
Streamline yourSOC 2 attestation with Vanta
SOC 2 attestations require a high level of detail and continuous efforts, from data collection and monitoring to frequent risk assessments. Vanta can streamline these tasks significantly with its SOC 2 product suite.
Vanta integrates with 300+ tools, including task trackers and cloud services, to help you set up continuous monitoring workflows. You can use pre-built processes, automated gap analysis and risk assessments, and checklists to tick off your compliance tasks and get certified in no time.
If you need support building a robust TPRM program, you may want to explore Vanta’s Vendor Risk Management product. It automates several of your routine third-party risk management tasks with features like:
- Centralized vendor inventory with defined and customizable risk scores.
- Comprehensive dashboards for tracking vendor metrics.
- Risk auto-scoring based on predetermined or custom parameters.
- Shadow IT discovery.
You can watch this webinar to understand how Vanta’s AI and automation functionalities help you manage a cost-efficient, SOC 2-attested TPRM program—or you can request a custom Vanta demo.
{{cta_simple1="/cta-modules"}} | The SOC 2 product page
Explore more TPRM articles
Introduction to TPRM
Vendor lifecycle management
Vendor risk assessment
Running a VRM program
Regulatory compliance and industry standards
Get started with TPRM
Start your TPRM journey with these related resources.
How to minimize third-party risk with vendor management
Get insights and best practices from security & compliance experts on how to manage third-party vendor risk in this free guide.
.svg)
Vanta in Action: Vendor Risk Management
Vendor security reviews can be manual and time-consuming, draining security teams of precious hours. Vanta’s Vendor Risk Management solution changes that, automating and streamlining security reviews so that you can spend less time on repetitive work and more time strengthening your security posture. Curious to see what it looks like?
10 important questions to add to your security questionnaire
We’ve identified 10 critical questions to include in your security questionnaire and why each answer is vital for informed decision-making.
