SOC 2 Trust Service Criteria: The Five Pillars Explained
SOC 2 compliance is built on five Trust Service Criteria (TSC) defined by the American Institute of Certified Public Accountants (AICPA). These criteria, formerly called Trust Service Principles, form the evaluation framework that auditors use to assess your organization's controls. Security is required for every SOC 2 audit. The remaining four, Availability, Processing Integrity, Confidentiality, and Privacy, are optional and selected based on what your customers and business model demand.
Understanding each criterion in detail is essential for scoping your audit correctly, building the right controls, and avoiding costly surprises during the examination. For a practical breakdown of what auditors check, see our SOC 2 compliance checklist.
Security: The Required Foundation
Security is the only mandatory Trust Service Criterion. It appears in every SOC 2 report regardless of scope. The Security criterion, often called the Common Criteria, evaluates whether your systems are protected against unauthorized access, both physical and logical.
The AICPA defines Security through a series of Common Criteria (CC) control points organized into nine categories:
- CC1: Control Environment. The organization demonstrates a commitment to integrity and ethical values. This includes board oversight, organizational structure, and accountability for internal controls.
- CC2: Communication and Information. The organization uses relevant, quality information to support internal controls and communicates that information internally and externally.
- CC3: Risk Assessment. The organization identifies and analyzes risks to achieving its objectives, including fraud risks and changes that could significantly affect the system.
- CC4: Monitoring Activities. The organization monitors, evaluates, and communicates the effectiveness of its controls on an ongoing basis.
- CC5: Control Activities. The organization implements control activities through policies and procedures, including technology controls and segregation of duties.
- CC6: Logical and Physical Access Controls. This covers access management: user provisioning, authentication, authorization, encryption, and physical security of data centers and offices.
- CC7: System Operations. The organization detects and responds to anomalies, monitors infrastructure, and manages incidents.
- CC8: Change Management. The organization manages changes to infrastructure, data, software, and procedures in a controlled manner.
- CC9: Risk Mitigation. The organization identifies and assesses risks from vendors, business partners, and other third parties.
Availability: Keeping Systems Operational
The Availability criterion assesses whether your system is available for operation and use as committed or agreed. This matters most for SaaS products, cloud infrastructure, and any service where downtime directly impacts customer operations.
Availability does not mean 100% uptime. It means your organization has defined uptime commitments (typically through SLAs), monitors against those commitments, and has processes to maintain and restore availability when disruptions occur.
Key control areas for Availability include:
Capacity planning and performance monitoring. You need to demonstrate that you monitor system performance, track capacity trends, and scale resources before constraints impact availability. This includes CPU, memory, storage, network bandwidth, and application-level metrics.
Disaster recovery and business continuity. A documented DR plan with defined Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) is essential. The plan must be tested at least annually, with test results documented and deficiencies addressed.
Incident management. Your organization must have documented procedures for identifying, escalating, and resolving incidents that affect availability. Mean Time to Detect (MTTD) and Mean Time to Resolve (MTTR) are key metrics auditors review.
Backup and restoration. Regular backups of critical data and systems, with verified restoration procedures. Auditors will look for evidence that backups are tested, not just that they exist.
Environmental protections. Physical infrastructure (whether owned or cloud-based) must have protections against power failure, fire, flooding, and other environmental threats. For organizations using AWS, Azure, or GCP, the cloud provider handles much of this, but you need to demonstrate multi-region or multi-AZ architecture where availability commitments require it.
Processing Integrity: Accurate and Complete Data Processing

Processing Integrity evaluates whether system processing is complete, valid, accurate, timely, and authorized. This criterion is most relevant for organizations that process transactions, financial data, calculations, or any data transformation where errors could have downstream consequences.
This is not about data accuracy at input. Processing Integrity focuses on what happens to data after it enters your system. Does your software transform it correctly? Are calculations performed accurately? Do processes execute in the right order and within expected timeframes?
Key control areas include:
Input validation. Controls that ensure data entering the system meets defined criteria for completeness and accuracy. This includes format checks, range validations, and duplicate detection.
Processing monitoring. Mechanisms to verify that processing occurs as designed. This includes reconciliation procedures, exception handling, and automated alerts when processing deviates from expected parameters.
Output verification. Controls that confirm processing output is complete and accurate before delivery to end users or downstream systems. This might include checksum validations, record count comparisons, or manual review for high-value transactions.
Error handling and correction. Documented procedures for identifying, logging, and correcting processing errors. The organization must demonstrate that errors are tracked to resolution and that root causes are addressed to prevent recurrence.
Confidentiality: Protecting Sensitive Information
The Confidentiality criterion evaluates whether information designated as confidential is protected as committed or agreed. This applies to any non-public information: trade secrets, intellectual property, financial data, business plans, customer lists, and any data your organization has committed to protect.
Confidentiality is distinct from Privacy (covered next). Confidentiality applies to all types of sensitive information. Privacy applies specifically to personal information. An organization can have confidentiality obligations without having privacy obligations, and vice versa.
Key control areas include:
Data classification. The organization must have a formal data classification policy that defines what constitutes confidential information. Without clear classification, it is impossible to demonstrate that appropriate protections are applied consistently.
Encryption. Confidential data must be encrypted at rest and in transit. AES-256 for storage and TLS 1.2+ for transmission are the current standards. Key management procedures must be documented, including key rotation schedules and access restrictions.
Access controls. Access to confidential information must follow the principle of least privilege. Only individuals with a documented business need should have access. Access reviews should be conducted at least quarterly.
Data retention and disposal. The organization must define how long confidential data is retained and how it is securely destroyed when no longer needed. This includes digital data (secure deletion, cryptographic erasure) and physical media (shredding, degaussing).
Vendor management. If confidential data is shared with third parties, those relationships must be governed by NDAs or equivalent agreements, and the third party's security posture must be assessed.
Privacy: Protecting Personal Information
The Privacy criterion evaluates how your organization collects, uses, retains, discloses, and disposes of personal information. Personal information is any data that can be used to identify an individual: names, email addresses, phone numbers, Social Security numbers, IP addresses, and similar identifiers.
Privacy is the most prescriptive of the five criteria. It is based on the AICPA's Generally Accepted Privacy Principles (GAPP), which define eight privacy obligations:
1. Notice. The organization provides notice about its privacy practices, including what personal information it collects, how it uses it, and with whom it shares it. This typically takes the form of a privacy policy.
2. Choice and Consent. Individuals are given choices about the collection, use, and disclosure of their personal information. Consent mechanisms must be appropriate to the sensitivity of the data.
3. Collection. The organization collects personal information only for the purposes identified in its notice. Collection must be limited to what is necessary for those purposes.
4. Use, Retention, and Disposal. Personal information is used only for the purposes identified in the privacy notice. Retention periods are defined, and data is securely disposed of when no longer needed.
5. Access. Individuals can access their personal information for review and update. The organization must provide a mechanism for individuals to request access and must respond within a defined timeframe.
6. Disclosure to Third Parties. Personal information is disclosed to third parties only for the purposes identified in the privacy notice and with appropriate safeguards.
7. Security for Privacy. Personal information is protected against unauthorized access using the same types of controls described under the Security criterion.
8. Quality. The organization maintains accurate, complete, and relevant personal information for the purposes identified in the privacy notice.
How to Choose Which Criteria to Include

Selecting the right combination of Trust Service Criteria depends on your business model, customer requirements, and contractual obligations.
Start with Security. It is mandatory and covers the broadest set of controls. Most organizations begin with a Security-only SOC 2 Type I to establish their baseline.
Add Availability if you provide SaaS, cloud infrastructure, or any service with uptime SLAs. Enterprise customers with mission-critical workflows will expect this criterion.
Add Processing Integrity if your system performs financial calculations, data transformations, or automated decision-making where accuracy is critical. Fintech, healthcare data processing, and payroll companies frequently include this criterion.
Add Confidentiality if you handle trade secrets, proprietary data, or business-sensitive information for clients. This is common for consulting firms, legal technology platforms, and data analytics companies.
Add Privacy if you collect and process personal information about end users (not just business contacts). This is increasingly expected for consumer-facing products and any organization subject to privacy regulations.
Most organizations include Security and Availability as their starting point. The combination of Security, Availability, and Confidentiality covers the majority of enterprise customer requirements.
Mapping Trust Service Criteria to Common Frameworks
If your organization is already aligned with another compliance framework, significant overlap exists:
| Trust Service Criterion | ISO 27001 | NIST CSF | HIPAA | SOX | |---|---|---|---|---| | Security | Annex A controls | All five functions | Security Rule | IT General Controls | | Availability | A.17 (Continuity) | Protect, Respond, Recover | Contingency Plan | Business continuity | | Processing Integrity | A.14 (System acquisition) | Protect | Integrity controls | Financial reporting accuracy | | Confidentiality | A.8, A.13 (Asset mgmt, Comms) | Protect | Privacy Rule (partial) | Data classification | | Privacy | A.18 (Compliance) | Protect | Privacy Rule | Privacy controls |
Organizations with ISO 27001 certification typically find that 60 to 70% of SOC 2 Security controls are already addressed. NIST CSF alignment covers a similar percentage. The gap is usually in documentation format and the specific evidence required by SOC 2 auditors.
Frequently Asked Questions
Do I need all five Trust Service Criteria for SOC 2?
No. Security is the only required criterion. The other four (Availability, Processing Integrity, Confidentiality, Privacy) are optional and should be selected based on your business model and customer requirements.
What is the difference between SOC 2 Trust Service Criteria and Trust Service Principles?
They are the same thing. The AICPA renamed Trust Service Principles to Trust Service Criteria in 2017 to better reflect their role as evaluation standards. Some older resources still use the term "principles."
Can I add more criteria to my SOC 2 report later?
Yes. Many organizations start with Security only for their first SOC 2 Type I report, then add Availability and Confidentiality in subsequent reporting periods. Each additional criterion requires its own set of controls, policies, and evidence.
How long does it take to prepare for a SOC 2 audit covering all five criteria?
A full five-criteria SOC 2 audit typically requires 6 to 12 months of preparation for a first-time audit. Organizations that start with Security only can often prepare in 3 to 6 months, then add criteria incrementally.
Which Trust Service Criteria do enterprise customers most commonly require?
Security and Availability are requested most frequently. Confidentiality is the third most common, particularly from customers in regulated industries. Processing Integrity and Privacy are less commonly required but increasingly important for fintech and consumer-facing products.
How do the Trust Service Criteria relate to the Common Criteria?
The Common Criteria (CC1 through CC9) are the specific control points under the Security criterion. They form the foundation of every SOC 2 report. The additional criteria (Availability, Processing Integrity, Confidentiality, Privacy) have their own supplemental control points that build on the Common Criteria.
