All 5 SOC 2 Trust Services Criteria — And How to Pick the Right Ones for Your Audit

A CISO at a mid-sized SaaS company once told me his first SOC 2 audit cost nearly double his original budget — not because the auditor overcharged, but because his team scoped in three criteria they didn't actually need. Nobody had stopped to ask which ones the business genuinely required before the engagement letter got signed.

This happens more often than you'd think. SOC 2 audit services get sold as a single package, but the actual scope of what gets tested is something you choose — and choosing wrong either wastes budget or leaves gaps a security reviewer will eventually notice.

Here's what the five criteria actually cover, and how to figure out which ones belong in your SOC 2 audit report.

Where the Five Criteria Come From

SOC 2 is built on five Trust Services Criteria, defined by AICPA: Security, Availability, Confidentiality, Processing Integrity, and Privacy. Every SOC 2 audit report is built around whichever combination of these five your company selects for its audit scope.

Only one of them is non-negotiable.

• Security — The One You Can't Skip

Security is mandatory for every single SOC 2 audit, Type 1 or Type 2. There's no version of this compliance report without it.

The objective here is straightforward: your systems and data need to be protected from unauthorized access, unauthorised disclosure, and damage. What's less straightforward is how much sits inside this one criterion — it's organised into nine sub-categories, labelled CC1 through CC9, covering everything from your governance structure to how you manage system changes to how you monitor for incidents.

Because Security alone spans this much ground, most companies end up with a reasonably strong compliance foundation just from meeting this one requirement — which is part of why it's worth understanding well before deciding whether you need anything else.

• Availability — For Companies Whose Uptime Is the Product

Availability asks a narrower question: is your system actually accessible when your customers need it, as promised?

This matters most for companies where downtime directly breaks a customer commitment — infrastructure providers, platforms with SLA guarantees, anything where "the service was down" is a contract violation, not just an inconvenience. If your customer agreements include specific uptime commitments, Availability usually needs to be in scope.

If you don't have formal uptime commitments and outages are rare and quickly resolved, this criterion may not add meaningful value to your audit — it just adds testing overhead for something nobody's asking you to prove.

• Confidentiality — Narrower Than People Assume

This criterion is most often confused with Privacy, and the mix-up costs companies real time during scoping.

Confidentiality covers specific information your company has committed — through a contract, an NDA, or a written policy — to protect from unauthorised disclosure. Trade secrets, proprietary business information, data shared under a partner NDA, internal financials not yet public. It's about commitments to protect specific categories of information, not a general promise to "keep data safe."

If your customer contracts include confidentiality clauses covering things like their business data, integration details, or proprietary configurations, this criterion is usually worth adding. If your main concern is protecting personal information about individual users, that's actually a different criterion — which brings us to the one everyone assumes they need and often doesn't.

• Privacy — The Biggest Lift, and the Most Commonly Over-Scoped

Privacy governs personal information specifically — how you collect, use, retain, and disclose data that identifies a person, measured against your own stated privacy commitments.

This is also the heaviest criterion to satisfy. It carries the most points of focus of any of the five. Unlike the others, the requirements go deep into specifics — consent handling, data subject rights, retention limits, disclosure tracking. Companies that genuinely handle sensitive personal data — health information, biometric data, anything under HIPAA-adjacent obligations — usually need this in scope, and the lift is justified.

But here's the trap: plenty of SaaS companies add Privacy reflexively, because it "sounds important," without actually processing the kind of personal data that makes this criterion relevant. If your product doesn't handle sensitive personal information at meaningful scale, adding Privacy usually means months of extra audit prep for a criterion your buyers were never actually asking about.

• Processing Integrity — Built for Transactional Accuracy, Not General Reliability

Processing Integrity asks whether your system processes data completely, accurately, and in an authorised, timely way — that outputs match inputs the way they're supposed to.

This one matters most for companies where a processing error has direct financial or operational consequences for the customer: payment processors, billing platforms, e-commerce transaction systems, anything calculating numbers customers rely on being correct. If a bug in your system could silently produce a wrong invoice amount or a miscalculated transaction, Processing Integrity is the criterion built to catch that risk.

For companies that don't process transactions with this kind of stakes attached, this criterion is frequently unnecessary — general system reliability is already covered reasonably well under Security.

How to Actually Decide What Belongs in Your Scope

The honest answer is: start with what your customers are asking for, not with what sounds thorough.

Pull up the security questionnaires and vendor risk assessments you've actually received from prospects and existing customers. What are they asking about specifically? If enterprise buyers keep asking about uptime SLAs, that's your signal for Availability. If they're asking how you handle their proprietary data under NDA, that's Confidentiality. If nobody's asking about personal data handling and you don't process much of it, Privacy probably doesn't belong in your first audit.

A second useful test: look at what you're already doing operationally, not what you'd need to build from scratch. Adding a criterion that reflects existing practice is a matter of documentation and evidence-gathering. Adding a criterion because it sounds comprehensive, when your actual operations don't support it yet, means building real controls from zero — which is where audits blow past their original timeline and budget.

What Happens If You Scope It Wrong

Under-scoping shows up later, usually in the worst possible moment — a big customer's security team asks about something your SOC 2 audit report never covered, and now you're explaining a gap instead of pointing to evidence.

Over-scoping is quieter but just as costly. Every extra criterion means more controls to design, more evidence to gather, and more testing for your SOC 2 auditor to perform — which extends your audit timeline and inflates your fees for criteria that weren't actually protecting a real business need. This is exactly what happened to the CISO from the opening story: three criteria added on the assumption that "more coverage looks better," none of which his actual customers had asked about.

Type 1 vs. Type 2 — A Quick Note on Scope Timing

Whichever criteria you select, apply them the same way whether you're pursuing a Type 1 or Type 2 report — the difference isn't which criteria get tested, but how. A Type 1 report confirms your controls were designed properly on a single date. A SOC 2 Type 2 audit tests whether those same controls actually operated consistently over a period — usually three to twelve months.

This matters for scoping because Type 2 is unforgiving of criteria you've added without real operational maturity behind them. A Type 1 report can pass on well-designed policy alone. A Type 2 audit will sample your actual practice across months — and a criterion you added just to look thorough will show gaps the moment an auditor starts pulling evidence.

Revisiting Scope as Your Company Changes

Your criteria selection isn't locked in forever. A company that starts with just Security often adds Availability once uptime SLAs become part of enterprise contracts, or adds Confidentiality once partnership agreements start including NDA-bound data sharing. This is normal, and expected — SOC 2 reporting is meant to track what your business actually promises customers, not a fixed checklist chosen once at the start.

The mistake isn't adding criteria later. The mistake is adding them too early, before there's a real commitment behind them to test against.

Getting This Right Before Your Audit Starts

Scoping decisions get made before the audit begins, but they shape everything that follows — how long the engagement takes, what it costs, and whether the final report actually answers the questions your buyers are asking. Getting an experienced SOC 2 auditor involved during scoping, rather than after the engagement is already underway, tends to catch these mismatches early — before a company spends months building controls for a criterion nobody needed, or discovers a real gap only after a customer's security team finds it first.