SOC 2 Trust Service Criteria

SOC 2 is built around five Trust Services Criteria (TSC), defined by the AICPA. Security is mandatory — every SOC 2 report includes it. The other four — availability, processing integrity, confidentiality, and privacy — are optional and selected based on your service and the commitments you make to customers.

Scoping the criteria correctly is one of the highest-leverage decisions in your SOC 2 program. Include too few and the report fails to satisfy buyers; include too many and you pay for audit scope you did not need. This lesson breaks down what each category actually requires, how controls map to criteria, and how to scope like someone who has done this before.

The current framework is the 2017 Trust Services Criteria, revised in 2022. The 2022 revision changed no criteria — it updated the "points of focus," the illustrative guidance auditors use to interpret each criterion, to reflect modern realities: cloud infrastructure, data governance and classification, ransomware-era resilience, and expanded confidentiality considerations. If a vendor or template still references the 2016 TSC, it is out of date.

How the Criteria Are Structured

The TSC are built on the COSO Internal Control framework — the same foundation used in financial audits — extended with security-specific criteria. This is why SOC 2 covers things founders do not expect, like board oversight and HR practices, alongside firewalls and encryption. SOC 2 evaluates your organization's control environment, not just your production stack.

Each criterion is a broad statement (for example, "the entity restricts logical access to information assets"), supported by points of focus that suggest what meeting it looks like. Your auditor does not hand you a control list; you define the controls that address each criterion, and the auditor tests whether they are designed and operating effectively. Two companies can satisfy the same criterion with entirely different controls — that flexibility is a feature, but it means scoping and control design require judgment.

Security (The Common Criteria)

Security is the foundation of every SOC 2 report and is formally called the Common Criteria because the other four categories build on it. It covers protection of information and systems against unauthorized access, disclosure, and damage — logical and physical. The common criteria are organized into nine series:

Two practical observations from real audits. First, CC6 generates the most evidence requests — expect sampling of onboarding and offboarding tickets, access review records, and MFA configuration across every in-scope system. Second, CC1 through CC4 surprise engineering-led teams because they are organizational, not technical: you need a risk register, documented policies people have actually acknowledged, and some form of management oversight, even at a 10-person company.

Typical controls mapped to Security: SSO with MFA enforced, role-based access with quarterly reviews, endpoint management with disk encryption, code review and CI/CD gates, centralized logging and alerting, annual penetration testing, vendor risk reviews, background checks, security awareness training, and an incident response plan that has been tested.

Availability

Availability addresses whether your system is operational and usable as committed or agreed — the key phrase. The auditor evaluates you against your own commitments (SLAs, uptime targets, published status commitments), not against an absolute standard.

Include this category if you publish SLAs, if customers depend on your uptime, or if buyers ask about disaster recovery. In practice, most SaaS companies add Availability in year one or two because it is a modest increment over Security: perhaps 10 to 15 additional controls, most of which a competent infrastructure team already runs.

Typical controls: infrastructure and application monitoring with on-call alerting, capacity planning, automated backups with tested restores (untested backups are a classic exception), a documented and exercised disaster recovery plan with defined RTO/RPO, redundancy across availability zones, and incident postmortems.

Processing Integrity

Processing integrity ensures that system processing is complete, valid, accurate, timely, and authorized. Include it when the correctness of your processing is itself the product: payment processing, billing engines, payroll, tax calculation, trading systems, claims processing, and data pipelines whose outputs drive customer decisions.

This is the least commonly included category, and appropriately so — for a typical collaboration or workflow SaaS, buyers do not expect it. But for fintechs, its absence gets noticed.

Typical controls: input validation and reconciliation checks, processing error detection and alerting, queue monitoring with dead-letter handling, data quality checks between pipeline stages, authorization controls on processing changes, and documented procedures for correcting processing errors.

Confidentiality

Confidentiality protects information designated as confidential — customer business data, trade secrets, contracts, and other sensitive business information — through its lifecycle from ingestion to disposal. Where Security asks "can unauthorized people get in?", Confidentiality asks "is confidential data identified, protected according to commitments, and destroyed when it should be?"

Include it if your contracts contain confidentiality obligations regarding customer data (most B2B contracts do) and buyers ask how you protect their data specifically. It is a common addition because the incremental controls are small: data classification policy, encryption at rest and in transit (which Security already requires), access restrictions on confidential data, retention schedules, and secure disposal/deletion procedures — including deletion upon contract termination, which enterprise buyers increasingly test.

Privacy

Privacy addresses the collection, use, retention, disclosure, and disposal of personal information, measured against your own privacy notice and the AICPA's privacy criteria. It is the largest optional category by control count and the least frequently included.

Two crucial clarifications. First, privacy applies to personal information; confidentiality applies to any designated confidential information — they are not interchangeable. Second, SOC 2 privacy is not GDPR or CCPA compliance. It examines whether you meet your own stated privacy commitments, not whether you satisfy a regulator. Companies with heavy GDPR obligations often address privacy through ISO 27701 or dedicated privacy assessments instead.

Include Privacy only if you process significant personal data as a core function (consumer data platforms, HR tech, healthtech) and customers specifically request it. For most B2B SaaS, Security plus Confidentiality answers the questions buyers actually ask.

Choosing Your Scope

A defensible default path:

1. Year one: Security, or Security + Availability if you have SLAs. This satisfies the majority of buyer requests and keeps your first audit contained.
2. Year two: add Availability and/or Confidentiality based on the questionnaire patterns your sales team sees.
3. Add Processing Integrity or Privacy only on demand — when contracts or specific customers require them.

Each added category increases policy work, evidence collection, audit fieldwork, and fees. Roughly, each optional category adds 10 to 25 percent to audit cost and a proportional amount of internal effort. Adding a category is easy in a later cycle; removing one you already reported on prompts awkward questions.

Scoping Checklist

Before you finalize scope with your auditor:

• Reviewed the last 6 to 12 months of customer security questionnaires for criteria-specific questions
• Inventoried contractual commitments — SLAs, confidentiality clauses, data deletion obligations, privacy commitments
• Confirmed Security scope covers the actual product(s) customers buy, including supporting infrastructure
• Decided on Availability based on published SLAs or uptime expectations
• Decided on Confidentiality based on contract language about customer data
• Ruled Processing Integrity in or out based on whether processing accuracy is the product
• Ruled Privacy in or out based on personal-data volume and explicit customer demand
• Mapped existing controls to each in-scope criterion and identified gaps
• Confirmed subservice organizations (AWS, GCP, Azure) are handled via the carve-out method and their SOC reports collected
• Validated scope and criteria selection with your auditor before the engagement letter is signed

Common Scoping Mistakes

Including every category to look thorough. More categories do not mean a stronger report — they mean more surface area for exceptions. Buyers respect a clean Security + Availability report far more than a five-category report with qualified areas.

Scoping out the system buyers care about. If your report covers "Platform A" but the customer is buying "Platform B," the report is useless to them. Align the system description with what sales actually sells.

Forgetting subservice organizations. Your cloud provider's controls (physical security, hardware disposal) are carved out of your report, but you must list them, state the carve-out, and monitor their SOC reports. Auditors check this.

Confusing confidentiality with privacy. Sales teams and even some consultants use them interchangeably. Scope the one your data and contracts actually implicate.

Treating points of focus as mandatory controls. They are illustrative. You address the criteria; the points of focus guide interpretation. Blindly implementing every point of focus wastes effort on controls irrelevant to your environment.

Frequently Asked Questions

How many controls does a SOC 2 audit cover?

There is no fixed number because you define the controls. A typical Security-only report at a startup includes roughly 60 to 90 controls; adding Availability and Confidentiality commonly pushes the total to 90 to 120. Compliance automation platforms ship prebuilt control sets mapped to the criteria, which most auditors accept as a starting point.

Can we change criteria between audit periods?

Yes. Scope is set per examination. Companies routinely add categories in later cycles as customer demands evolve. Just coordinate with your auditor early, since a new category needs its controls operating for the full observation period.

Is there a "SOC 2 checklist" of required safeguards?

No official one. Unlike PCI DSS or NIST 800-171, SOC 2 does not prescribe specific safeguards. The criteria state outcomes; you choose controls. This is why two SOC 2 reports can look quite different — and why reading the actual controls and test results in a vendor's report matters more than the fact that a report exists.

Which criteria do enterprise buyers actually require?

Security, always. Availability, very commonly — especially if you have an SLA. Confidentiality, increasingly. Processing Integrity and Privacy are requested narrowly, by buyers whose use case depends on them. If in doubt, ask your three largest prospects what their vendor risk teams require.

Did the 2022 TSC revision change what we need to do?

Not structurally — the criteria and category names are identical to 2017. Auditors now interpret them through updated points of focus, which in practice raised expectations around data governance, disposal of information, and resilience against destructive attacks like ransomware. If your program was built on 2017 guidance, review your data classification, deletion, and recovery controls.

Do the Trust Services Criteria map to ISO 27001 or NIST CSF?

Yes, substantially. The AICPA publishes mappings, and most compliance platforms cross-map controls so evidence collected once satisfies multiple frameworks. Security's CC series overlaps heavily with ISO 27001 Annex A; if you plan to pursue both, design controls once against a common set.

In the next lesson, we will compare Type 1 and Type 2 reports.

The right tooling makes criteria mapping and evidence collection dramatically easier. AuditXYZ helps you compare compliance automation platforms and evaluate auditors so you can scope and staff your SOC 2 with confidence.