SOC 2 Type II remains the default trust signal for SaaS vendors selling into mid-market and enterprise buyers, and the 2022 revision of the Trust Services Criteria is now the operative standard for every audit period beginning after December 15, 2025. The bar has moved meaningfully on third-party risk and software supply chain controls, and startups treating SOC 2 as a checklist exercise will find their reports flagged with qualifications they did not see coming. This post is a working guide to what has actually changed and what auditors are asking for in 2026.
The framing matters: SOC 2 is not a security standard, it is an attestation against criteria your service organization commits to. The Type II report covers an observation window, typically six to twelve months, during which your controls must operate consistently. The newer criteria pull supply chain hygiene into the same evidentiary discipline as access reviews and change management, which is a category shift many startups have not absorbed.
What changed in the 2022 TSC revision?
The 2022 revision tightened the language in CC2.3, CC3.4, CC9.2, and several supplemental criteria to require explicit consideration of vendor and software supplier risk. CC9.2 in particular now expects the service organization to identify, assess, and manage risks arising from its vendors and business partners on an ongoing basis, with documented criteria for onboarding and continued use. Auditors in 2026 are reading this to include open source dependencies and the broader software supply chain, not just contracted SaaS vendors.
In practice this means your SOC 2 evidence file needs to show a recurring process for evaluating the software components you ship, not just the cloud providers you contract with. The expectation is parity: if you assess your IdP vendor annually, you should be assessing your critical open source dependencies on a comparable rhythm. Audit teams from the larger firms have moved fast on this interpretation, and smaller boutique auditors are following within one or two cycles.
How should a startup scope its first Type II?
Scope discipline is the single highest-leverage decision in your first SOC 2. The temptation is to include every system and every business process, which produces a sprawling audit and a six-figure invoice. The defensible alternative is to scope to the production service that buyers care about, the supporting infrastructure that touches customer data, and the engineering and operations functions that change those systems. Marketing, sales, and corporate IT generally belong outside the scope unless they touch the in-scope environment.
Pick your trust services criteria deliberately. Security is mandatory. Availability is the second most common selection and is usually expected by enterprise buyers. Confidentiality is appropriate when you handle non-public business data under NDA. Privacy and Processing Integrity tend to be over-scoped for early-stage startups and are best deferred unless a specific buyer requires them. The cost difference between two criteria and five criteria is substantial and rarely justified before product-market fit.
What evidence patterns hold up under scrutiny?
The strongest evidence is generated as a byproduct of how the system actually operates. If access reviews run quarterly through a workflow tool that emits an immutable record, the evidence is the record. If your change management lives in pull requests with required approvals and CI gates, the evidence is the PR history and the gate configurations. Auditors are increasingly comfortable with this pattern and skeptical of evidence assembled retroactively into a spreadsheet, which they read as a signal of an unreliable control.
For supply chain controls specifically, the evidence patterns that work in 2026 are continuous SBOM generation in CI, recorded policy decisions on each build, and a vulnerability triage queue with timestamped state transitions. A monthly screenshot of a dashboard is not evidence of a continuous control. The auditor wants to see the operating cadence and exception handling over the full observation window, not a point-in-time snapshot.
Where do most first audits go sideways?
The most common qualification in 2026 audits is incomplete coverage of the change management criteria, CC8.1, specifically around emergency changes and infrastructure changes that bypass the normal pull request flow. Startups consistently document their application change process well and then have a separate, less rigorous path for Terraform changes, database migrations, or production hotfixes. Auditors test these paths specifically because they know where the gaps live.
The second common issue is vendor risk management documentation that names the vendors but does not show the assessment work. Listing Stripe, AWS, and Datadog in a spreadsheet is not a control. Showing that you reviewed each vendor's SOC 2 report, tracked the relevant complementary user entity controls, and remediated any gaps is a control. The same standard now applies to your software supply chain under the 2022 TSC revisions.
How Safeguard Helps
Safeguard converts the supply chain criteria in CC9.2 and the change management criteria in CC8.1 into evidence your auditor will accept. SBOMs are generated on every build and retained for the full Type II observation window, giving you a complete record of what your software contained at any point in time. Griffin AI runs reachability analysis on each build so the vulnerability triage queue is prioritized by exploitability, not raw CVSS. Policy gates in CI block builds that violate your stated criteria, producing a clean record of operating effectiveness. TPRM scoring of your dependencies and zero-CVE base images close the supplier risk loop your auditor is now testing.