SOC 2 Trust Services Criteria: All Five Explained

The Trust Services Criteria are the measuring stick against which every SOC 2 examination is conducted. They define what a service organization’s controls must achieve — and CertPro CPA LLC tests whether those controls actually achieved it throughout the observation period.

The SOC 2 Trust Services Criteria are published by the AICPA and cover five domains: Security, Availability, Confidentiality, Processing Integrity, and Privacy. Security is required in every SOC 2 engagement — it forms the foundation of every report. The remaining four are selected based on the commitments the service organization makes to its customers and the nature of the data it processes.

Selecting the right criteria for your engagement is one of the most consequential scoping decisions in the SOC 2 process. Include too few and your report may not satisfy buyer requirements. Include too many and you expand fieldwork, cost, and control implementation burden unnecessarily. This guide from CertPro CPA LLC explains exactly what each criterion covers, which organizations need it, and how it is tested.

Tl; DR:

Concern: With SOC 2 scoping decisions directly affecting audit cost, timeline, and report coverage, service organizations find it hard to determine which Trust Services Criteria apply to their specific services — and what each criterion actually requires in terms of implemented controls.
Overview: The SOC 2 Trust Services Criteria are the five categories of control requirements published by the AICPA against which a licensed CPA firm evaluates a service organization’s control environment — Security is mandatory in every engagement, while Availability, Confidentiality, Processing Integrity, and Privacy are selected based on the nature of the services provided.
Solution: Service organizations should understand what each of the five Trust Services Criteria requires, which criteria apply to their specific service model, and how selecting the right criteria set produces a SOC 2 report that satisfies enterprise buyer requirements without unnecessary scope expansion.

SOC 2 Trust Services Criteria: All Five Explained

The Trust Services Criteria are the framework against which CertPro CPA LLC conducts every SOC 2 examination. They define the control objectives — the outcomes a service organization’s controls must achieve — and the specific control requirements mapped to each objective. For the authoritative source on the TSC framework, see the AICPA’s SOC Suite of Services documentation.

How the Trust Services Criteria Are Organized

The Trust Services Criteria are structured in two layers:

The Common Criteria — a set of control requirements that apply to the Security criterion and also serve as the foundation for the other four criteria. Every SOC 2 engagement tests the Common Criteria regardless of which additional criteria are in scope. For a detailed breakdown, see SOC 2 Common Criteria.

Criterion-specific additional criteria — each of the four additional criteria (Availability, Confidentiality, Processing Integrity, Privacy) adds a set of control requirements specific to that criterion’s subject matter.

The result is a modular structure: every engagement includes the Common Criteria, and each additional criterion adds its own layer of specific requirements on top.

Criterion 1 — Security (CC Series) — Mandatory

The Security criterion evaluates whether the service organization’s system is protected against unauthorized access — both logical and physical — and whether the organization has the controls necessary to detect security events, respond to incidents, manage changes, and maintain security governance.

Security is the only mandatory Trust Services Criterion. It is required in every SOC 2 engagement regardless of the nature of the services provided. An engagement that covers only the Security criterion is described as a Security-only SOC 2 examination.

What the Security criterion requires: The Security criterion is organized around the Common Criteria — nine control categories covering: Control environment and governance (CC1), Communication of security information (CC2), Risk assessment (CC3), Monitoring of control effectiveness (CC4), Control activities — policies and procedures (CC5), Logical and physical access controls (CC6), System operations — monitoring, incident response (CC7), Change management (CC8), and Risk mitigation — vendor management, business continuity (CC9).

Which organizations need it: Every service organization that pursues SOC 2. The Security criterion is the baseline — it cannot be excluded.

What buyers look for: Enterprise buyers who request a Security-only report want assurance that the service organization has implemented controls across all nine Common Criteria categories. Access management, change management, incident response, monitoring, and vendor management are the control areas buyers examine most closely. For a full breakdown, see SOC 2 Controls.

Criterion 2 — Availability (A Series)

The Availability criterion evaluates whether the service organization’s system is available for operation and use as committed or agreed — typically through service level agreements, uptime guarantees, or contractual availability commitments.

A1.1 — Availability commitments and capacity management
The organization has defined its availability commitments to customers, monitors system capacity to ensure those commitments can be met, and adjusts capacity proactively when monitoring indicates that current capacity may be insufficient.
Control examples: Uptime monitoring with defined alerting thresholds, capacity planning reviews, infrastructure scaling procedures, and SLA performance reporting.

A1.2 — Availability monitoring and incident response
The organization monitors the availability of the in-scope system on an ongoing basis, detects availability events promptly, and responds according to documented procedures to restore service within committed recovery timeframes.
Control examples: Availability monitoring dashboards, on-call procedures, incident escalation protocols, and mean time to recovery tracking.

A1.3 — Recovery testing
The organization tests its backup and recovery capabilities periodically to verify that data can be restored and services can be resumed within the recovery time and recovery point objectives defined in its availability commitments.
Control examples: Backup restoration tests, disaster recovery drills, and documented test results with identified gaps and remediation actions.

Which organizations need Availability: Organizations whose customers depend on continuous or high-availability service delivery — SaaS platforms with uptime SLAs, cloud infrastructure providers, payment processing platforms, healthcare systems where availability is safety-critical, and any service where downtime directly affects customers’ business operations.

What buyers look for: Evidence that the organization monitors uptime continuously, responds to availability events within committed timeframes, and tests its recovery capabilities regularly. Buyers in healthcare, financial services, and critical infrastructure sectors apply particularly rigorous scrutiny to Availability controls.

Criterion 3 — Confidentiality (C Series)

The Confidentiality criterion evaluates whether information designated as confidential is protected throughout its lifecycle — from collection through processing, storage, transmission, and disposal — in accordance with the organization’s confidentiality commitments and applicable legal requirements.

C1.1 — Identifying confidential information
The organization has a defined process for identifying information that is required to be kept confidential — based on contractual obligations, legal requirements, and the sensitivity of the data processed. This typically involves a data classification framework.
Control examples: Data classification policy, data inventory mapping, contractual confidentiality obligations register, and confidentiality agreement templates for personnel and vendors.

C1.2 — Protecting confidential information
The organization implements technical and procedural controls to protect confidential information against unauthorized access, disclosure, or use throughout its lifecycle.
Control examples: Encryption at rest and in transit, access controls restricting confidential data to authorized personnel, data loss prevention tools, and confidentiality training for personnel with access to sensitive data.

C1.3 — Disposing of confidential information
When confidential information is no longer needed, it is disposed of in a manner that renders it permanently unrecoverable — using secure deletion for electronic media and physical destruction for hard media.
Control examples: Secure deletion procedures, media destruction records, retention and disposal schedules, and vendor disposal certifications.

Which organizations need Confidentiality: Organizations that process proprietary business data, trade secrets, attorney-client privileged information, financial models, pharmaceutical research data, or any information where confidentiality is a contractual or regulatory requirement.

What buyers look for: Evidence that confidential data is classified, encrypted, access-controlled, and disposed of securely. Buyers in regulated sectors — legal, finance, pharmaceuticals — give particular weight to Confidentiality controls when evaluating service providers.

Criterion 4 — Processing Integrity (PI Series)

The Processing Integrity criterion evaluates whether system processing is complete, valid, accurate, timely, and authorized — ensuring that the service organization processes data correctly and that errors or unauthorized manipulations are detected and corrected.

PI1.1 — Defining processing objectives
The organization has defined the processing objectives for the in-scope system — what the system is supposed to do, what constitutes correct processing, and what the acceptable error rate is.
Control examples: System design documentation, processing specifications, and acceptance criteria for system outputs.

PI1.2 — Input validation
The organization validates data inputs to the in-scope system to detect and reject invalid, incomplete, or unauthorized inputs before processing occurs.
Control examples: Input validation rules, error handling procedures, and rejected input logs.

PI1.3 — Processing monitoring
The organization monitors system processing on an ongoing basis to detect errors, anomalies, and unauthorized processing activities — and investigates and resolves identified issues promptly.
Control examples: Transaction monitoring dashboards, processing error logs, and reconciliation procedures.

PI1.4 — Output validation
The organization validates system outputs to verify that processing was complete and accurate — including reconciliation of inputs to outputs and review of output quality before delivery to customers.
Control examples: Output reconciliation procedures, delivery confirmation records, and output quality review documentation.

PI1.5 — Error correction
Identified processing errors are investigated, corrected, and communicated to affected parties — with root cause analysis conducted to prevent recurrence.
Control examples: Error correction logs, customer notification records, and root cause analysis documentation.

Which organizations need Processing Integrity: Organizations where data accuracy is critical — payment processors, healthcare data platforms, financial reporting services, and any platform where customers rely on the service organization to process data correctly.

What buyers look for: Evidence that input validation, processing monitoring, output validation, and error correction controls are operating consistently throughout the observation period. Financial institution buyers and healthcare customers give Processing Integrity significant weight.

Criterion 5 — Privacy (P Series)

The Privacy criterion evaluates whether the service organization collects, uses, retains, discloses, and disposes of personal information in accordance with its privacy notice and applicable privacy regulations — including GDPR, CCPA, HIPAA, and other applicable frameworks.

The Privacy criterion maps to the AICPA’s Generally Accepted Privacy Principles (GAPP) — a framework of eight privacy principles that align closely with the requirements of major privacy regulations:

P1 — Notice
The organization provides notice about its privacy practices — including what personal information it collects, why it is collected, how it is used, and with whom it is shared — through a privacy notice made available before or at the time of data collection.
Control examples: Privacy notice documentation, consent management processes, and privacy notice version control.

P2 — Choice and Consent
The organization provides individuals with choices about how their personal information is collected, used, and disclosed — and obtains consent where required by applicable regulations.
Control examples: Consent collection mechanisms, opt-out processes, and consent records.

P3 — Collection
The organization collects only the personal information necessary for the purposes described in its privacy notice — implementing data minimization principles.
Control examples: Data collection reviews, privacy impact assessments, and data minimization policies.

P4 — Use, Retention, and Disposal
Personal information is used only for the purposes described in the privacy notice, retained only for as long as necessary, and disposed of securely when no longer needed.
Control examples: Data retention schedules, automated deletion procedures, and use restriction controls.

P5 — Access
Individuals have the right to access their personal information and to request corrections — and the organization has processes to fulfill these requests within defined timeframes.
Control examples: Data subject access request procedures, response time tracking, and correction records.

P6 — Disclosure to Third Parties
Personal information is disclosed to third parties only in accordance with the privacy notice and applicable legal requirements — with appropriate contractual protections in place.
Control examples: Data processing agreements, third-party disclosure logs, and subprocessor management processes.

P7 — Security for Privacy
The organization implements security controls specifically designed to protect personal information against unauthorized access, disclosure, or use — going beyond the baseline Security criterion to address privacy-specific risks.
Control examples: Personal data encryption, pseudonymization, access logging for personal data systems, and breach notification procedures.

P8 — Quality
The organization maintains personal information in a form that is accurate, complete, and current — and has processes for individuals to request corrections.
Control examples: Data quality checks, correction request procedures, and data accuracy monitoring.

Which organizations need Privacy: Organizations that collect and process personal information — particularly those subject to GDPR, CCPA, HIPAA, or other privacy regulations. SaaS platforms that collect user data, healthcare technology vendors, HR platforms, and marketing platforms handling consumer profiles are typical candidates.

What buyers look for: Evidence that personal data collection is limited to stated purposes, consent is obtained where required, data subject rights requests are fulfilled promptly, and personal data is protected by controls that go beyond the baseline Security criterion. EU-based buyers and healthcare sector buyers give Privacy controls particular scrutiny.

How to Select the Right Trust Services Criteria

The right criteria set for your SOC 2 engagement is determined by two factors: the nature of your services and the commitments you have made to your customers.

Start with your customer contracts — review your service agreements and data processing agreements to identify the security, availability, confidentiality, and privacy commitments you have made. The criteria you select should cover the commitments documented in those agreements.

Consider your buyer requirements — some enterprise buyers specify which criteria they require. Healthcare buyers frequently require Security and Availability. Financial services buyers may require Processing Integrity. EU-based buyers or those subject to GDPR often require Privacy.

Match criteria to your service model — a cloud storage platform processing sensitive client data is a natural candidate for Security, Availability, and Confidentiality. A payment processor is a natural candidate for Security and Processing Integrity. A healthcare data analytics platform may need all five.

Avoid unnecessary scope expansion — including criteria that do not reflect your service model or your customer commitments adds cost and control burden without adding value to your buyers. CertPro CPA LLC advises on the optimal criteria set during the audit scoping phase.

Begin Your SOC 2 Examination with CertPro CPA LLC

CertPro CPA LLC is a licensed CPA firm that conducts SOC 2 examinations across all five Trust Services Criteria under AICPA AT-C Section 205. Our scoping process identifies the right criteria set for your service model and customer requirements — producing a report that satisfies enterprise buyers without unnecessary scope or cost.

Explore the full SOC 2 hub for detailed guidance on every aspect of the SOC 2 process.

Ready to begin? Contact CertPro CPA LLC to scope your SOC 2 engagement.

FAQ