SOC 2 Trust Services Criteria: What Each Category Requires and How to Meet It

The Structure of the Trust Services Criteria

The AICPA publishes the Trust Services Criteria (TSC) as the evaluative framework for SOC 2 examinations. The framework contains five categories. Security — formally called the Common Criteria — is mandatory in every SOC 2 engagement. The remaining four categories are selected based on the commitments your organization makes to customers in its system description and service agreements. Selecting criteria beyond Security is not optional if your service commitments encompass those areas — it is a statement of what you are accountable for.
The Common Criteria are organized into nine sub-groups (CC1 through CC9) covering control environment, communication and information, risk assessment, monitoring, logical access, system operations, change management, and risk mitigation. All five TSC categories are evaluated against these Common Criteria as a foundation, with additional criteria layered on top where applicable.

Security — The Common Criteria (Mandatory)

Security is the backbone of every SOC 2 report. The Common Criteria evaluate whether your organization’s systems are protected against unauthorized access, both logical and physical, and whether your governance structures support a sustained control environment.
Key control areas under the Common Criteria include: organizational governance and tone at the top (CC1), communication of information relevant to security (CC2), risk assessment processes (CC3), monitoring of controls (CC4), documented security policies (CC5), logical and physical access restrictions (CC6), system operations and incident management (CC7), change management processes (CC8), and risk mitigation for identified threats (CC9).
Evidence that auditors commonly sample for Security includes: organizational charts and role definitions, security policies and their version history, risk register and evidence of risk assessment activity, user access provisioning and de-provisioning records, multi-factor authentication configurations, change tickets and approval records, incident logs, and penetration testing or vulnerability scanning results.

Availability

The Availability criteria evaluate whether your system is available for operation and use as committed or agreed. This is relevant for any service organization whose customers depend on system uptime — cloud platforms, software-as-a-service providers, and managed service environments are the most common applicability scenarios.
Availability controls include: documented uptime commitments and SLAs, monitoring of system performance against those commitments, capacity management processes, business continuity and disaster recovery plans and test evidence, and incident response procedures specifically addressing availability incidents.
The distinction between Availability as a Trust Services Criteria and general IT availability management is the accountability dimension: your system description must articulate specific availability commitments, and your controls must demonstrably protect those commitments over the observation period.

Processing Integrity

Processing Integrity evaluates whether system processing is complete, valid, accurate, timely, and authorized. This criteria is most frequently in scope for organizations that process transactions on behalf of customers — payment processors, financial data platforms, and any service where the correctness of computational output is a customer commitment.
Controls under Processing Integrity include: input validation procedures, output reconciliation, error detection and correction processes, and monitoring for anomalous processing activity. Auditors look for evidence that your system does what it claims to do with the data it processes — and that failures are detected, logged, and corrected systematically.

Confidentiality

The Confidentiality criteria address whether information designated as confidential is protected as committed. Confidential information is defined in your system description and typically includes customer data, intellectual property, financial information, and any information subject to confidentiality obligations under contract or regulation.
Controls include: data classification and handling policies, encryption of confidential data in transit and at rest, access restrictions limiting confidential data to authorized roles, and secure disposal procedures. Confidentiality differs from Privacy in that it applies to a broader category of information — not solely personal information.
Organizations handling regulated data categories — healthcare records, financial data, defense-sensitive information — typically find that Confidentiality controls overlap significantly with their regulatory compliance obligations. Building controls that satisfy multiple frameworks simultaneously is a core element of Armorstack’s VERITY advisory approach.

Privacy

The Privacy criteria evaluate whether personal information is collected, used, retained, disclosed, and disposed of in conformity with the entity’s privacy notice and with criteria set forth in the AICPA’s Generally Accepted Privacy Principles (GAPP). Privacy is in scope when your organization collects, processes, or stores personal information on behalf of or from individuals.
Privacy controls include: a documented and accurate privacy notice, consent mechanisms, data subject rights processes (access, correction, deletion), data retention schedules and enforcement, breach notification procedures, and third-party data sharing controls. Organizations subject to CCPA, GDPR, HIPAA, or state privacy laws will find meaningful overlap between those regulatory requirements and the Privacy TSC, but the SOC 2 Privacy criteria are not a substitute for regulatory compliance — they are a complementary attestation.

Selecting Your Criteria Scope

The most important scoping decision in a SOC 2 program is determining which Trust Services Criteria your service commitments require you to include. Including criteria you cannot adequately evidence creates audit risk. Excluding criteria that your customer commitments imply creates contractual and reputational risk. The starting point is your system description — a precise, accurate statement of what your service does, what data it handles, and what commitments you make to customers.
Armorstack’s VERITY practice works through this scoping exercise as the first step of every SOC 2 engagement. Getting it right eliminates scope creep during fieldwork and produces a report that accurately represents what your customers need to evaluate.
For the evidence requirements that flow from these criteria, review the SOC 2 audit checklist. For the question of Type I versus Type II and how auditors evaluate these criteria differently in each, see the Type I vs Type II comparison. Return to the SOC 2 compliance overview or the full compliance hub. Continuous monitoring that generates evidence across all five criteria categories is delivered through Armorstack’s managed detection and response program.