Every SOC 2 report begins with a decision too many teams skip past: only one of the five Trust Service Criteria is required. Security is built in by default. Availability, Processing Integrity, Confidentiality, and Privacy are optional — added only when a company's real commitments call for them. Skip that decision and one of two things happens: the audit balloons with evidence nobody asked for, or the report ships without covering the promise a customer cares about. Here is what each criterion actually tests, and how to tell which ones belong in scope.
Five Criteria, One Mandatory
SOC 2 is an attestation engagement performed under the AICPA's SSAE 18 standard by a licensed CPA firm. That distinction matters more than it sounds: the outcome is a report, not a certification. There is no seal a company earns once and keeps forever, and no pass or fail badge to display. The report is the auditor's independent opinion on how a defined set of controls are designed and — for a Type II — whether they operated effectively over a period.
The AICPA's Trust Services Criteria define what those controls cover: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Only Security — the Common Criteria — is mandatory in every SOC 2 report. The other four are add-ons, scoped in only when they map to a promise the company has actually made its customers.
| Criterion | What It Commits You To | Who Typically Needs It |
|---|---|---|
| Security | Common Criteria (CC1–CC9): access control, risk assessment, monitoring, incident response, change management | Every company — mandatory, no exceptions |
| Availability | Systems meet published uptime and performance commitments; DR and backup practices are in place | SaaS platforms with SLAs or uptime guarantees |
| Processing Integrity | Data is processed completely, accurately, on time, and only with proper authorization | Payment, billing, and transaction-processing platforms |
| Confidentiality | Information designated confidential — IP, contracts, financial data — is protected via encryption and access control | B2B vendors handling client IP or operating under NDAs |
| Privacy | Personal information is collected, used, retained, and disclosed per the published privacy notice and GAPP | Companies collecting personal data directly, as a controller |
Companies don't "pass" SOC 2 or get "SOC 2 certified." The CPA firm issues a written opinion, scoped to whichever Trust Service Criteria the company chose to include. Two companies can both hold a SOC 2 report while covering entirely different ground — one tested against Security alone, another against Security plus three more.
Security: The Common Criteria
Security is organized under nine categories, the Common Criteria, CC1 through CC9. Together they cover whether an organization can prevent, detect, and respond to unauthorized access and compromise — the baseline question every other criterion assumes is already answered.
The Nine Common Criteria
- CC1 — Control environment and organizational oversight
- CC2 — Communication and information
- CC3 — Risk assessment
- CC4 — Monitoring activities
- CC5 — Control activities
- CC6 — Logical and physical access controls
- CC7 — System operations
- CC8 — Change management
- CC9 — Risk mitigation
Because Security is mandatory, no company skips it. It is also the foundation the other four build on: an Availability commitment means little if the underlying systems aren't protected from compromise, and Confidentiality protections lean on the same access controls Security already requires. The 2020 compromise of SolarWinds' Orion software illustrates why monitoring and detection — not just access control on paper — carry real weight: the intrusion persisted for months, precisely the kind of gap CC4 and CC7 exist to close.
Availability
Availability tests whether the systems a company has committed to keep available actually do so, measured against the commitments themselves — a published SLA, an uptime percentage, a contractual response time. It doesn't require some absolute bar like continuous uptime; it tests whether the organization meets whatever it has explicitly promised, and whether it has the monitoring, capacity planning, and disaster recovery practices in place to make that plausible.
In practice this covers performance and capacity monitoring, environmental safeguards for infrastructure, incident recovery procedures, and backup and disaster recovery testing. The evidence an auditor expects includes monitoring logs, capacity reports, and records of DR tests actually being run — not just a DR plan sitting in a drawer.
Availability belongs in scope for SaaS platforms with published SLAs, infrastructure and hosting providers, and vendors whose downtime disrupts customer operations. A company without formal uptime commitments gains little from including it — it adds evidence-collection burden without a promise to justify it.
Processing Integrity
Processing Integrity is often confused with Security. Security asks whether data is protected from unauthorized access. Processing Integrity asks something different: whether the processing itself does what it claims — a transaction posts to the right account, invoice math is correct, a batch job doesn't drop or duplicate records, and processing only happens with proper authorization. It tests whether data is processed completely, accurately, on time, and only as authorized.
This criterion matters most for payment processors, billing engines, e-commerce order and fulfillment systems, and financial platforms — anywhere a processing error, not a breach, is the customer's real risk. A company that primarily stores or transmits data without materially transforming or calculating it usually gets little benefit from adding Processing Integrity; most SaaS platforms fall into that category and are better served by Security alone.
Confidentiality
Confidentiality protects information an organization has agreed, formally or contractually, to treat as confidential — source code, business plans, contracts, financial data, client IP. It covers anything designated confidential by internal policy or customer agreement, and isn't limited to information about a specific individual.
In practice, Confidentiality controls look like encryption in transit and at rest, access restricted to a need-to-know basis, and confidentiality provisions honored inside contracts and data-handling agreements. It belongs in scope for B2B SaaS companies handling client IP or trade secrets, vendors operating under NDAs with enterprise customers, and any company whose contracts explicitly promise to protect designated confidential information.
The two get conflated constantly. Confidentiality protects whatever an organization has designated confidential — contracts, source code, financial data — none of which need relate to a person. Privacy is narrower: it applies specifically to personal information, evaluated against the company's own privacy notice. A company can carry heavy Confidentiality obligations without processing meaningful personal data, and the reverse is just as common.
Privacy
Privacy governs how personal information is collected, used, retained, and disclosed, measured against the organization's own privacy notice and the AICPA's Generally Accepted Privacy Principles — notice, choice, collection, use, retention, and disclosure. Unlike Confidentiality's broader reach, Privacy is specifically about information tied to an identifiable individual: the test is whether the company does what it told people it would do.
Privacy typically belongs in scope for companies that collect meaningful volumes of personal information directly, as a data controller — consumer applications, HR platforms, marketing and advertising platforms. Companies that primarily process data on behalf of others often route those obligations through Confidentiality and their customer contracts instead. Where personal data crosses borders, Privacy scoping tends to sit alongside separate obligations under frameworks like GDPR or India's DPDP Act.
Privacy is the least commonly added of the five — and, when added, the one most often scoped too broadly. Because "personal information" can be defined expansively, taking it on without a clear read of the actual privacy notice and data flows multiplies the evidence-collection burden fast, for coverage the audit may not need.
How to Scope Your SOC 2
The right way to choose which of the four optional criteria belong in scope is to work backward from commitments already made — contracts, SLAs, marketing claims, and privacy notices — rather than forward from what sounds thorough.
A Quick Scoping Checklist
- Do contracts include an SLA or uptime commitment? Add Availability.
- Does the platform calculate, transact, or transform customer data? Add Processing Integrity.
- Do agreements include confidentiality or NDA clauses over client data? Add Confidentiality.
- Does the company collect personal information directly, governed by its own privacy notice? Add Privacy.
- Is the company undergoing SOC 2 at all? Security is already included.
Adding all five to look thorough is its own mistake: more evidence, more controls to test, more time on the clock, for coverage no buyer asked for. Scoping too narrow is just as wrong — leaving out a category a major customer's contract requires means the report doesn't answer the question the deal needs answered. Choosing which SOC 2 Type to pursue is a related but separate decision from which criteria to scope.
Final Thought
The five Trust Service Criteria aren't a checklist to complete in order — they're a set of promises, and only Security is universal. The other four exist because companies make different commitments, and the criteria let the report scope itself to match.
The test that cuts through most scoping debates: can the company point to the actual sentence in a contract, SLA, or privacy notice a given criterion is protecting? If not, that decision deserves a second look before the audit begins — not after the evidence has been collected for something nobody promised.
Frequently Asked Questions
Yes. Security, formally the Common Criteria (CC1 through CC9), is included in every SOC 2 report regardless of industry or size. Availability, Processing Integrity, Confidentiality, and Privacy are optional, added only when they map to commitments the company has actually made to its customers.
Confidentiality protects information the organization has agreed to keep confidential — source code, business plans, client IP, financial data — regardless of whether it relates to a person. Privacy is narrower: it governs personal information specifically, measured against the entity's own privacy notice and the AICPA's Generally Accepted Privacy Principles. The two are easy to conflate but answer different questions.
No. Availability only belongs in scope if the company has made real uptime or performance commitments, such as a published SLA. Processing Integrity applies to platforms where data is transformed, calculated, or transacted, such as payment or billing systems. A company that mostly stores and transmits data without materially processing it often needs neither, and adding them anyway increases audit cost without a corresponding buyer requirement.
No. SOC 2 is an attestation engagement performed under the AICPA's SSAE 18 standard by a licensed CPA firm. The result is a report containing the auditor's opinion on the design — and for a Type II, the operating effectiveness — of controls mapped to the chosen Trust Service Criteria, not a certificate or pass or fail badge.
Start with what the company has actually promised: contracts, SLAs, marketing claims, and privacy notices. An uptime commitment points to Availability, transaction processing points to Processing Integrity, NDA clauses point to Confidentiality, and direct collection of personal information points to Privacy. Security is always included. Scoping beyond what's promised adds audit burden without buyer value.