Businesses around the world use SOC 2 to demonstrate strong data security practices and build customer trust. In particular, organizations that handle customer data are now expected to have a SOC 2 attestation to win enterprise business.
For most organizations, the challenge isn’t deciding to pursue SOC 2 but understanding what it entails. Compliance can be a time-consuming, multi-layered process for teams pursuing it for the first time. This guide explains the core SOC 2 compliance requirements, including the Trust Services Criteria, required controls, audit expectations, and what you'll need to prepare before your assessment.
What is the goal of meeting SOC 2 compliance requirements?
The goal of meeting SOC 2 compliance requirements is to obtain a SOC 2 report, the official attestation document you receive following a successful SOC 2 audit. To acquire one, you must engage a licensed, independent CPA firm to evaluate your controls against the applicable SOC 2 Trust Services Criteria. The report validates whether your controls are aligned with SOC 2 trust principles, including their design, implementation, and, where applicable, operating effectiveness. The ultimate objective is to share the report with your prospects, customers, and partners as evidence of your security posture.
{{cta_withimage1="/cta-blocks"}} | SOC 2 compliance checklist
What are the SOC 2 compliance requirements?
SOC 2 requirements are unique among compliance standards. You don’t get a prescriptive list of controls to implement. Instead, SOC 2 takes a risk-based approach, requiring organizations to design and implement controls to address the risks relevant to their systems and services. For example, instead of directing you to implement specific firewalls to protect your data, it says: “The assessment of fraud risks includes consideration of threats and vulnerabilities that arise specifically from the use of IT and access to information.”
Because the criteria are broad and principle-based, every organization approaches and sets up its SOC 2 controls differently. As you pursue compliance, you’ll build security controls and policies that address your risk profile while satisfying the necessary criteria.
Because SOC 2 focuses on risk management rather than prescribing specific technical controls, many of the controls you implement naturally overlap with other frameworks and regulations, including ISO 27001, the GDPR, and HIPAA. If you’re aligned with any of these, you may already have a strong foundation for SOC 2.
"ISO 27001-certified organizations tend to have a head start on many SOC 2 controls, including risk assessment, logical access, operations, and change management, which map cleanly to ISO Annex A controls and existing ISMS processes.
HIPAA-aligned teams usually have access controls, audit logging, and incident response well covered under the Security Rule. Where both groups typically need additional work is the COSO-aligned governance criteria since SOC 2 expects explicit, evidenced board oversight, organizational structure documentation, and internal communication mechanisms that neither ISO 27001 nor HIPAA require in the same form.”
Regardless of your current compliance posture, meeting SOC 2 requirements starts with evaluating the Trust Services Criteria.
Trust Services Criteria 101
The Trust Services Criteria (TSC) are the foundation of SOC 2. They are the five categories that your auditor uses to evaluate whether your controls protect your systems and data. The five TSCs are:
- Security (Common Criteria): There are more than 30 individual criteria within the Security criterion, all of which are required for any organization seeking SOC 2. This category protects your organizational and customer data from unauthorized access.
- Availability: If employees and customers need the data you manage, they need to have consistent access. This category (criterion) ensures your data is available when needed for its intended function and that it can be recovered in case of a technical failure or data breach.
- Processing Integrity: If you process data on behalf of your customers, include processing integrity controls in your SOC 2 scope. This covers processes like running analytics, calculations, or otherwise manipulating data to produce a result. This category ensures you provide your customers with accurate calculations and information.
- Confidentiality: If your organization manages confidential data, like your customer’s business secrets, intellectual property, or personal information then you may need to include confidentiality in your SOC 2. The controls within this category ensure this data can only be accessed by the right people.
- Privacy: This criterion protects the rights of consumers and their data, giving them control over how their data is collected and used. It includes things like providing notice about data collection, obtaining consent, and honoring data deletion requests.
Meeting the Security criterion is mandatory for SOC 2 compliance, while the remaining four are required only when relevant to your products and services or the type of data you process.
How do the Trust Services Criteria translate into a list of SOC 2 controls?
Since the TSC don’t prescribe a fixed set of controls, your attestation approach should be:
- Scope which TSCs apply to you
- Design and implement controls that address your risk profile
- Map those controls to the relevant TSC
- Undergo an independent SOC 2 audit for attestation
You can maintain a SOC 2 controls list or matrix connecting individual criteria to the TSC, which serves as evidence for auditors.
For most organizations, the biggest challenge is determining which controls to implement. Experts suggest working backward from your service commitments.
"Teams often overengineer their SOC 2 programs by copying another organization's control list instead of designing controls for their own environment. In practice, you should determine relevant SOC 2 controls by working backward from your service commitments and system description, not forward from a control catalog.
Each TSC is satisfied by the controls you design to meet your service commitments, instead of hitting an arbitrary control count. If your design is traceable to the points of focus, your evidence demonstrates the control is operating effectively, and your auditor can follow the evidence trail from commitment to risk to control.”
Mandatory SOC 2 Security requirements (Common Criteria)
The table below provides an overview of the Security (Common Criteria):
Additional requirements
Security controls are necessary for every SOC 2 report. The other four criteria—Availability, Processing Integrity, Confidentiality, and Privacy–are scoped into your audit only when relevant to your business.
Trust Services Criteria: Common misunderstandings
A common mistake during SOC 2 attestation is interpreting the Trust Services Criteria too narrowly. While organizations may technically “meet” a criterion, they miss the intention behind it.
For example, organizations often treat the communication criteria (CC 2.2 and CC 2.3) as a one-way exercise by publishing policies. They fail to demonstrate how the two-way communication mechanism works in their team.
Risk assessment (CC 3.4) is another common gap. Organizations often focus on IT change management, without accounting for risks like changes in the regulatory landscape, business model, and vendor relationships.
Vendor risk management (CC 9.2) is regularly reduced to maintaining a vendor inventory, when it should ideally cover the full vendor lifecycle, including risk-based tiering, proportional due diligence, contractual alignment, ongoing monitoring, and termination.
If your SOC 2 report includes the Availability, Processing Integrity, or Privacy categories, pay close attention to controls covering each. Recurring gaps include skipping recovery testing (A1.2), investing too little in input validation and output reconciliation controls (PI1.1–1.5), and focusing on privacy notice and consent while neglecting data subject access, third-party disclosure, and monitoring obligations (P5, P6, P8).
{{cta_withimage1="/cta-blocks"}} | SOC 2 compliance checklist
SOC 2 Type 1 vs Type 2 requirements
There are two types of SOC 2 reports: SOC 2 Type 1 and SOC 2 Type 2. A SOC 2 Type 1 report expresses an opinion on the suitability of design of your controls as of a specific date. A SOC 2 Type 2 report expresses an opinion on the suitability of design and the operating effectiveness of your controls throughout a defined observation period (typically 3–12 months).
The underlying SOC 2 requirements are the same for both report types. The difference lies in audit timelines and documentation required. Type 1 requires evidence that your controls are suitably designed as of a point in time. Type 2 requires evidence that your controls were suitably designed and operated effectively throughout the observation period. Common evidence includes:
- System-generated artifacts like configuration exports, log samples, vulnerability scans, and access tickets
- Process artifacts like change tickets, access reviews, vendor assessments, and incident records
- Governance artifacts like approved policies, meeting minutes, and training completion records
For Type 2 assessments, auditors also require full populations (including terminations and production changes during the review period), from which they can pull samples and test supporting evidence.
The most reliable evidence is automatically generated, timestamped, and traceable to the source system, which is why leading continuous monitoring GRC platforms have become the standard for conducting effectiveness tests.
Meet SOC 2 requirements confidently with Vanta
Vanta is the #1 agentic trust platform that fast-tracks the path to SOC 2 attestation by streamlining control mapping, implementation and testing, evidence collection, and audit readiness. You can plan and manage your program with the Vanta AI Agent, AI-powered remediation, and continuous monitoring dashboards.
Vanta’s SOC 2 solution comes with out-of-the-box features such as:
- 1,400+ automated tests supported by 400+ integrations
- Continuous evidence collection and alerts for gaps
- Smart policy builder to support documentation
- Smart, pre-populated system description templates
- Risk assessment workflows
- Ownership and accountability tracking
- Integration with Vanta’s Trust Center to demonstrate your SOC 2 attestation
Vanta’s partner network also gives you access to 100+ trusted audit firms who work in-platform or through the API to support your compliance activities.
Schedule a custom demo today and see how Vanta streamlines SOC 2 compliance.
{{cta_simple1="/cta-blocks"}} | SOC 2 product page
Preparing for a SOC 2 audit
SOC 2 compliance requirements: What does SOC 2 compliance involve?
Preparing for a SOC 2 audit
SOC 2 compliance requirements: What does SOC 2 compliance involve?
Download the checklist
Preparing for a SOC 2 audit
Looking to automate SOC 2 audit prep?
Businesses around the world use SOC 2 to demonstrate strong data security practices and build customer trust. In particular, organizations that handle customer data are now expected to have a SOC 2 attestation to win enterprise business.
For most organizations, the challenge isn’t deciding to pursue SOC 2 but understanding what it entails. Compliance can be a time-consuming, multi-layered process for teams pursuing it for the first time. This guide explains the core SOC 2 compliance requirements, including the Trust Services Criteria, required controls, audit expectations, and what you'll need to prepare before your assessment.
What is the goal of meeting SOC 2 compliance requirements?
The goal of meeting SOC 2 compliance requirements is to obtain a SOC 2 report, the official attestation document you receive following a successful SOC 2 audit. To acquire one, you must engage a licensed, independent CPA firm to evaluate your controls against the applicable SOC 2 Trust Services Criteria. The report validates whether your controls are aligned with SOC 2 trust principles, including their design, implementation, and, where applicable, operating effectiveness. The ultimate objective is to share the report with your prospects, customers, and partners as evidence of your security posture.
{{cta_withimage1="/cta-blocks"}} | SOC 2 compliance checklist
What are the SOC 2 compliance requirements?
SOC 2 requirements are unique among compliance standards. You don’t get a prescriptive list of controls to implement. Instead, SOC 2 takes a risk-based approach, requiring organizations to design and implement controls to address the risks relevant to their systems and services. For example, instead of directing you to implement specific firewalls to protect your data, it says: “The assessment of fraud risks includes consideration of threats and vulnerabilities that arise specifically from the use of IT and access to information.”
Because the criteria are broad and principle-based, every organization approaches and sets up its SOC 2 controls differently. As you pursue compliance, you’ll build security controls and policies that address your risk profile while satisfying the necessary criteria.
Because SOC 2 focuses on risk management rather than prescribing specific technical controls, many of the controls you implement naturally overlap with other frameworks and regulations, including ISO 27001, the GDPR, and HIPAA. If you’re aligned with any of these, you may already have a strong foundation for SOC 2.
"ISO 27001-certified organizations tend to have a head start on many SOC 2 controls, including risk assessment, logical access, operations, and change management, which map cleanly to ISO Annex A controls and existing ISMS processes.
HIPAA-aligned teams usually have access controls, audit logging, and incident response well covered under the Security Rule. Where both groups typically need additional work is the COSO-aligned governance criteria since SOC 2 expects explicit, evidenced board oversight, organizational structure documentation, and internal communication mechanisms that neither ISO 27001 nor HIPAA require in the same form.”
Regardless of your current compliance posture, meeting SOC 2 requirements starts with evaluating the Trust Services Criteria.
Trust Services Criteria 101
The Trust Services Criteria (TSC) are the foundation of SOC 2. They are the five categories that your auditor uses to evaluate whether your controls protect your systems and data. The five TSCs are:
- Security (Common Criteria): There are more than 30 individual criteria within the Security criterion, all of which are required for any organization seeking SOC 2. This category protects your organizational and customer data from unauthorized access.
- Availability: If employees and customers need the data you manage, they need to have consistent access. This category (criterion) ensures your data is available when needed for its intended function and that it can be recovered in case of a technical failure or data breach.
- Processing Integrity: If you process data on behalf of your customers, include processing integrity controls in your SOC 2 scope. This covers processes like running analytics, calculations, or otherwise manipulating data to produce a result. This category ensures you provide your customers with accurate calculations and information.
- Confidentiality: If your organization manages confidential data, like your customer’s business secrets, intellectual property, or personal information then you may need to include confidentiality in your SOC 2. The controls within this category ensure this data can only be accessed by the right people.
- Privacy: This criterion protects the rights of consumers and their data, giving them control over how their data is collected and used. It includes things like providing notice about data collection, obtaining consent, and honoring data deletion requests.
Meeting the Security criterion is mandatory for SOC 2 compliance, while the remaining four are required only when relevant to your products and services or the type of data you process.
How do the Trust Services Criteria translate into a list of SOC 2 controls?
Since the TSC don’t prescribe a fixed set of controls, your attestation approach should be:
- Scope which TSCs apply to you
- Design and implement controls that address your risk profile
- Map those controls to the relevant TSC
- Undergo an independent SOC 2 audit for attestation
You can maintain a SOC 2 controls list or matrix connecting individual criteria to the TSC, which serves as evidence for auditors.
For most organizations, the biggest challenge is determining which controls to implement. Experts suggest working backward from your service commitments.
"Teams often overengineer their SOC 2 programs by copying another organization's control list instead of designing controls for their own environment. In practice, you should determine relevant SOC 2 controls by working backward from your service commitments and system description, not forward from a control catalog.
Each TSC is satisfied by the controls you design to meet your service commitments, instead of hitting an arbitrary control count. If your design is traceable to the points of focus, your evidence demonstrates the control is operating effectively, and your auditor can follow the evidence trail from commitment to risk to control.”
Mandatory SOC 2 Security requirements (Common Criteria)
The table below provides an overview of the Security (Common Criteria):
Additional requirements
Security controls are necessary for every SOC 2 report. The other four criteria—Availability, Processing Integrity, Confidentiality, and Privacy–are scoped into your audit only when relevant to your business.
Trust Services Criteria: Common misunderstandings
A common mistake during SOC 2 attestation is interpreting the Trust Services Criteria too narrowly. While organizations may technically “meet” a criterion, they miss the intention behind it.
For example, organizations often treat the communication criteria (CC 2.2 and CC 2.3) as a one-way exercise by publishing policies. They fail to demonstrate how the two-way communication mechanism works in their team.
Risk assessment (CC 3.4) is another common gap. Organizations often focus on IT change management, without accounting for risks like changes in the regulatory landscape, business model, and vendor relationships.
Vendor risk management (CC 9.2) is regularly reduced to maintaining a vendor inventory, when it should ideally cover the full vendor lifecycle, including risk-based tiering, proportional due diligence, contractual alignment, ongoing monitoring, and termination.
If your SOC 2 report includes the Availability, Processing Integrity, or Privacy categories, pay close attention to controls covering each. Recurring gaps include skipping recovery testing (A1.2), investing too little in input validation and output reconciliation controls (PI1.1–1.5), and focusing on privacy notice and consent while neglecting data subject access, third-party disclosure, and monitoring obligations (P5, P6, P8).
{{cta_withimage1="/cta-blocks"}} | SOC 2 compliance checklist
SOC 2 Type 1 vs Type 2 requirements
There are two types of SOC 2 reports: SOC 2 Type 1 and SOC 2 Type 2. A SOC 2 Type 1 report expresses an opinion on the suitability of design of your controls as of a specific date. A SOC 2 Type 2 report expresses an opinion on the suitability of design and the operating effectiveness of your controls throughout a defined observation period (typically 3–12 months).
The underlying SOC 2 requirements are the same for both report types. The difference lies in audit timelines and documentation required. Type 1 requires evidence that your controls are suitably designed as of a point in time. Type 2 requires evidence that your controls were suitably designed and operated effectively throughout the observation period. Common evidence includes:
- System-generated artifacts like configuration exports, log samples, vulnerability scans, and access tickets
- Process artifacts like change tickets, access reviews, vendor assessments, and incident records
- Governance artifacts like approved policies, meeting minutes, and training completion records
For Type 2 assessments, auditors also require full populations (including terminations and production changes during the review period), from which they can pull samples and test supporting evidence.
The most reliable evidence is automatically generated, timestamped, and traceable to the source system, which is why leading continuous monitoring GRC platforms have become the standard for conducting effectiveness tests.
Meet SOC 2 requirements confidently with Vanta
Vanta is the #1 agentic trust platform that fast-tracks the path to SOC 2 attestation by streamlining control mapping, implementation and testing, evidence collection, and audit readiness. You can plan and manage your program with the Vanta AI Agent, AI-powered remediation, and continuous monitoring dashboards.
Vanta’s SOC 2 solution comes with out-of-the-box features such as:
- 1,400+ automated tests supported by 400+ integrations
- Continuous evidence collection and alerts for gaps
- Smart policy builder to support documentation
- Smart, pre-populated system description templates
- Risk assessment workflows
- Ownership and accountability tracking
- Integration with Vanta’s Trust Center to demonstrate your SOC 2 attestation
Vanta’s partner network also gives you access to 100+ trusted audit firms who work in-platform or through the API to support your compliance activities.
Schedule a custom demo today and see how Vanta streamlines SOC 2 compliance.
{{cta_simple1="/cta-blocks"}} | SOC 2 product page
Explore more SOC 2 articles
Introduction to SOC 2
Preparing for a SOC 2 audit
SOC 2 reporting and documentation
Streamlining SOC 2 compliance
SOC differences and similarities
Additional SOC 2 resources
Get started with SOC 2
Start your SOC 2 journey with these related resources.
The SOC 2 Compliance Checklist
Speed up SOC 2 audit prep with automation. This checklist shows how to simplify compliance, reduce audit friction, and unlock enterprise deals.
Vanta in Action: Compliance Automation
Demonstrating security compliance with a framework like SOC 2, ISO 27001, HIPAA, etc. is not only essential for scaling your business and raising capital, it also builds an important foundation of trust.
