Introduction
SOC 2 Trust Services Criteria (often shortened to TSC) are the categories of commitments a service organization can include in a SOC 2 examination. They describe what the report is about: Security, Availability, Processing Integrity, Confidentiality, and Privacy.
Choosing criteria is one of the earliest scoping decisions in a SOC 2 program. Pick too narrowly and customers may ask for commitments you did not cover. Pick too broadly and you inherit control and evidence work you are not ready to operate across an audit period.
In plain language: Trust Services Criteria answer, "Which trust promises are in this SOC 2 report, and therefore which control stories must we design, operate, and prove?"
This guide explains each criterion in everyday terms, how Security works as the common baseline, how scoping and selection usually work, how criteria choice differs from Type 1 vs Type 2, and what evidence themes tend to appear. It uses industry-common understanding of the criteria. It does not quote AICPA standards text and is not a substitute for your auditor's engagement scoping.
Related reading: What Is SOC 2 Evidence?, how to prepare for a SOC 2 audit, continuous compliance, and the glossary entries for availability and confidentiality.
What Are Trust Services Criteria?
Trust Services Criteria are the topical categories used in SOC 2 to organize control objectives around customer trust concerns. A SOC 2 report covers one or more of these categories for a described system (your product, platform, or service boundary as defined in the system description).
At a high level:
- Security addresses protection against unauthorized access, unauthorized disclosure of information, and damage to systems that could compromise availability, integrity, confidentiality, or privacy.
- Availability addresses whether the system is available for operation and use as committed or agreed.
- Processing Integrity addresses whether system processing is complete, valid, accurate, timely, and authorized.
- Confidentiality addresses protection of information designated as confidential.
- Privacy addresses collection, use, retention, disclosure, and disposal of personal information consistent with commitments and criteria related to privacy.
Security is almost always in scope for SOC 2 engagements. The other four are optional add-ons based on your commitments, customer expectations, and what you are prepared to evidence.
Criteria are not the same thing as your internal control framework. You still design specific controls, assign control owners, and collect proof. Criteria tell you which trust themes the examination covers.
The Five Criteria in Plain Language
Security
Security is the baseline category for most SOC 2 reports. In practice, it covers how you prevent and detect unauthorized access, protect systems and data from compromise, and support related trust goals through logical access, network and infrastructure protections, change control, risk management, vendor oversight, monitoring, and incident response.
Typical Security conversations include identity and access control, MFA, least privilege, secure development and change management, vulnerability handling, logging and alerting, endpoint and cloud configuration baselines, security training, and third-party risk.
If you only remember one thing: Security is the default SOC 2 story customers expect when they ask for "your SOC 2."
Availability
Availability focuses on whether the system is up and usable as you committed. It is not a guarantee of 100% uptime. It is about the controls and processes that support availability objectives: capacity planning, monitoring, backup and restore, failover or redundancy design where claimed, incident handling for outages, and communication when commitments are at risk.
Teams often add Availability when they publish uptime SLAs, sell mission-critical workflows, or hear customers ask specifically about resilience and disaster recovery practices. See also disaster recovery and business continuity plan glossary pages for neighboring concepts.
Processing Integrity
Processing Integrity focuses on whether processing is complete, valid, accurate, timely, and authorized. Think of pipelines that transform customer data, billing engines, payroll calculations, or transaction processing where wrong outputs create real harm.
Controls often include input validation, job monitoring, reconciliation, error handling, authorized override paths, and evidence that broken jobs were detected and corrected. Not every SaaS product needs Processing Integrity in the SOC 2 report. Add it when processing correctness is a primary customer trust concern and you can evidence it.
Confidentiality
Confidentiality focuses on protecting information you designate as confidential. That designation may come from contracts, data classification, or product design (for example, customer secrets, proprietary content, or non-public business data).
Controls often overlap with Security (encryption, access restriction, secure disposal) but the Confidentiality criterion emphasizes commitments about confidential information specifically: how it is identified, how access is limited, how it is protected in transit and at rest with encryption where appropriate, and how retention and disposal follow data retention rules.
Privacy
Privacy focuses on personal information: notice, choice, collection, use, retention, disclosure, access, and disposal practices aligned to your privacy commitments and applicable criteria themes. It is related to, but not identical to, Confidentiality. Confidentiality can cover many non-personal secrets. Privacy centers on personal data lifecycle commitments.
Teams consider Privacy when they make detailed privacy commitments to customers, process sensitive personal data as a core product function, or face customer questionnaires that specifically ask whether Privacy is in the SOC 2. Privacy scoping often requires tight partnership with legal and privacy counsel. This guide does not provide legal advice.
Security as the Common Baseline
In common market practice, SOC 2 examinations include Security. Additional criteria are selected when your system description and customer commitments justify the extra scope.
That baseline matters operationally:
- Many Security controls already support Availability, Confidentiality, or Privacy outcomes (for example, access restriction and encryption).
- Adding a criterion still adds specific commitments, tests, and evidence expectations. Overlap does not mean "free."
- Customers who ask for "SOC 2" usually mean Security at minimum. Some industries additionally expect Availability or Confidentiality based on the service.
Start by making Security real: owned controls, steady evidence collection, and a clear system description. Add criteria when the customer and product story require them and when you can operate the extra controls across the period.
How Scoping Works
Scoping a SOC 2 engagement usually includes several decisions that interact with criteria selection:
- System description boundary. Which products, environments, supporting infrastructure, and locations are in the report?
- Trust Services Criteria. Security plus any optional criteria.
- Report type. Type 1 (design at a point in time) vs Type 2 (operating effectiveness over a period). See SOC 2 Type 1 vs Type 2.
- Subservice organizations. Which vendors are carved out or included, and how complementary user entity controls are described.
- Control set. Your mapped controls that address the in-scope criteria.
Scoping is collaborative with your auditor. Internal readiness work (including a structured gap-style readiness pass against your chosen criteria and compliance framework obligations) should happen before you lock marketing language about what the report will cover. Do not invent coverage claims before the engagement is defined.
Clarify in writing:
- What is in the system boundary
- Which criteria are in scope
- The period or point-in-time date
- Which environments (production only vs production plus staging) are included
Ambiguous scope creates evidence thrash and customer confusion later.
Selecting Additional Criteria
Use customer demand, product risk, and operating readiness as the decision filter.
| Criterion | Often considered when... | Watch-outs |
|---|---|---|
| Availability | You publish uptime SLAs, sell high-availability services, or customers ask about resilience | Need monitoring, incident, backup/restore, and capacity evidence across the period |
| Processing Integrity | Incorrect processing would materially harm customers (billing, transactions, calculations) | Need reconciliations, job controls, error queues, and authorization of overrides |
| Confidentiality | Contracts designate confidential data and customers ask how it is protected beyond baseline Security | Need clear classification, handling rules, and disposal evidence |
| Privacy | Personal data lifecycle commitments are central and customers ask for Privacy in SOC 2 | Needs legal alignment, notices, retention, and subject-request processes where committed |
Practical selection tips:
- Do not add a criterion only because a competitor lists it, unless you can operate and evidence it.
- Do not skip a criterion your enterprise buyers consistently require if you are ready to support it.
- Revisit selection when you launch a new product line or enter a new market segment.
- Keep control mapping updated so shared controls are reused without double-counting fictionally.
Trust Services Criteria vs Type 1 and Type 2
Criteria and report type answer different questions.
| Decision | Question it answers |
|---|---|
| Trust Services Criteria | Which trust themes are covered in the report? |
| Type 1 vs Type 2 | Is the report about design at a point in time, or operating effectiveness over a period? |
You can have Security-only Type 1, Security-only Type 2, or Security plus Availability Type 2, and so on. Adding criteria increases topical breadth. Choosing Type 2 increases the need for evidence across time.
For Type 2, plan evidence collection calendars for each in-scope criterion, not only a policy binder at kickoff. Period length and sample expectations are set with your auditor. See SOC 2 Type 1 vs Type 2 for a deeper comparison.
Examples of Controls and Evidence by Criterion
Exact controls vary by company. These examples illustrate common themes. They are not a mandatory checklist and not a claim about any universal auditor request list.
Security
| Control theme | Example evidence |
|---|---|
| Workforce access reviews | Population exports, reviewer decisions, remediation tickets |
| Privileged access restricted | Admin group exports, MFA status, joiner-mover-leaver tickets |
| Changes approved before production | PR approvals, deployment tickets, emergency change records |
| Vendors reviewed on cadence | Inventory, risk tiers, SOC reports or questionnaires, review notes |
| Alerts triaged | Monitoring tickets with timestamps and closure |
| Security training | Completion reports with dates and user IDs |
Availability
| Control theme | Example evidence |
|---|---|
| Uptime monitoring and incident response | Status page records, incident tickets, post-incident notes |
| Backup and restore | Backup job reports, restore test tickets and results |
| Capacity and saturation alerts | Cloud metrics exports, scaling tickets |
| Redundancy or failover as claimed | Architecture docs plus test or exercise records where applicable |
Processing Integrity
| Control theme | Example evidence |
|---|---|
| Input validation and error handling | Design docs, ticket samples for rejected inputs |
| Batch job success monitoring | Job dashboards, failure alerts, rerun approvals |
| Reconciliations | Reconciliation worksheets with reviewers and dates |
| Authorized corrections | Override logs tied to approvals |
Confidentiality
| Control theme | Example evidence |
|---|---|
| Data classification and handling | Classification policy, labeled repositories, access rules |
| Encryption in transit and at rest | Configuration exports, TLS and KMS settings |
| Confidential data disposal | Deletion tickets, retention job logs |
| Need-to-know access | Access reviews focused on confidential stores |
Privacy
| Control theme | Example evidence |
|---|---|
| Privacy notice and commitment alignment | Published notices, change history, legal review records |
| Retention and deletion of personal data | Retention schedules, deletion job evidence |
| Access or deletion request handling (if committed) | Request tickets, completion timestamps |
| Vendor privacy due diligence where relevant | DPAs, questionnaire responses, review notes |
For quality attributes of strong packets (dates, ownership, relevance), see What Is SOC 2 Evidence? and audit evidence collection.
Common Scoping Mistakes
Teams struggle when they:
- Add Availability or Privacy because it "sounds stronger," then discover missing restore tests or privacy request workflows mid-period
- Market "SOC 2 with all five criteria" before controls and evidence paths exist
- Confuse criteria selection with Type 2 readiness
- Write a system description that does not match the environments engineers actually operate
- Assume Security evidence automatically satisfies every other criterion without mapping
- Forget subservice organizations and complementary controls in the description
- Change product scope mid-period without updating control ownership and collection calendars (control drift)
- Treat customer questionnaire language as the engagement scope without auditor alignment
These mistakes create rushed remediation, weak samples, and awkward customer conversations.
How to Prepare Once Criteria Are Chosen
A practical preparation arc:
- Confirm criteria and system boundary with leadership and your auditor.
- Map controls to each in-scope criterion with owners and expected evidence types.
- Run a readiness or gap pass to find missing policies, processes, and proof paths. Convert gaps into owned work and, when needed, a corrective action plan.
- Stand up collection cadence for Type 2 periods: access reviews, change samples, vendor renewals, monitoring tickets, restore tests, and any criterion-specific artifacts.
- Train control owners on what "good evidence" means: dated, complete, traceable.
- Track exceptions with time bounds rather than silent waivers (exception management).
- Rehearse the packet before fieldwork using your SOC 2 preparation checklist habits.
- Keep collecting under continuous compliance so the next period is not another scramble. Related: continuous compliance.
Preparation is an operating program, not a week of screenshots.
How AuditFlo Helps
AuditFlo (auditflo.co) helps teams collect and organize control evidence across the audit period so SOC 2 readiness is continuous rather than seasonal.
With continuous evidence collection, control mapping support, and audit-period history, you can preserve dates and ownership and reduce last-minute screenshots across common systems such as GitHub, Jira, Okta, AWS, and Google Workspace. That support applies whether your report covers Security alone or Security plus additional Trust Services Criteria.
AuditFlo is framed here as evidence and readiness support. It does not select your criteria for you, issue a SOC 2 report, replace your auditor, certify compliance, or guarantee any Trust Services Criteria outcome.
If you want to see how evidence can stay organized for your scoped criteria, request a demo.
Final Thoughts
Trust Services Criteria define which trust themes a SOC 2 report covers. Security is the common baseline. Availability, Processing Integrity, Confidentiality, and Privacy are optional additions driven by commitments, customer expectations, and your ability to operate and evidence related controls. Criteria choice is separate from Type 1 vs Type 2. Scope carefully, map controls deliberately, collect dated proof over the period, and avoid marketing criteria you cannot support. Strong scoping plus steady evidence habits make SOC 2 conversations with auditors and customers far more predictable.
FAQ
Is Security required for every SOC 2?
In common market practice, SOC 2 examinations include Security. Confirm scoping with your auditor for your engagement. Customers who ask for "a SOC 2" usually expect Security at minimum.
Do we need all five Trust Services Criteria?
No. Many organizations start with Security only, then add criteria when customer demand and operating readiness justify the extra scope. Broader is not automatically better.
What is the difference between Confidentiality and Privacy?
Confidentiality focuses on information designated as confidential, which may include non-personal business or customer secrets. Privacy focuses on personal information lifecycle commitments such as notice, use, retention, and disposal. They can overlap in controls (for example, access restriction) but they are not the same criterion.
Does adding Availability mean we guarantee uptime?
No. Availability in a SOC 2 context relates to controls supporting availability commitments, not a promise of perfect uptime. Your SLAs and contracts remain separate commercial terms. See availability.
How do Trust Services Criteria relate to Type 1 and Type 2?
Criteria decide topical coverage. Type 1 vs Type 2 decides whether the report addresses design at a point in time or operating effectiveness over a period. You choose both. Details: SOC 2 Type 1 vs Type 2.
Can one control support more than one criterion?
Often yes, when mapping is honest. For example, access restriction may support Security and Confidentiality themes. Document control mapping explicitly so owners know which evidence serves which story.
Where should we go next after choosing criteria?
Build or refresh your control list, run a readiness gap pass, set evidence cadence, and follow a preparation guide such as How to Prepare for a SOC 2 Audit. For proof quality, see What Is SOC 2 Evidence? and audit evidence collection.