SOC 2 Trust Services Criteria (2026): All 5 TSCs Explained

The SOC 2 Trust Services Criteria are the five categories an auditor measures your controls against. The AICPA defines them in TSP Section 100, the 2017 Trust Services Criteria with revised points of focus issued in 2022 — the current standard as of 2026. The 2022 revision updated the guidance, not the criteria themselves, so the five categories below have been stable since 2017.

The five criteria are Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is the only one required in every audit. You add the other four based on what you commit to customers and what your buyers ask for.

What Are the SOC 2 Trust Services Criteria and How Do You Choose Them?

The American Institute of CPAs (AICPA) publishes the Trust Services Criteria (TSCs) so auditors evaluate every service organization against one consistent standard. Two questions decide which optional criteria you scope in:

• Contractual commitments: What have you promised customers in your service agreements and SLAs?
• Buyer requirements: Which criteria do your target customers’ procurement teams ask for before they sign?

Security is the baseline. The other four extend the report to cover specific commitments you make about uptime, data handling, transaction accuracy, and personal data.

The Five SOC 2 Trust Services Criteria at a Glance

Trust Service Criterion	What It Covers	When to Scope It In
Security (CC1–CC9)	Protects systems and data from unauthorized access, use, or modification.	Always. Required in every SOC 2 report.
Availability (A1.1–A1.3)	Confirms the system is available for operation and use as committed.	When you sell uptime SLAs and customers want proof of recovery testing (RTO/RPO).
Processing Integrity (PI1.1–PI1.5)	Confirms processing is complete, valid, accurate, timely, and authorized.	When you process payments, trades, or other critical, high-volume transactions.
Confidentiality (C1.1–C1.2)	Protects information designated confidential, including its secure disposal.	When customers require proof you protect and securely delete sensitive business data.
Privacy (P1–P8)	Protects personal information across its full lifecycle.	When you collect, use, or store personal information (PII), including AI/ML training data.

Each criterion maps to a specific commitment. Your audit scope should match what you actually promise customers.

Which Criteria Auditors See Scoped Most

Across the firms in the SOC2Auditors directory, the most common scope by a wide margin is Security only (a Security-only Type 2), especially for the first audit. Auditors report that most startups start there because Security is mandatory, the controls are reusable, and it satisfies the majority of mid-market procurement checklists.

The next most common additions auditors see are Availability (for any product sold on an uptime SLA) and Confidentiality (when an NDA or contract obligates secure handling and deletion). Privacy is scoped less often than founders expect — many SaaS companies satisfy customer privacy requirements through the Security and Confidentiality controls plus a separate privacy program, and only add the Privacy TSC when a specific enterprise buyer demands it. Processing Integrity is the rarest, mostly limited to fintech, payments, and data-processing platforms.

For the underlying control sets behind each criterion, see the full SOC 2 controls list and the SOC 2 security controls breakdown.

Deciding What to Add

Security is given. Each additional criterion adds auditor hours, evidence requirements, and cost. Add a criterion when a meaningful share of your target customers require it — survey your top prospects rather than guessing. A FinTech platform that processes payments needs Processing Integrity. A SaaS product selling a hard uptime SLA needs Availability. Adding a criterion no customer asks for raises your audit cost without closing any deals.

For how scope drives the final number, see the SOC 2 audit cost for startups.

What Does the Mandatory Security Criterion Require?

Every SOC 2 report includes Security. It is called the Common Criteria (CC) because its nine criteria (CC1–CC9) underpin all the other Trust Services Criteria. The first five (CC1–CC5) map to the COSO internal control framework; CC6 through CC9 cover access, operations, change management, and risk mitigation.

The Security criterion protects your systems and data from unauthorized access, disclosure, and damage. It is the largest TSC by control count, which is why most first-time audits cover Security alone.

CC6: Logical and Physical Access

Of the nine Common Criteria, CC6 (logical and physical access) is where auditors in our network report the most exceptions. The recurring causes are familiar: missing MFA, terminated employees who still have access, and shared or generic credentials.

The controls auditors test against CC6 most often:

• MFA on every account. Multi-factor authentication on every service, endpoint, and admin account, typically enforced through an identity provider such as Okta or Google Workspace.
• Access reviews. Documented, periodic reviews (usually quarterly) confirming each person’s access still matches their role.
• Timely deprovisioning. A documented process that revokes access promptly when someone leaves, ideally automated through SCIM so accounts are disabled the same day.

Auditor note: CC6 exceptions are also the easiest to clear before fieldwork. Pull an access export, reconcile it against your current headcount, and remove every stale account before the observation period starts.

Build Once, Map Across TSCs

The Common Criteria apply to every TSC you scope, so the work you do for Security is reusable. A risk register, quarterly monitoring in a platform like Vanta, and documented communication policies satisfy CC requirements that also support Availability, Confidentiality, Processing Integrity, and Privacy.

That reuse is why adding a second criterion usually costs less than the first audit: most of the evidence already exists. Getting Security right first keeps later scope expansion cheaper.

When Should You Add the Availability Criterion to Your SOC 2 Audit?

The Availability criterion (A1.1–A1.3) confirms that your system is available for operation and use as you committed. If you sell customers an uptime SLA, this is the criterion that backs the promise with audited evidence.

What Auditors Test

Criterion A1.3 requires you to test your recovery procedures, so a disaster recovery plan that has never been exercised will draw an exception. Auditors in our network consistently flag untested DR plans as the most common Availability gap. They want evidence from actual tabletop and failover drills, not a document.

The controls that satisfy Availability:

• Capacity monitoring (A1.1): Evidence that you monitor system performance and capacity to meet your availability commitments.
• Environmental and backup protections (A1.2): Backups, failover, and recovery infrastructure that support continued operation.
• Recovery testing (A1.3): Documented results from tabletop and live failover drills, typically run at least annually.

RTO and RPO

Two metrics define your Availability commitments:

• Recovery Time Objective (RTO): How quickly you restore service after a disruption. An RTO of 4 hours means you commit to being back online within 4 hours.
• Recovery Point Objective (RPO): How much data you can lose. An RPO of 15 minutes means a recovery loses at most the last 15 minutes of data.

Auditor note: Stated RTO and RPO targets are not enough on their own. Auditors want evidence from a recovery test that shows you hit them. Store immutable backups in a separate region and include test results in the Section 4 appendices of your SOC 2 report.

For a deeper look at how auditors evaluate this criterion, see Schellman’s guidance on the Trust Services Criteria.

For a SaaS company on the hook for service credits when an SLA is missed, that documented proof is worth scoping in.

What Is the Difference Between the Confidentiality and Privacy Trust Services Criteria?

Confidentiality and Privacy are often confused because both protect sensitive data, but they cover different things. Confidentiality protects information your business has designated confidential. Privacy protects personal information about individuals.

Confidentiality: C1.1 and C1.2

The Confidentiality criterion has two parts. C1.1 requires you to identify and maintain the information you have designated confidential. C1.2 requires you to dispose of that information securely when it is no longer needed. C1.2 is where auditors in our network see the most gaps — companies can show they encrypt data but cannot prove they delete it.

Controls that satisfy C1.2:

• Immutable storage locks. Tools like Amazon S3 Object Lock prevent data from being altered or deleted before its retention period ends.
• Automated lifecycle policies. Rules that delete data after a defined period — for example, 30 days after a contract ends — with audit logs recording each deletion.
• Deletion attestations. An on-demand record or certificate confirming a customer’s data has been disposed of, which enterprise customers increasingly request in contracts.

Privacy: P1–P8

The Privacy criterion has eight criteria (P1–P8) covering the full lifecycle of personal information: notice (P1), choice and consent (P2), collection (P3), use, retention, and disposal (P4), access (P5), disclosure (P6), quality (P7), and monitoring and enforcement (P8). It applies only when you handle personal information.

Privacy law has tightened the case for scoping this criterion. As of 2026, 20 US states have comprehensive consumer privacy laws in effect, with Indiana, Kentucky, and Rhode Island taking effect January 1, 2026. Under the EU AI Act, obligations for high-risk (Annex III) AI systems were originally set to apply August 2, 2026, though the Digital Omnibus on AI (politically agreed in May 2026) proposes pushing that deadline to December 2, 2027; the original date stays legally binding until the amendment is published in the Official Journal, so plan against August 2, 2026 until then. If your product builds on a third-party model and you place it on the EU market, you may carry provider obligations including technical documentation and conformity assessment.

If you handle personal data, especially for AI or ML training, scope your Privacy work to the eight criteria above and document which state laws apply to each data flow. Many companies still meet customer privacy needs through Security and Confidentiality controls plus a standalone privacy program, and only add the Privacy TSC when a specific buyer requires it — see the section below before assuming you need it.

Confidentiality vs Privacy

Aspect	Confidentiality (C1.1–C1.2)	Privacy (P1–P8)
Protects	Information your business designates confidential.	Personal information about individuals.
Examples	Trade secrets, contract terms, M&A details, internal financials.	Names, emails, addresses, health data, AI/ML training data.
Primary driver	Contracts and NDAs; protecting competitive advantage.	Data protection law (20 US state laws as of 2026, EU AI Act) and customer expectations.

Confidentiality covers the business information you designate as confidential. Privacy governs how you handle personal data.

What Does the Processing Integrity Criterion Require and Who Needs It?

The Processing Integrity criterion (PI1.1–PI1.5) confirms one thing for your customers: your system processes data completely, validly, accurately, on time, and only when authorized. It applies to services where processing accuracy is the product — payments, trades, billing, and data automation.

It is the rarest TSC in our auditor network. Most SaaS products do not need it. When a service does process critical transactions, enterprise buyers in finance, logistics, and healthcare often require it before they sign.

Why It Is Hard to Pass

Processing Integrity has high exception rates because it is difficult to evidence. Auditors trace the full lifecycle of transactions, not a sample of logs. They look for proof that your system catches errors, reconciles inputs against outputs, and keeps a tamper-evident record of every event.

The controls auditors look for:

• End-to-end reconciliation (PI1.2–PI1.3). Automated checks that balance inputs against outputs. If 1,000 invoices come in, the system confirms 1,000 corresponding payments were calculated and disbursed.
• Tamper-evident records. Techniques such as hash chaining or Merkle proofs create a ledger where a record cannot be altered without detection.
• Ongoing transaction testing (PI1.4–PI1.5). Test material transaction types on a regular cycle so you find and fix errors before fieldwork.

Auditor note: A database log is not enough on its own. Auditors want to see the reconciliation that proves outputs match authorized inputs for each material transaction type.

If you process payments or other critical transactions, scope it in when those buyers ask for it.

How Do You Scope a SOC 2 Report Without Overspending?

Once you understand the five criteria, the work is deciding which ones your business needs. Every criterion you add increases the controls you maintain, the evidence you collect, and the auditor hours you pay for. Scoping in a criterion no customer asks for raises your cost without winning any deals.

Let Customer Demand Drive Your Scope

Rather than guessing, ask your buyers. Once a year, survey your top prospects and customers with one question: “Which Trust Services Criteria do you require in a SOC 2 report?” In practice, that usually means Security first, then Availability if you sell an uptime SLA, and Confidentiality or Privacy if contracts or regulation require them.

Reduce the Cost of Each Added Criterion

The Common Criteria behind Security apply to every TSC, so most of your evidence is reusable. Platforms like Vanta, Drata, and Secureframe let you define a control once and map its evidence across multiple criteria. When you instrument controls with API evidence — Okta logs, CloudTrail, S3 access logs — adding a criterion later costs far less than rebuilding an evidence library from scratch.

When a prospect requires a criterion you have not scoped, that reuse is what lets you expand the report without starting over. If you are still deciding on scope, start with a SOC 2 readiness assessment before you commit.

Frequently Asked Questions

The most common questions about the Trust Services Criteria:

What Is the Difference Between a SOC 2 Type 1 and Type 2 Report?

A SOC 2 Type 1 report assesses whether your controls are designed correctly on a single date. An auditor confirms the right policies and procedures are in place at that point in time.

A SOC 2 Type 2 report tests whether those controls operated effectively over a period, usually six to twelve months. It is the report nearly every enterprise customer asks for, because it shows the controls worked across the whole period rather than on a single date. For a full comparison, see SOC 2 Type 1 vs Type 2.

How Long Does It Take to Get a SOC 2 Report?

From scratch, readiness usually takes three to six months — writing policies, configuring security tools, and documenting controls. The Type 2 observation period then runs another six to twelve months, after which the auditor needs about four to six weeks for fieldwork and the final report. Start to finish, expect nine to eighteen months.

Which Trust Services Criteria Should My SaaS Company Start With?

Every SOC 2 report must include the Security criterion (CC1–CC9). From there, add only what your contracts and customers require:

• Availability: Add it if you sell customers an uptime SLA and they want proof you can recover from disruptions.
• Confidentiality: Add it if contracts or NDAs require you to protect and securely delete sensitive business data.
• Processing Integrity: Add it if you process payments, trades, or other critical transactions where accuracy is the product.
• Privacy: Add it if you handle personal information, including AI/ML training data, and a buyer specifically requires the Privacy TSC.

Most startups should start with Security alone, then add criteria as specific customers ask for them.

---

Choosing the right auditor affects cost, timeline, and how much rework the audit creates. If you want to compare firms by scope, pricing, and timeline, start with the SOC 2 auditor directory.