Trust Services Criteria (SOC 2)

Name: Trust Services Criteria (TSC)

Type: Framework

Authoritative Source: AICPA

Certification Available: Yes. ISO has a conformity program that it maintains, where a certified auditor may issue an ISO 27001 certification.

Too Long / Didn’t Read (TL/DR): The Trust Services Criteria (TSC), developed by the American Institute of Certified Public Accountants (AICPA) is one of the most widely recognized frameworks for evaluating this assurance, especially for technology and service-oriented companies. 

The TSC underpins System and Organization Controls (SOC) 2 and SOC 3 reporting. It is not a regulation or security standard in the technical sense, but rather a control framework designed to help organizations evaluate and report on the design and operating effectiveness of controls over data security, confidentiality, privacy, availability and processing integrity.

GRC-Focused Overview of The Trust Services Criteria (TSC)

The Trust Services Criteria (TSC) framework is a foundational model for cybersecurity assurance in service-oriented and cloud-centric industries. It combines principles from enterprise risk management, operational security and control auditing to provide a structured path toward verifiable trust.

Unlike prescriptive technical standards such as PCI DSS or NIST SP 800-53, the TSC offers a principles-based framework that organizations can adapt based on size, complexity and sector. When implemented correctly, it provides a powerful mechanism to:

  • Align cybersecurity controls with customer and regulatory expectations
  • Enhance operational transparency and contract performance
  • Demonstrate due care in managing security, availability and privacy risks
  • Integrate cybersecurity into broader governance and risk functions

Critically, the strength of cybersecurity documentation often determines the success of TSC alignment and SOC 2 attestation. High-quality documentation transforms abstract policies into evidence-based controls and allows independent auditors to confidently form their opinions.

In a digital economy where data is currency and trust is capital, the Trust Services Criteria offer a proven, flexible and scalable framework for demonstrating cybersecurity excellence.

This page provides a cybersecurity-focused summary of the Trust Services Criteria (TSC) from a GRC practitioner's perspective, including:

  • The history of these frameworks;
  • Practical compliance strategies; and
  • The role of high-quality documentation to be secure, compliant and resilient.

Trust Services Criteria (TSC) - Origins and Purpose

The TSC traces its origins to the AICPA’s efforts to standardize assurance reporting on systems and controls in organizations that provide services to other entities. Prior to the introduction of SOC reports, Statement on Auditing Standards (SAS) 70 was often misapplied to IT environments, though it was originally designed for financial reporting audits.

Recognizing the need for a more IT- and cybersecurity-aligned assurance framework, the AICPA introduced Service Organization Control (SOC) reports in 2011, under the Statement on Standards for Attestation Engagements (SSAE) framework. These included:

  • SOC 1 - Controls relevant to financial reporting (based on SSAE 18);
  • SOC 2 - Controls relevant to the Trust Services Criteria (based on TSC); and
  • SOC 3 - General-use reports covering the same criteria as SOC 2, but without the confidential detail.

The TSC themselves were originally referred to as Trust Services Principles and Criteria. Over time, they were refined to align more closely with COSO’s Internal Control–Integrated Framework, as well as evolving industry expectations around risk management, privacy and cybersecurity. In 2017, the AICPA issued a major update that structured the criteria around five trust service categories, each supported by common and supplementary criteria.

The most recent version of the Trust Services Criteria (updated periodically by the AICPA) continues to reflect cross-domain requirements and incorporates references to leading standards such as ISO 27001, NIST CSF, COBIT and the GDPR.

The Five Trust Services Categories

The Trust Services Criteria are organized into five (5) distinct categories, with Security serving as the foundation. Depending on the nature of services provided and the needs of customers, a SOC 2 examination may focus on just one or multiple of these categories:

1. Security (Common Criteria – Required for all SOC 2 Reports)

This is the core pillar and includes controls related to:

  • Logical and physical access controls;
  • System and operations security;
  • Risk assessment;
  • Incident detection and response; and
  • Governance and oversight.

2. Availability

Focuses on whether the system is available for operation and use as committed or agreed. Includes:

  • Capacity planning;
  • Performance monitoring; and
  • Disaster recovery and backup processes.

3. Processing Integrity

Relevant for systems that must ensure accurate, timely and authorized processing of data. Covers:

  • Input validation;
  • Processing accuracy; and
  • Output completeness.

4. Confidentiality

Applies where organizations must protect confidential information shared by customers or partners. Controls include:

  • Data classification and retention;
  • Encryption and secure data disposal; and
  • Confidentiality agreements.

5. Privacy

Based on the AICPA’s Generally Accepted Privacy Principles (GAPP) and aligned to global privacy standards (e.g., GDPR, CCPA). Includes:

  • Notice and consent mechanisms;
  • Personal data access, correction and deletion; and
  • Privacy governance and accountability.

Industries and Use Cases for Trust Services Criteria

The TSC and SOC 2 reporting are particularly relevant for service organizations—entities that process, store, or manage customer data or operations. The framework is especially useful in sectors where organizations don’t fall under strict statutory cybersecurity requirements but still need to prove due care and control integrity.

  • Technology and SaaS Providers. Most cloud and software-as-a-service companies undergo SOC 2 examinations as a core part of their customer assurance and go-to-market strategy. Customers increasingly require SOC 2 reports as part of their vendor risk management programs.
  • Financial Technology (Fintech) and Payment Platforms. While not replacing PCI DSS or GLBA compliance, TSC-based SOC 2 audits give fintech firms a way to demonstrate the strength of their security and availability controls to institutional partners, investors and banking regulators.
  • Healthcare SaaS and Business Associates. Health technology vendors and processors of protected health information (PHI) leverage the Trust Services Criteria to address security and availability expectations in parallel with HIPAA.
  • Managed Services and Data Processors. Managed IT service providers, co-location facilities and third-party data processors use SOC 2 reports to contractually demonstrate cybersecurity and operational reliability to enterprise customers.
  • E-Commerce and Digital Platforms. Digital businesses rely on SOC 2 and the underlying Trust Services Criteria to strengthen customer trust, especially in handling confidential or personal data across global markets.

Common Methods to Achieve and Maintain Conformity With The Trust Services Criteria (TSC)

Achieving conformance with the TSC and producing a clean SOC 2 report is a multi-phase process that involves building a system of controls, collecting evidence of effectiveness and undergoing third-party assessment.

  • Define the Audit Scope and System Boundaries. Before beginning a SOC 2 engagement, organizations must:
    • Identify the system under examination, including infrastructure, software, people, processes and data
    • Determine which Trust Services Categories apply based on customer needs and risk exposure
    • Engage a licensed CPA firm that performs SOC 2 audits in accordance with AICPA attestation standards
  • Perform a Gap Assessment. Organizations typically conduct an internal readiness assessment or work with an external consultant to evaluate:
    • Control coverage across applicable TSC criteria
    • Documentation and evidence quality
    • Operational maturity and gaps
    • Need for remediation or new control development
  • Build or Strengthen the Control Environment. Based on the gap analysis, organizations:
    • Implement technical security measures (e.g., access control, logging, alerting, encryption)
    • Establish governance artifacts (e.g., risk assessments, policies, procedures)
    • Deploy security awareness training and operational processes (e.g., vulnerability management)
  • Conduct a Type I or Type II Audit. There are two types of SOC 2 reports:
    • Type I: Assesses the design of controls at a specific point in time
    • Type II: Assesses both the design and operating effectiveness of controls over a period (typically 6–12 months). Type II reports carry more weight in enterprise and regulated environments.
  • Maintain Controls and Monitor Continuously. Mature organizations treat the SOC 2/TSC cycle as part of their cybersecurity lifecycle, integrating findings into broader governance and risk management functions. SOC 2 and TSC alignment are not one-time efforts. Organizations must:
    • Track changes in risk exposure and update controls
    • Conduct periodic reviews, training and incident simulations
    • Prepare annually for re-audits and customer/vendor scrutiny

Structure of the Trust Services Criteria

The TSC is rooted in the COSO, a globally accepted model for enterprise risk management. Each criterion follows COSO’s five components of internal control:

  1. Control Environment
  2. Risk Assessment
  3. Control Activities
  4. Information and Communication
  5. Monitoring Activities

Under each component, the TSC defines “common criteria” that apply to all five Trust Services Categories and “supplemental criteria” that are specific to Availability, Confidentiality, Privacy and Processing Integrity.

Each criterion is supported by Points of Focus, which serve as implementation considerations—analogous to control objectives or safeguards in other frameworks. For example, Common Criteria 6.1 (Logical Access Controls) maps to sub-controls such as:

  • Unique user identification;
  • Role-based access provisioning;
  • Multi-factor authentication; and
  • Periodic access reviews.

The flexibility of this structure allows organizations to tailor their control implementations to their unique operational model, size and risk profile.

Understanding The Value of Quality Cybersecurity Documentation To Conform With The Trust Services Criteria (TSC)

Documented evidence is the foundation of a successful SOC 2 examination and thus compliance with the Trust Services Criteria. Unlike checkbox assessments, SOC 2 reports are attestation engagements, meaning that auditors form an opinion based on documented control design, operation and effectiveness.

  • Governance and Policy Evidence. Auditors review these artifacts for completeness, version control and alignment to actual operations. Well-crafted policies and procedures directly support Common Criteria such as:
    • CC1.2 – The entity demonstrates commitment to integrity and ethical values (e.g., Code of Conduct)
    • CC2.1 – The entity specifies suitable objectives (e.g., ISMS governance structure, cybersecurity policy)
    • CC3.2 – The entity identifies and assesses risks (e.g., formal risk assessments and treatment plans)
  • Control Design and Implementation Records. Evidence must show controls are consistently applied, not just theoretically defined. Operational procedures, playbooks and technical standards demonstrate how controls are implemented. Examples include:
    • Access management SOPs
    • Change management workflows
    • Incident response plans and simulations
    • Asset and vulnerability management guidelines
  • System Descriptions and Diagrams. Accurate and detailed network diagrams, data flow maps and architectural documentation reduce audit friction and clarify scope. The “system description” section of the SOC 2 report must clearly articulate:
    • The scope and boundaries of the system under review
    • Types of data handled
    • Infrastructure and technologies used
    • Third-party dependencies and supply chain controls
  • Logs, Reports and Monitoring Evidence. Audit logs, alert tickets, system reports and event response records are critical for evaluating the operating effectiveness of controls. Without this documentation, auditors cannot attest to whether controls were applied over time.
  • Continuous Improvement and Corrective Actions. Documentation of findings, root cause analysis and control updates demonstrates a mature security program and supports Monitoring Activities under COSO. These records are often reviewed to assess how the organization responds to incidents and control failures.

** SPONSORED CONTENT **

ComplianceForge GRC importable policies standards procedures