The 5 Trust Services Criteria Explained (Without the Jargon)

The Framework Underneath the Framework

SOC 2 doesn't have a single checklist. It has five categories of criteria called Trust Services Criteria (TSCs), and the controls that apply to you depend on which TSCs are in scope for your audit.

This is one of the most misunderstood aspects of SOC 2 for beginners. Let's break each one down clearly.

1. Security (CC) — The Required One

Official name: Common Criteria (CC) — sometimes called "Security"

The plain-English version: Security covers whether your systems and data are protected from unauthorized access, both from the outside world and from within your organisation.

This one is mandatory. Every SOC 2 audit includes Security. You cannot have a SOC 2 report without it.

The Security criteria are organised into nine categories:

• CC1: Control Environment (leadership, accountability, governance)
• CC2: Communication & Information (how policies are communicated)
• CC3: Risk Assessment (how you identify and evaluate risks)
• CC4: Monitoring (how you track whether controls are working)
• CC5: Control Activities (the actual operational controls)
• CC6: Logical & Physical Access (who can access what, and how) — the most heavily tested
• CC7: System Operations (vulnerability management, incident response)
• CC8: Change Management (how code and infrastructure changes are controlled)
• CC9: Risk Mitigation (vendor management, business continuity)

Most of your audit effort will be focused here, especially on ●CC6.2, ●CC6.3, ●CC7.1, and ●CC8.1.

2. Availability (A) — The Second Most Common

The plain-English version: Availability covers whether your system is accessible and operational as promised to your customers.

This TSC is relevant if:

• You have uptime SLAs in customer contracts
• You provide a service where downtime has meaningful business impact
• Customers explicitly ask about your disaster recovery capabilities

What auditors test for Availability:

• Do you monitor system performance and alert on degradation?
• Do you have a tested disaster recovery plan?
• Can you demonstrate that your infrastructure meets your SLA commitments?

Key controls: ●A1.1, ●A1.2, ●A1.3

Orion's decision: They included Availability because their product is a real-time analytics platform. Downtime means customers can't access their data — a direct SLA breach. For Orion, Availability was non-negotiable.

3. Confidentiality (C) — For When Data Sensitivity Matters

The plain-English version: Confidentiality covers whether information that is designated as confidential is actually protected from unauthorized disclosure.

This is distinct from privacy (which covers personal data). Confidentiality applies to business-sensitive information — trade secrets, financial data, proprietary data that customers have entrusted to you.

This TSC is relevant if:

• Customers store business-sensitive data in your system
• Your contracts include confidentiality obligations
• You handle financial or commercial data

What auditors test:

• How do you identify and classify confidential information?
• How do you restrict access to confidential data?
• What happens to confidential data when a customer relationship ends?

4. Processing Integrity (PI) — For Transaction-Critical Systems

The plain-English version: Processing Integrity covers whether your system processes data completely, accurately, timely, and validly.

This TSC is specifically relevant for companies where incorrect data processing has direct financial or legal consequences: payment processors, accounting software, healthcare billing platforms, and similar.

If you're a general SaaS company that stores and retrieves data but doesn't process financial transactions, this TSC is usually not in scope.

What auditors test:

• Do you have controls to detect and correct processing errors?
• Is there a reconciliation process for critical transactions?
• How do you handle partial failures?

5. Privacy (P) — For Personal Data Processing

The plain-English version: Privacy covers whether personal information is collected, used, retained, and disclosed in accordance with commitments made to data subjects (individuals).

The Privacy TSC is aligned with AICPA's privacy framework and incorporates Generally Accepted Privacy Principles (GAPP). It has significant overlap with GDPR and India's DPDP Act.

This TSC is relevant if:

• You collect personal information from end users
• Your product processes personally identifiable information (PII)
• Customers ask you specifically about privacy controls and data subject rights

Note: Privacy adds significant complexity to the audit. Many companies defer it until they have established their core Security + Availability report.

Which TSCs Should You Choose?

Here's my practical guidance based on company type:

| Company Type | Recommended TSCs | |---|---| | B2B SaaS (general) | Security + Availability | | Payments / Fintech | Security + Availability + Processing Integrity | | Healthcare / Health data | Security + Availability + Privacy | | Enterprise data management | Security + Availability + Confidentiality | | Consumer apps with PII | Security + Privacy | | High-security / Government | All five |

Start with Security. Add Availability if you have uptime SLAs. Add others based on your customers' specific requirements and what's in your contracts.

What Comes Next

Now that you know what the framework covers, the next critical step is defining which parts of your company are actually in scope. Scope definition is arguably the most important strategic decision in your entire SOC 2 journey — and it's where most companies make their first big mistake.