SOC 2 Trust Services Criteria: 5 Categories & Scope

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.

Scope Decision Matrix

Security is required. Add another category when it matches a commitment your customers rely on — not because a generic checklist includes it.

Customer promise or data type	Category to consider	Evidence buyers and auditors may expect	Usually leave it out when
“The service will meet this uptime or recovery target.”	Availability	Capacity monitoring, backups, recovery test results, measured RTO/RPO	You make no material availability commitment beyond Security controls
“Transactions or calculations will be complete, accurate, timely, and authorized.”	Processing Integrity	Input validation, exception handling, reconciliation, processing tests	Your product stores or displays data but does not make a processing-accuracy promise
“We will protect and securely dispose of designated business information.”	Confidentiality	Classification, access restrictions, protection measures, deletion evidence	Contracts do not designate information as confidential beyond the Security scope
“We collect and use personal information according to stated privacy commitments.”	Privacy	Notice, consent where applicable, data inventory, access/correction, retention, disclosure, monitoring	A separate privacy program meets obligations and customers do not require the Privacy category in the report

This is a scoping prompt, not a substitute for legal advice or the CPA firm’s engagement decision. For the control sets behind each category, see the full SOC 2 controls list and the SOC 2 security controls breakdown.

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 systems and data from unauthorized access, disclosure, and damage. It is required in every report, so it is the starting point for scope.

CC6: Logical and Physical Access

For CC6 (logical and physical access), check three evidence-heavy failure modes before fieldwork: missing MFA, terminated personnel who retain 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.

Pre-fieldwork check: Pull an access export, reconcile it against current personnel and approved roles, and resolve stale accounts before the observation period starts.

Reuse Security Evidence When Adding Another TSC

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 recovery procedures. A disaster-recovery plan with no exercise evidence does not demonstrate that the procedure operated. Depending on the control and commitments, evidence may come from a tabletop, restore test, or live failover test.

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, restore, or failover exercises run periodically — often annually — based on commitments and risk.

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.

Evidence note: Stated RTO and RPO targets are not enough on their own. Keep dated recovery-test results showing whether you met them, record failures, and track corrective actions. Backup architecture and report presentation depend on your system and the CPA firm’s reporting approach.

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 secure disposal when that information is no longer needed. For C1.2, a deletion policy is not enough on its own; keep evidence that the process ran.

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.

2026 regulatory context: Privacy laws and the EU AI Act can create obligations outside a SOC 2 engagement. They do not automatically require you to scope the Privacy category. Map the laws and contracts that apply to each data flow with counsel, then decide with the CPA firm whether the Privacy TSC adds useful assurance. For AI systems placed on the EU market, consult the European Commission’s current AI Act timeline rather than relying on a static deadline summary here.

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 designated information.	Privacy commitments, applicable law, 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.

Many SaaS products do not make a processing-accuracy commitment that warrants this category. It becomes relevant when the service itself processes material transactions or data and customers rely on the completeness, accuracy, timeliness, or authorization of that processing.

Why It Requires Detailed Evidence

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.