SOC 2 for ISVs, Part 2: The Five Trust Service Criteria, Demystified

TL;DR

SOC 2 has five Trust Service Criteria: Security (mandatory), Availability, Processing Integrity, Confidentiality, and Privacy. You don’t audit against all of them — you pick the ones that match what you actually promise customers. Picking too few looks weak; picking too many turns your audit into a multi-quarter slog. This post walks through each criterion, what auditors look for, and how to scope without overcommitting.

Introduction

In Part 1 we covered why SOC 2 is the price of admission to enterprise sales. That gets the why out of the way. Now comes the question every founder asks next: “What does the audit actually cover?”

The answer lives in five categories called the Trust Service Criteria (TSC). They’re defined by the AICPA, and they describe what “trustworthy” means in operational terms. Most ISVs I’ve worked with arrive thinking they need to audit everything, panic-budget for it, then realize halfway through that they’ve scoped in commitments they don’t actually make to customers. Let’s avoid that.

The mental model: criteria are scoped to your promises

Before we go into each criterion, internalize this: SOC 2 audits what you say you do. If your marketing site promises 99.95% uptime, Availability is in scope whether you like it or not. If you handle PII as part of your core service, Privacy is hard to credibly exclude. The criteria you pick should mirror your customer-facing commitments — your MSA, your DPA, your SLA, your privacy policy.

Auditors notice mismatches. So do enterprise procurement teams reading your report.

1. Security — the only mandatory one

Every SOC 2 report includes Security, often called the Common Criteria because it underpins the others. This is the bulk of the audit and where most controls live.

Security covers logical and physical access controls, system operations, change management, and risk mitigation. In practice, an auditor will ask things like:

Who has admin access to your production AWS or GCP accounts, and how is it reviewed?
How do you authenticate users — SSO, MFA, password policies?
How are code changes reviewed, approved, and deployed?
How do you detect and respond to security incidents?
How do you onboard and offboard employees?

If you’re starting with SOC 2, Security alone is a legitimate first report. Plenty of ISVs publish a Type II covering only Security and it satisfies most enterprise buyers. Adding more criteria later — once your operational maturity catches up — is a perfectly fine strategy.

2. Availability — only if you commit to uptime

Availability covers whether the system is available for operation and use as committed. Note the word committed — this criterion is only meaningful if you have actual availability commitments in customer contracts or your public SLA.

Auditors will look at:

Capacity planning and monitoring
Backup and disaster recovery procedures (and whether you’ve actually tested restores)
Incident response and uptime tracking
Environmental protections for infrastructure (mostly handled by AWS/GCP at the IaaS level — you inherit those controls)

When to include it: if you publish an SLA, sell to customers who depend on your uptime, or run anything mission-critical. When to skip it: if you’re early-stage and your contracts don’t make hard uptime promises, including Availability adds audit work without proportional buyer trust.

3. Processing Integrity — niche but important when it applies

Processing Integrity covers whether system processing is complete, valid, accurate, timely, and authorized. The classic use cases are payment processors, billing systems, transaction engines, and any service where the correctness of the output is the product.

Auditors will examine:

Data validation at input
Error handling and reconciliation
Output integrity controls
Monitoring for processing anomalies

When to include it: if you’re a fintech, a billing platform, a clinical-data processor, or anywhere a wrong answer is a serious problem. When to skip it: most general-purpose SaaS doesn’t need it. A collaboration tool or a marketing platform probably has bigger fish to fry.

4. Confidentiality — protecting non-personal sensitive data

Confidentiality is often confused with Privacy, but they’re distinct. Confidentiality is about protecting information designated as confidential — typically business data, IP, customer lists, financial records, source code. Privacy specifically deals with personal information.

Auditors will check:

Encryption in transit and at rest
Data classification and handling procedures
Access restrictions on confidential data
Secure disposal at end of lifecycle

When to include it: if customers entrust you with sensitive business data — think B2B platforms handling contract data, financial records, or proprietary datasets. Many enterprise buyers explicitly want this in scope. When to skip it: rarely a great idea to skip if you’re handling any customer business data, but the controls largely overlap with Security, so the marginal effort is low.

5. Privacy — only when personal data is your business

Privacy covers the collection, use, retention, disclosure, and disposal of personal information in conformance with your stated privacy notice. This is the heaviest criterion — it overlaps with GDPR, CCPA, and other regional regulations, and the evidence burden is real.

Auditors will look at:

Notice and consent mechanisms
Data subject rights (access, deletion, correction)
Cross-border data transfer controls
Retention and disposal policies

When to include it: if processing personal data is core to your product — health-tech, ad-tech, consumer-facing SaaS, anything regulated. When to skip it: if you process personal data only incidentally (e.g., user emails for login), Confidentiality + Security usually cover the bait.

"Do you handle personal data as a core function?"

A real scoping decision: the dual-cloud medical ISV

The medical-domain ISV I mentioned in Part 1 ran on both AWS and GCP. When we scoped their first SOC 2 audit, we had to make exactly these choices:

Security — obvious, mandatory.
Availability — they had hospital customers depending on the platform during clinical workflows. Including it was non-negotiable.
Confidentiality — they handled sensitive clinical metadata. Included.
Privacy — they touched patient-adjacent information but weren’t the system of record for PHI. We excluded it for the first audit because their data model legitimately limited their privacy exposure, and because HIPAA covered the patient-data angle separately. Revisiting it became a Year 2 conversation.
Processing Integrity — not their core value prop. Excluded.

The result was a tightly scoped Type II covering three criteria across both clouds. Clean to defend, fast to evidence, and exactly what their enterprise buyers were asking for. Adding Privacy later would be a delta audit, not a redo.

How scoping affects the rest of the work

Every criterion you add multiplies effort across three dimensions:

Controls — more criteria means more controls to design, document, and operate.
Evidence — every control needs sampleable proof during the observation window. More controls means more screenshots, tickets, logs, and approvals to collect.
Audit hours — auditors price by scope. More criteria means more billable hours and more time on calls answering walkthrough questions.

The instinct to “include everything to look serious” usually backfires. A clean Type II report on Security + Availability + Confidentiality, executed well, beats a sprawling five-criteria report with a long list of exceptions and management responses.

Conclusion

The Trust Service Criteria aren’t a menu where more is better. They’re a contract — pick the ones that match what you actually promise customers, exclude the ones that don’t apply, and be ready to defend both choices to your auditor and your buyers.

In the next post we’ll get into the actual technical foundation: how IAM, logging, encryption, and change management map to controls under these criteria, and what that looks like on AWS, GCP, and Kubernetes.