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.
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 (CC series) cover the Security category and form the backbone of every SOC 2 engagement. They are grouped into nine logical sub-sections:
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.
The Availability criteria apply when your product's uptime directly affects your customers' operations. The three criteria here require you to demonstrate:
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 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:
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.
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:
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.
The Privacy criteria are the most expansive non-Security category, with eight criteria (P1 through P8) covering the full lifecycle of personal information:
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.
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:
| TSC Area | Example Criteria | Controls You Need |
|---|---|---|
| CC6 (Access) | CC6.1, CC6.2, CC6.3 | MFA, SSO, access reviews, offboarding workflows |
| CC7 (Operations) | CC7.1, CC7.2 | SIEM or log aggregation, vulnerability scanning, EDR |
| CC8 (Change) | CC8.1 | Change advisory process, deployment approvals, rollback procedures |
| CC9 (Vendor) | CC9.2 | Vendor risk assessments, third-party security reviews |
| A1 (Availability) | A1.2, A1.3 | Redundancy configs, tested DR plan, uptime monitoring |
| C1 (Confidentiality) | C1.1 | Encryption at rest/transit, data classification, DLP controls |
| P (Privacy) | P3, P4, P6 | Data inventory, consent management, breach notification procedures |
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.
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.
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.
The right scope depends on your customers, your services, and your existing control maturity. A few practical guidelines:
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.