9.1 Trust Services Criteria (TSC) for SOC 2 Engagements

Trust Services Criteria (TSC) for SOC 2 Engagements

Quick Summary: A SOC 2 examination provides assurance regarding controls at a service organization relevant to one or more of the five Trust Services Categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Established by the AICPA under SSAE 21 (Clarified Attestation Standards, specifically AT-C section 205, Assertion-Based Examination Engagements), SOC 2 evaluates the operational and technical controls of technology service providers. Security—termed the Common Criteria (CC series)—is mandatory in every SOC 2 report and incorporates the 17 principles of the COSO 2013 Internal Control—Integrated Framework. The remaining four categories are modular, scoped in based on management's commitments and system functionality.

---

1. The Trust Services Criteria (TSC) Architecture & SSAE 21 Framework

In modern cloud architectures, enterprise software, and outsourced business processes, user entities rely extensively on third-party service organizations. SOC 2 reports are attestation reports designed to provide user entities, their independent auditors, regulators, and business partners with independent assurance regarding how a service organization secures and processes data.

Authoritative Guidance

SOC 2 examinations are governed by:

• SSAE 21 / AT-C section 205: Establishes the performance and reporting standards for examination engagements.
• AICPA Description Criteria (DC section 200): Governs the criteria management uses to prepare and present the description of the service organization's system in Section III of the report.
• AICPA Trust Services Criteria (TSP section 100): Establishes the control criteria evaluated by the independent service auditor.

The Five Trust Services Categories

The Trust Services Criteria framework is organized into five discrete categories. While organizations frequently refer to "SOC 2 compliance," SOC 2 is not a one-size-fits-all pass/fail certification; it is an attestation engagement scoped to specific categories:

1. Security (Common Criteria): Information and systems are protected against unauthorized access, unauthorized disclosure of information, and damage to systems that could compromise the availability, integrity, confidentiality, or privacy of information or systems. Security is the mandatory core of every SOC 2 examination.
2. Availability: Information and systems are available for operation and use to meet the entity's commitments and system requirements (e.g., system uptime, data recovery, business continuity).
3. Processing Integrity: System processing is complete, valid, accurate, timely, and authorized to meet the entity's objectives (e.g., financial transactions, algorithmic calculations, billing systems).
4. Confidentiality: Information designated as confidential is protected to meet the entity's commitments and system requirements (e.g., proprietary corporate source code, intellectual property, sensitive financial records).
5. Privacy: Personal information is collected, used, retained, disclosed, and disposed of to meet the entity's commitments and system requirements. The privacy criteria live in the Trust Services Criteria themselves (P1.0 through P8.0) — they are not the old Generally Accepted Privacy Principles. The AICPA replaced GAPP (2009, ten principles) with the Privacy Management Framework (PMF, 2020, nine components); the PMF is a management framework, while TSP section 100's P-series is what a SOC 2 service auditor examines against.

+-----------------------------------------------------------------------------------+
|                     MODULAR SOC 2 TRUST SERVICES ARCHITECTURE                     |
+-----------------------------------------------------------------------------------+
|               OPTIONAL / MODULAR CATEGORIES (Selected Based on Scope)             |
|   +----------------+   +----------------------+   +-----------------+   +-----+   |
|   |  Availability  |   | Processing Integrity |   | Confidentiality |   | ... |   |
|   |  (A1.1 - A1.3) |   |    (PI1.1 - PI1.5)   |   |  (C1.1 - C1.2)  |   |     |   |
|   +-------+--------+   +----------+-----------+   +--------+--------+   +--+--+   |
|           |                       |                        |               |      |
+-----------|-----------------------|------------------------|---------------|------+
|           v                       v                        v               v      |
|   +---------------------------------------------------------------------------+   |
|   |                  MANDATORY BASELINE: SECURITY / COMMON CRITERIA           |   |
|   |                            (CC1.0 - CC9.0)                                |   |
|   |  CC1-CC5: COSO 2013 Principles (Control Env, Comm, Risk, Monitor, Act)    |   |
|   |  CC6-CC9: IT-Specific (Access, Operations, Change Mgmt, Risk Mitigation)  |   |
|   +---------------------------------------------------------------------------+   |
+-----------------------------------------------------------------------------------+

---

2. Criteria vs. Controls: The Fundamental Architectural Distinction

A central concept tested on the CPA ISC examination is the precise structural distinction between criteria and controls:

• Criteria ("The What"): Standardized, objective benchmarks promulgated by the AICPA that define the operational conditions a system must achieve. For example, criterion CC6.1 states: "The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet its commitments and system requirements." Criteria are uniform across all organizations undergoing a SOC 2 audit.
• Controls ("The How"): The specific, proprietary organizational policies, technical configurations, physical safeguards, and manual procedures designed and implemented by the service organization's management to satisfy the criteria. For example, to satisfy CC6.1, Company Alpha might implement Okta Single Sign-On with phishing-resistant FIDO2 security keys and automated session timeouts of 15 minutes, whereas Company Beta might implement Microsoft Entra ID with conditional access policies and smart cards. Both sets of controls satisfy the same AICPA criterion.

---

3. Deep Dive: The Common Criteria Series (CC1.0 – CC9.0)

The Common Criteria are structured into nine distinct series (CC1.0 through CC9.0). Crucially, the first five series (CC1.0 through CC5.0) directly incorporate the 17 internal control principles from the COSO 2013 Internal Control—Integrated Framework. Series CC6.0 through CC9.0 add supplemental criteria specific to information technology systems, operations, access, and third-party risk.

CC1.0 Series: Control Environment (COSO Principles 1–5)

Evaluates the organizational tone at the top, ethical values, and oversight structure:

• CC1.1 (COSO Principle 1): Commitment to integrity and ethical values (e.g., formal code of conduct, whistleblower hotline, annual ethics acknowledgments).
• CC1.2 (COSO Principle 2): Board of directors / audit committee independence and oversight of internal control.
• CC1.3 (COSO Principle 3): Management establishes structures, reporting lines, and appropriate authorities and responsibilities.
• CC1.4 (COSO Principle 4): Commitment to attract, develop, and retain competent individuals aligned with objectives.
• CC1.5 (COSO Principle 5): Holding individuals accountable for their internal control responsibilities (e.g., performance evaluations, disciplinary policies).

CC2.0 Series: Communication and Information (COSO Principles 13–15)

Evaluates how the organization identifies, captures, and exchanges internal and external information:

• CC2.1 (COSO Principle 13): The entity obtains or generates and uses relevant, quality information to support internal control functioning.
• CC2.2 (COSO Principle 14): Internal communication of objectives and responsibilities necessary to support internal control (e.g., security policies distributed via intranet).
• CC2.3 (COSO Principle 15): External communication with customers, regulators, and third parties regarding matters affecting internal control (e.g., security incident notifications, customer terms of service).

CC3.0 Series: Risk Assessment (COSO Principles 6–9)

Evaluates the formal processes used to identify and manage operational, technological, and environmental threats:

• CC3.1 (COSO Principle 6): Specifies objectives with sufficient clarity to enable the identification and assessment of risks relating to objectives.
• CC3.2 (COSO Principle 7): Identifies risks to the achievement of its objectives across the entity and analyzes risks to determine how they should be managed.
• CC3.3 (COSO Principle 8): Considers the potential for fraud in assessing risks to the achievement of objectives.
• CC3.4 (COSO Principle 9): Identifies and assesses changes that could significantly affect the system of internal control (e.g., mergers, corporate restructuring, rapid technological shifts).

CC4.0 Series: Monitoring Activities (COSO Principles 16–17)

Evaluates continuous and periodic assessments of internal control effectiveness:

• CC4.1 (COSO Principle 16): Selects, develops, and performs ongoing and/or separate evaluations to ascertain whether internal controls are present and functioning (e.g., internal audit reviews, automated security posture assessments).
• CC4.2 (COSO Principle 17): Evaluates and communicates internal control deficiencies in a timely manner to responsible parties and senior management.

CC5.0 Series: Control Activities (COSO Principles 10–12)

Evaluates policies and procedures that ensure management directives to mitigate risks are carried out:

• CC5.1 (COSO Principle 10): Selects and develops control activities that contribute to the mitigation of risks to acceptable levels.
• CC5.2 (COSO Principle 11): Selects and develops general control activities over technology (ITGCs) to support the achievement of objectives.
• CC5.3 (COSO Principle 12): Deploys control activities through policies that establish what is expected and procedures that put policies into action.

CC6.0 Series: Logical and Physical Access Controls (IT-Specific Supplemental Criteria)

Covers the identification, authentication, authorization, and physical safeguarding of enterprise infrastructure:

• CC6.1: Implements logical access security software, firewalls, and network boundaries to prevent unauthorized external access.
• CC6.2: User registration and access modification procedures (new hire provisioning, role changes, and immediate deprovisioning upon termination).
• CC6.3: Enforces least privilege and Role-Based Access Control (RBAC); grants permissions strictly based on documented business need.
• CC6.4: Restricts physical access to facilities, data centers, and secure server rooms to authorized personnel using badge readers, biometric scanners, and CCTV.
• CC6.5: Discontinues logical and physical access rights upon employee termination (disabling accounts, recovering corporate laptops and badges).
• CC6.6: Logical boundary controls to prevent unauthorized connections (e.g., network segmentation, demilitarized zones [DMZs], API gateways).
• CC6.7: Transmission protection (encrypting sensitive data in transit using TLS 1.3; encrypting data at rest using AES-256).
• CC6.8: Prevents or detects unauthorized mobile code, malware, and ransomware through Endpoint Detection and Response (EDR) agents and centralized antivirus.

CC7.0 Series: System Operations (IT-Specific Supplemental Criteria)

Evaluates vulnerability management, security incident handling, and daily operational monitoring:

• CC7.1: Vulnerability management, regular vulnerability scanning, penetration testing, and timely patch management.
• CC7.2: Real-time monitoring of system components and anomaly detection (e.g., Security Information and Event Management [SIEM] log ingestion, automated alerts).
• CC7.3: Security incident detection, triage, and escalation procedures.
• CC7.4: Incident response execution: containment, eradication, recovery, and documented post-incident lessons learned.
• CC7.5: Disaster recovery and business continuity testing (periodic data restoration tests, failover simulations).

CC8.0 Series: Change Management (IT-Specific Supplemental Criteria)

Evaluates software development lifecycle (SDLC) controls and configuration changes:

• CC8.1: The entity authorizes, designs, develops or acquires, configures, tests, approves, and implements changes to infrastructure, data, software, and procedures.
  • Key Audit Focus: Segregation of duties between software developers and the production deployment environment (developers cannot push code directly to production without independent peer review, automated testing, and release manager sign-off).
  • Emergency change procedures: Documented post-implementation approvals for emergency hotfixes.

CC9.0 Series: Risk Mitigation (IT-Specific Supplemental Criteria)

Evaluates vendor management and business partner relationships:

• CC9.1: Identifies, selects, and manages risk arising from vendors, subservice organizations, and third-party business partners (e.g., obtaining vendor SOC 2 reports, conducting annual security questionnaires).
• CC9.2: Evaluates and manages risks associated with business disruptions caused by third parties, ensuring contractual continuity and failover capabilities.

---

4. Supplemental Trust Services Categories: When and Why to Include

While Security (CC1–CC9) is mandatory for every SOC 2, management decides whether to include Availability, Processing Integrity, Confidentiality, or Privacy based on principal service commitments and system requirements communicated to customers.

+----------------------------------------------------------------------------------------------------+
|                                 CRITERIA SCOPING DECISION MATRIX                                   |
+-----------------------+--------------------------------------------------+-------------------------+
| Category              | Primary Business Driver / Customer Commitment    | Key Criteria Focus      |
+-----------------------+--------------------------------------------------+-------------------------+
| Security (Mandatory)  | Core requirement for all technology platforms    | CC1.0 through CC9.0     |
| Availability          | SLA uptime commitments (e.g., 99.9% availability)| A1.1 through A1.3       |
| Processing Integrity  | Financial/transactional processing or data crunch| PI1.1 through PI1.5     |
| Confidentiality       | Protection of proprietary/sensitive business info| C1.1 through C1.2       |
| Privacy               | Direct collection and processing of personal info | P1.0 through P8.0       |
+-----------------------+--------------------------------------------------+-------------------------+

Availability (Criteria A1.1 – A1.3)

• When to Include: When the service organization makes contractual commitments regarding system uptime (e.g., a 99.9% or 99.99% Service Level Agreement [SLA]), disaster recovery timeframes, or business continuity.
• Core Criteria:
  • A1.1: Maintains, monitors, and evaluates current processing capacity and storage to ensure systems meet commitments (capacity planning).
  • A1.2: Implements environmental protections (UPS battery backups, redundant diesel generators, fire suppression, redundant HVAC) and physical recovery safeguards.
  • A1.3: Conducts regular data backups, replicates data to secondary geographic regions, and tests disaster recovery / business continuity plans against established Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO).

Processing Integrity (Criteria PI1.1 – PI1.5)

• When to Include: When the system performs financial transactions, e-commerce payment processing, algorithmic calculations, billing, or complex batch data transformations where errors could corrupt user entity business records.
• Core Criteria:
  • PI1.1: System processing specifications are documented and communicated to authorized users.
  • PI1.2: System inputs are complete, valid, authorized, and accurate (input validation controls, hash checks).
  • PI1.3: System processing is executed completely, accurately, and timely according to specifications (reconciliations, automated balance checks, run-to-run totals).
  • PI1.4: System outputs are complete, accurate, authorized, and distributed only to intended recipients.
  • PI1.5: Data stored and maintained by the system remains complete, accurate, and protected during processing cycles.

Confidentiality (Criteria C1.1 – C1.2)

• When to Include: When the organization handles sensitive corporate data, trade secrets, intellectual property, proprietary source code, legal contracts, price lists, or non-public financial results protected under non-disclosure agreements (NDAs) or confidentiality clauses.
• Core Criteria:
  • C1.1: Identifies and designates confidential information upon receipt or creation (data classification policies).
  • C1.2: Disposes of confidential information in accordance with agreements and regulations (secure shredding, NIST SP 800-88 cryptographic wiping, data retention schedules).

Privacy (Criteria P1.1 – P8.1)

• When to Include: When the service organization collects, processes, or stores Personal Identifiable Information (PII) directly from individuals or customers (e.g., names, Social Security numbers, dates of birth, healthcare records, financial account numbers) and is governed by privacy notices or regulations such as GDPR, CCPA, or HIPAA.
• The eight privacy criteria series in TSP section 100 (2017 Trust Services Criteria):
  1. P1.0 — Notice and Communication of Objectives: The entity provides notice to data subjects about its privacy objectives, including purpose of collection, types collected, methods of collection, and use, retention and disposal.
  2. P2.0 — Choice and Consent: The entity communicates the choices available regarding collection, use, retention, disclosure and disposal, and obtains consent where required.
  3. P3.0 — Collection: Personal information is collected consistent with the entity's privacy objectives and limited to what is necessary.
  4. P4.0 — Use, Retention, and Disposal: The entity limits use of personal information to its stated objectives, retains it only as long as needed, and disposes of it securely.
  5. P5.0 — Access: Data subjects can access their personal information for review and correction, including updates.
  6. P6.0 — Disclosure and Notification: Disclosure to third parties occurs only for the stated objectives and with consent where required; the entity notifies affected data subjects, regulators and others of unauthorized disclosures.
  7. P7.0 — Quality: Personal information is accurate, complete and relevant for the purposes for which it is used.
  8. P8.0 — Monitoring and Enforcement: The entity has a process to receive, address and resolve inquiries, complaints and disputes from data subjects, and periodically monitors privacy compliance, correcting identified deficiencies.

Exam trap — the P-series is not GAPP. Legacy study material maps "Security for Privacy" to P7 and "Quality" to P8. That is the retired 2009 GAPP ordering. In the current Trust Services Criteria, P7.0 is Quality and P8.0 is Monitoring and Enforcement, and security for privacy is handled by the mandatory Common Criteria rather than by a separate P criterion.

[!IMPORTANT] Critical Exam Distinction: Confidentiality vs. Privacy: On the CPA ISC exam, candidates are frequently tested on distinguishing Confidentiality from Privacy:

• Confidentiality protects proprietary business and organizational data (e.g., trade secrets, proprietary algorithms, financial projections, corporate M&A documents, customer contract terms). It applies to B2B corporate information governed by contracts and non-disclosure agreements.
• Privacy applies exclusively to Personal Information (PII) relating to identifiable natural persons (e.g., consumer health records, Social Security numbers, home addresses, biometric profiles). Privacy mandates compliance with the P1.0 through P8.0 criteria — notice, choice and consent, collection, use/retention/disposal, access, disclosure and notification, quality, and monitoring and enforcement. A B2B enterprise SaaS platform managing corporate server logs needs Confidentiality, whereas an HR payroll or consumer healthcare platform managing individual employee records needs Privacy.