Trust Services Criteria Explained

If your organization is pursuing a SOC 2 audit, the Trust Services Criteria (TSC) are the control framework your auditor will use to evaluate you. Developed by the American Institute of Certified Public Accountants (AICPA), the TSC define what "trust" means for a service organization and translate it into auditable requirements across five categories.

This article breaks down each category, how they map to real controls, and what IT teams actually need to implement to satisfy them.

What Are the Trust Services Criteria?

The Trust Services Criteria are a set of principles and supporting criteria that define what a service organization must demonstrate to earn a SOC 2 report. They replaced the older Trust Services Principles in 2017 and were updated again in 2022 to align with COSO's Internal Control framework.

The TSC are organized into five categories:

1. Security (required for all SOC 2 audits)

2. Availability

3. Processing Integrity

4. Confidentiality

5. Privacy

Security is the only mandatory category. Your organization chooses which of the remaining four to include based on what your customers care about and what your services actually do. A cloud storage provider might add Availability and Confidentiality. A healthcare SaaS platform might add Privacy.

Each category contains a set of criteria labeled with a code (CC for Common Criteria, A for Availability, PI for Processing Integrity, C for Confidentiality, P for Privacy). Within each criterion, there are "points of focus" that auditors use as evidence checkpoints.

The Common Criteria: Security as the Foundation

The Common Criteria (CC series) cover the Security category and form the backbone of every SOC 2 engagement. They are grouped into nine logical sub-sections:

• CC1: Control Environment, Does leadership set the right tone? Are organizational structures, reporting lines, and accountability mechanisms in place?
• CC2: Communication and Information, Is relevant information captured, processed, and communicated internally and externally?
• CC3: Risk Assessment, Does the organization identify, analyze, and respond to risk systematically?
• CC4: Monitoring Activities, Are controls being evaluated over time for effectiveness?
• CC5: Control Activities, Are policies and procedures actually deployed to mitigate risks?
• CC6: Logical and Physical Access Controls, Who can access systems and data, and how is that access managed?
• CC7: System Operations, Is the environment monitored for anomalies and threats?
• CC8: Change Management, Are changes to systems controlled and reviewed?
• CC9: Risk Mitigation, Are vendor and business partner risks assessed and managed?

For most IT teams, CC6 and CC7 generate the most audit evidence requests. CC6 covers things like MFA enforcement, access provisioning and deprovisioning, and least-privilege policies. CC7 covers log monitoring, incident response, and vulnerability management.

For more on how device controls feed into CC6 and CC7, see device management and security.

Availability Criteria (A Series)

The Availability criteria apply when your product's uptime directly affects your customers' operations. The three criteria here require you to demonstrate:

• A1.1: Performance objectives and capacity management are defined
• A1.2: Environmental protections and redundancy controls are in place
• A1.3: Recovery plans are developed, tested, and documented

In practice, this means you need documented SLAs, DR/BCP plans with tested RPO and RTO targets, and infrastructure monitoring that shows you can detect and respond to availability issues. Cloud-native organizations typically satisfy these through provider SLAs plus their own alerting configurations, but auditors will want to see the evidence chain, not just a screenshot of AWS's uptime page.

Processing Integrity Criteria (PI Series)

Processing Integrity applies when your service processes transactions on behalf of customers, such as payment processors, data transformation pipelines, or order management systems. The criteria require you to show that:

• PI1.1: System processing is complete, valid, accurate, timely, and authorized
• PI1.2: System inputs are controlled for completeness and accuracy
• PI1.3: Outputs are accurate and distributed appropriately

This is the least commonly selected category. It is most relevant for fintechs, logistics platforms, and any organization where a processing error could result in a financial or contractual impact on customers.

Confidentiality Criteria (C Series)

The Confidentiality criteria address how you protect information that is explicitly designated as confidential, such as contracts, business plans, or data subject to NDA. There are two criteria:

• C1.1: Confidential information is identified and protected during its lifecycle
• C1.2: Confidential information is disposed of appropriately

Note that "confidentiality" under the TSC is narrower than most people assume. It covers information designated as confidential by agreement or policy, not all sensitive data. Personal information is handled under the Privacy category instead.

Common controls include encryption at rest and in transit, data classification policies, and documented retention and disposal procedures. If your endpoints store confidential data locally, full-disk encryption (FileVault on macOS, BitLocker on Windows) is a standard point of focus auditors will check.

Privacy Criteria (P Series)

The Privacy criteria are the most expansive non-Security category, with eight criteria (P1 through P8) covering the full lifecycle of personal information:

• P1: Privacy notice and communication
• P2: Choice and consent
• P3: Collection of personal information
• P4: Use, retention, and disposal
• P5: Access by data subjects
• P6: Disclosure and notification
• P7: Quality and accuracy
• P8: Monitoring and enforcement

The AICPA aligned the Privacy criteria with established frameworks including the GAPP (Generally Accepted Privacy Principles). Organizations subject to GDPR or CCPA will find significant overlap, which makes Privacy a practical addition for those already managing regulatory obligations. That said, SOC 2 Privacy and GDPR compliance are not interchangeable. A SOC 2 with Privacy scope will not satisfy a GDPR audit requirement on its own.

For organizations navigating multiple frameworks simultaneously, compliance automation tools can reduce the duplication of collecting and mapping evidence across overlapping controls.

How the TSC Map to Real Controls

The gap between "we have a policy" and "we can prove it to an auditor" is where most SOC 2 preparations stall. Here is how the criteria translate to specific technical controls IT teams need to own:

For CC7 specifically, auditors want to see that you are actively monitoring for and responding to threats, not just that you have a tool installed. An endpoint hardening guide can help establish a consistent baseline across your fleet that feeds directly into this criterion.

Common Mistakes in TSC Implementation

Based on how organizations typically stumble during SOC 2 readiness, these are the most frequent issues:

1. Treating policies as controls. A written access control policy does not satisfy CC6. You need evidence of the control operating, such as access review logs, provisioning tickets, or automated enforcement.

2. Scope creep without criteria coverage. Adding systems to your audit scope without ensuring those systems have matching controls creates evidence gaps.

3. Ignoring the points of focus. Each criterion has multiple points of focus. Auditors will probe several of them. Satisfying the headline criterion without reading the points of focus leads to findings.

4. Failing to demonstrate monitoring in CC4. Organizations implement controls but do not document their internal reviews. If you cannot show the control was evaluated, auditors cannot give credit for it.

5. Selecting Privacy scope without infrastructure to support it. P5 requires you to give data subjects access to their personal information. If you do not have a process for responding to those requests, do not include Privacy in scope until you do.

How Iru Approaches Trust Services Criteria

A significant portion of TSC evidence comes from endpoint and device controls, specifically around CC6, CC7, and confidentiality requirements. Iru Compliance maps directly to these criteria, connecting your device configuration state to the controls auditors will test.

Through Iru Endpoint, IT teams can enforce configuration baselines (FileVault encryption, screen lock, OS version requirements) and surface that compliance posture in real time. When an auditor asks for evidence that all endpoints had disk encryption enabled during the audit period, Iru generates that history without requiring someone to manually pull screenshots.

Iru Compliance goes further by mapping controls to specific SOC 2 Trust Services Criteria, tracking evidence automatically, and flagging gaps before your auditor does. If a device falls out of compliance with a configuration that maps to CC6.7, that drift is visible immediately rather than discovered during fieldwork.

For organizations pursuing their first SOC 2 or expanding into additional TSC categories, this kind of continuous control monitoring matters more than point-in-time checks. Auditors are increasingly evaluating whether controls operated consistently across the period, not just whether they were in place the week before the audit.

You can read more about how the SOC 2 process works end to end in the SOC 2 compliance guide.

Choosing the Right TSC Scope for Your Organization

The right scope depends on your customers, your services, and your existing control maturity. A few practical guidelines:

• Start with Security only if this is your first SOC 2. The Common Criteria are substantial enough on their own.
• Add Availability if your customers have uptime SLAs with you or if your product is infrastructure-adjacent.
• Add Confidentiality if you handle customer data under NDA or process sensitive business information.
• Add Privacy only if you are ready to support all eight criteria, including data subject access requests and breach notification workflows.
• Add Processing Integrity if transaction accuracy is central to your service delivery.

Expanding scope in future audits is normal. Starting with the right scope for your current maturity level gives you a cleaner first report and a manageable remediation path.

For IT teams preparing evidence, what is IT compliance is a useful primer on how technical controls connect to auditable requirements across frameworks.