A mid-size SaaS company kicks off its first SOC 2 audit and immediately hits a decision it didn't budget time for: which of the five SOC 2 Trust Services Criteria actually apply to them. The AICPA's framework — Security, Availability, Processing Integrity, Confidentiality, and Privacy — looks like a menu, but only one item is mandatory, and picking the wrong extras adds months of evidence collection for controls a customer never asked about. Compliance automation platforms like Secureframe have built entire products around helping teams answer this question faster, mapping cloud configurations and HR systems to specific criteria. But mapping criteria to policy language is only half the job when the thing being audited is a software build pipeline, not just a SaaS backend. This post breaks down what each Trust Services Criterion actually covers, when to add it, and where evidence for software supply chain risk fits into the picture.
What are the SOC 2 Trust Services Criteria?
The Trust Services Criteria are five categories of controls, published by the AICPA and last substantively revised in 2017 (with points of focus updated in 2022), that an auditor evaluates during a SOC 2 examination. Every SOC 2 report is built on the Common Criteria — a set of 33 individual criteria organized into nine series (CC1 through CC9) covering governance, risk assessment, monitoring, logical access, and change management — which together constitute the Security category. The other four categories, Availability, Processing Integrity, Confidentiality, and Privacy, are additive: each contributes its own supplemental criteria on top of the Common Criteria baseline (Availability adds 3 criteria under the A-series, Confidentiality adds 2 under the C-series, Processing Integrity adds 5 under the PI-series, and Privacy adds roughly 8 P-series categories covering notice, choice, collection, and disposal). A company scopes its report by choosing which of the four optional categories apply, then an auditor tests the combined control set over an observation period.
Why is Security the only mandatory criterion?
Security is mandatory because the AICPA treats it as the baseline without which the other four categories are meaningless — you can't meaningfully attest to availability or confidentiality of a system that lacks basic access controls. Every SOC 2 report, Type I or Type II, must include the Common Criteria; there is no version of SOC 2 that skips it. This is also why vendors and auditors alike often shorthand "SOC 2" to mean "Security" scope only — a large share of first-time SOC 2 reports, particularly from early-stage SaaS companies pursuing their first enterprise deal, cover Security alone because it satisfies the majority of vendor security questionnaires without the added evidence burden of the other four categories.
When should a company add Availability, Confidentiality, Processing Integrity, or Privacy?
The right answer is to add a category when a customer commitment or regulatory obligation depends on it, not by default. A few concrete patterns show up repeatedly:
- Availability gets added when a company sells uptime SLAs — for example, a company offering a contractual 99.9% uptime commitment should expect enterprise customers to ask for Availability-scoped SOC 2 evidence covering capacity monitoring, incident response, and disaster recovery testing.
- Confidentiality gets added when a vendor handles data under NDA or contractual confidentiality terms beyond normal privacy law — common for B2B SaaS companies processing another company's source code, financial data, or trade secrets, which is exactly the profile of software supply chain and AppSec vendors.
- Processing Integrity gets added when the system's output has to be provably complete, accurate, and timely — payment processors, billing platforms, and healthcare claims systems are the classic examples, since PI criteria (PI1.1 through PI1.5) focus on whether data is processed correctly, not just protected.
- Privacy gets added when the company collects personal information and wants SOC 2 to cover notice-and-consent practices specifically — though in practice, many companies handling PII in the U.S. rely on Security plus applicable state or federal privacy law instead of adding the full Privacy category, because the ten Generally Accepted Privacy Principles behind it are extensive to operationalize.
Adding categories you don't need is a common first-audit mistake: each additional category adds evidence requests, sampling, and auditor testing hours, and Type II observation periods (commonly 3, 6, or 12 months) apply to every in-scope control, not just Security.
How do Type I and Type II reports differ under the Trust Services Criteria?
A Type I report attests that controls were suitably designed as of a single point in time, while a Type II report attests that those same controls operated effectively across an observation window — typically 6 to 12 months for a first audit and often shortened to 6 months for annual renewals once a program is mature. Enterprise procurement teams overwhelmingly ask for Type II specifically because Type I says nothing about whether a control actually ran; a company can pass Type I with a written access-review policy that was never executed once during the period. The Trust Services Criteria themselves don't change between Type I and Type II — the same CC-series, A-series, C-series, PI-series, or P-series criteria apply — what changes is the rigor of testing: a Type II auditor pulls samples of access reviews, change tickets, and vulnerability scan results from across the entire period rather than checking that a policy document exists.
How does Secureframe help teams map controls to the Trust Services Criteria, and where does that stop short?
Secureframe, along with similar GRC and compliance automation platforms, helps by continuously syncing cloud infrastructure, HR, and identity provider data to pre-built control templates mapped against Common Criteria and the four optional categories, which cuts down the manual spreadsheet work that used to define SOC 2 prep. That's a real improvement for controls like access provisioning (CC6 series) or vendor risk tracking (CC9.2), where the underlying evidence lives in systems like Okta, AWS IAM, or an HRIS with clean APIs to poll.
Where that model runs into limits is evidence for controls that live inside the software build and release process rather than infrastructure configuration — things auditors increasingly ask about under change management (CC8.1) and monitoring (CC7.1): what dependencies shipped in a given release, whether a build artifact matches its source, and whether a vulnerability introduced by a third-party package was detected before or after deployment. A GRC platform can confirm that a code review policy exists and that pull requests were approved; it generally can't attest to what's actually inside the compiled artifact, container image, or dependency tree that policy was meant to govern. For software supply chain-heavy organizations — which increasingly includes any company shipping containerized services or consuming open-source dependencies at scale — that gap between "policy evidence" and "artifact evidence" is exactly where audits stall or where auditors issue exceptions during Type II testing.
How Safeguard Helps
Safeguard generates the artifact-level evidence that closes the gap left by policy-and-config-focused compliance tooling, mapped directly to the Trust Services Criteria that reference change management, monitoring, and vendor risk. Continuous SBOM generation and dependency provenance tracking give auditors concrete evidence for CC8.1 (change management authorization) and CC9.2 (vendor and third-party risk management) — not a policy statement, but a record of exactly which components shipped in which release and where they came from. Build attestation and signing verification support CC7.1 and CC7.2 by demonstrating that security-relevant changes to artifacts are detected and that what deployed matches what was reviewed.
For companies scoping Confidentiality or Processing Integrity because they handle sensitive source code, SBOMs, or payment-adjacent data, Safeguard's tenant-isolated evidence trail gives auditors something concrete to sample against, rather than a policy document asserting the control exists. If you're preparing for a SOC 2 Type II examination and your auditor is asking questions your GRC platform's control templates weren't built to answer — particularly around software supply chain risk, dependency provenance, or build integrity — reach out to our team to see how Safeguard's evidence maps to your specific Trust Services Criteria scope.