SOC 215 April 2026 10 min read

SOC 2 Trust Service Criteria: All 5 Categories Explained

A plain-language breakdown of all five SOC 2 Trust Service Criteria — Security, Availability, Confidentiality, Processing Integrity, and Privacy.

Key Takeaways

Security (Common Criteria) is the only mandatory TSC — all other categories are optional and scope-dependent.
The 2017 TSC update reorganized Security into CC1–CC9, adding risk assessment and vendor management criteria that were absent in earlier versions.
Availability (A1) is most relevant for SaaS companies with uptime SLAs; three sub-criteria cover capacity, environmental threats, and recovery.
Privacy (P1–P8) maps closely to GDPR and DPDP Act obligations, making it a logical add-on for companies with regulatory exposure.
Most B2B SaaS companies start with Security only and add Availability as their second criterion when enterprise buyers request it.

In this guide

Security: The Common Criteria (CC1–CC9)
Availability Criteria (A1)
Confidentiality Criteria (C1)
Processing Integrity Criteria (PI1)
Privacy Criteria (P1–P8)
How to Choose Your TSC Scope
Common Scope Mistakes

Security: The Common Criteria (CC1–CC9)

The Security category — formally called the Common Criteria (CC) — is mandatory in every SOC 2 engagement. It contains 33 individual criteria organized into nine control groups: CC1 (Control Environment), CC2 (Communication and Information), CC3 (Risk Assessment), CC4 (Monitoring Activities), CC5 (Control Activities), CC6 (Logical and Physical Access), CC7 (System Operations), CC8 (Change Management), and CC9 (Risk Mitigation).

CC6 and CC8 are where most audit findings occur. CC6 covers how you control who can access systems and data — including provisioning, de-provisioning, MFA enforcement, and privileged access management. CC8 covers your change management process — how code gets reviewed, tested, and deployed to production. Both are areas where fast-moving startups frequently have informal processes that don't meet the written-policy standard required by auditors.

CC3 (Risk Assessment) and CC9 (Risk Mitigation / Vendor Management) are often underestimated by first-time companies. CC3 requires a formal annual risk assessment process with documented risk owners and risk treatment decisions. CC9 requires you to assess and monitor the security of your critical third-party vendors — which for most SaaS companies means AWS, GitHub, Okta, Stripe, and similar tools.

Availability Criteria (A1)

The Availability TSC contains three criteria: A1.1 (capacity management), A1.2 (environmental threats), and A1.3 (recovery). If your product commits to uptime SLAs — even just "99.9% uptime" in your Terms of Service — your customers may require Availability in your SOC 2 scope.

A1.1 requires that you monitor, evaluate, and manage system capacity. Evidence includes auto-scaling configurations, CloudWatch alarms on CPU/memory thresholds, and records of capacity reviews. A1.2 requires that you identify and protect against environmental threats — including cloud region outages, network failures, and power disruptions. Evidence includes multi-AZ or multi-region deployment configurations. A1.3 requires documented and tested recovery procedures. Evidence includes your RTO/RPO commitments, DR runbooks, and records of DR tests conducted during the observation period.

A key mistake is including Availability in scope without actually running a DR test. Auditors will always ask for evidence of at least one DR test during the observation period. A company that has a DR runbook but has never tested it will receive an exception on A1.3.

Confidentiality Criteria (C1)

The Confidentiality TSC has two criteria: C1.1 (identifying and maintaining confidential information) and C1.2 (disposing of confidential information). This category is relevant when your product stores information that customers designate as confidential — such as legal contracts, financial models, health records, or intellectual property.

C1.1 requires that you have controls to identify which data is confidential and ensure it is handled according to its classification. Evidence includes data classification policies, encryption-at-rest configurations for confidential data stores, and access controls that limit confidential data to authorized users. C1.2 requires secure disposal — cryptographic erasure for cloud storage, certificate-of-destruction for physical media, and data deletion workflows when customers off-board.

Confidentiality is sometimes confused with Privacy. The distinction is important: Confidentiality protects data that customers (companies) designate as confidential. Privacy protects personal information belonging to individuals. A B2B platform handling enterprise trade secrets needs Confidentiality. A consumer app or a B2B product that processes employee data needs Privacy.

Processing Integrity Criteria (PI1)

Processing Integrity has five criteria (PI1.1–PI1.5) covering whether system processing is complete, valid, accurate, timely, and authorized. This category is primarily relevant for payment processors, ETL pipelines, financial reporting systems, and any platform where incorrect data processing has direct business consequences.

PI1.1 requires that you define processing objectives and specifications. PI1.2 requires that inputs are complete and accurate before processing. PI1.3 requires that system processing produces complete, accurate results. PI1.4 requires that outputs are complete and delivered to authorized parties. PI1.5 requires that stored data is complete and accurate and available for retrieval.

Evidence for Processing Integrity typically includes: reconciliation reports showing input/output counts match, error logging and alerting configurations, data validation logic in code (reviewed via pull requests), and records of any processing errors and how they were resolved. Most pure SaaS application companies do not include Processing Integrity in scope unless they have payment processing or data transformation as a core product function.

Privacy Criteria (P1–P8)

The Privacy TSC has eight criteria covering the full lifecycle of personal information: P1 (notice and communication of privacy policies), P2 (choice and consent), P3 (collection), P4 (use, retention, and disposal), P5 (access), P6 (disclosure and notification), P7 (quality), and P8 (monitoring and enforcement).

Privacy maps closely to GDPR Article requirements and India's DPDP Act obligations. P1 requires a published privacy notice. P2 requires obtaining consent or having a lawful basis for processing. P3 limits collection to what is necessary. P4 requires retention policies and data disposal procedures. P5 requires mechanisms for individuals to access and correct their data. P6 requires breach notification procedures. P7 requires data accuracy controls. P8 requires privacy program oversight and complaint handling.

Adding Privacy to your SOC 2 scope does not automatically mean you are GDPR or DPDP compliant — the criteria overlap significantly but are not identical. However, if you are pursuing both SOC 2 and regulatory compliance, aligning your Privacy program to the SOC 2 TSC creates a common evidence base that serves both.

How to Choose Your TSC Scope

Start with what your biggest prospects are asking for. Review your last 10 security questionnaire responses and identify which TSC categories came up. If multiple enterprise prospects asked about uptime and DR, add Availability. If healthcare or legal tech customers asked about confidential data handling, add Confidentiality.

Consider your product commitments. If your SLA promises 99.9% uptime, you should have Availability controls regardless of whether customers ask — a failure to meet your SLA with no documented capacity management or recovery testing is both an audit risk and a legal risk.

Start narrow, expand later. Adding a TSC to an existing engagement costs roughly $3,000–$8,000 in additional auditor fees. It is far easier to add a category in year two, when your team is comfortable with the audit process, than to overscope year one and struggle to implement all the controls before your observation period ends.

Common Scope Mistakes

The most common TSC scope mistake is including Availability without running a DR test. Auditors always sample A1.3 and always ask for a DR test record. If you haven't run one during the observation period, you'll get an exception.

A related mistake is adding Privacy because it "sounds good" without implementing the underlying consent management, data subject request workflows, and retention automation. Privacy has eight criteria — each requiring real operational evidence. Companies that add Privacy to scope without preparing the controls typically receive multiple exceptions.

Finally, some companies add Processing Integrity because their product processes payments — then discover that PI1 requires extensive evidence about data validation and reconciliation that their engineering team hasn't built. If your payment processing is entirely delegated to Stripe with no custom logic, you likely don't need Processing Integrity in scope — Stripe's SOC 2 report covers their processing controls.

Frequently Asked Questions

Is it possible to have SOC 2 Security only?

Yes — and it is the most common scope for B2B SaaS companies. Security (Common Criteria) is the only mandatory category. Many companies maintain Security-only SOC 2 reports throughout their entire compliance journey because their customers don't specifically require the other categories. If a customer does require Availability or Confidentiality, you can add those categories in a subsequent audit cycle.

Do the Trust Service Criteria change over time?

The AICPA updates the TSC periodically. The current version is the 2017 TSC, which replaced the earlier 2016 version. The 2017 update significantly restructured the Common Criteria, adding risk assessment (CC3) and vendor management (CC9) as explicit categories. The AICPA has indicated intent to update the criteria again, though no finalized revision had been published as of early 2026. Your auditor will always audit against the current version.

What is the difference between SOC 2 Privacy and GDPR?

SOC 2 Privacy (P1–P8) and GDPR both protect personal information, but they are not equivalent. GDPR is law with regulatory enforcement and financial penalties. SOC 2 Privacy is an audit criterion evaluated by a CPA. The concepts overlap (consent, access rights, breach notification, retention) but the detailed requirements differ. Having SOC 2 Privacy in scope provides evidence of a mature privacy program but does not constitute GDPR compliance on its own.

Can I add Trust Service Criteria mid-audit?

You can discuss expanding scope with your auditor before the observation period ends, but it is generally inadvisable. Adding a new TSC mid-observation-period means the auditor needs to test those criteria for the remaining portion only, resulting in a shorter testing window and potentially a qualified opinion if controls are immature. It is better to add new categories at the start of a new observation period.

How many controls are in a typical SOC 2 Security audit?

The 2017 Common Criteria contains 33 criteria across CC1–CC9. Each criterion typically requires 2–5 controls to address it, resulting in roughly 80–150 individual controls for a Security-only engagement. The exact number depends on your system complexity and how granularly you define controls. Compliance platforms like AuditPath map each criterion to specific control tests, giving you a precise count for your environment.