Not as a named requirement. SOC 2 reports are built on the Trust Services Criteria, which describe outcomes rather than specific documents. An SBOM is not what the auditor asks for by name, but it is a practical way to show you know what software you run and can react when a new vulnerability appears.
What SOC 2 asks for, and what it leaves to you
The AICPA publishes the Trust Services Criteria that SOC 2 examinations use. They are principles: for example, that you detect new vulnerabilities and respond to them. You choose the controls and the evidence. Auditors test the controls you describe. If your own description says you maintain an inventory of components, then the inventory becomes something they can test.
Confirm with your auditor what they expect, since practice varies.
Where an SBOM helps
| SOC 2 concern | How an SBOM supports it |
|---|---|
| Detecting newly discovered vulnerabilities | Gives scanners an exact component list to match against new advisories |
| Change management | A diff between SBOMs shows what dependencies changed in a release |
| Incident response | Answers "are we affected" quickly |
| Vendor and customer reviews | Something concrete to share when asked about components |
| Asset inventory | Covers software components as well as servers |
When you can skip it
If your product is a small service with a few direct dependencies, and your scanner reads lockfiles directly and keeps dated results, you may already have the evidence you need. An SBOM adds value mainly when you ship to customers, run many services, or answer questionnaires that ask for one.
Steps if you decide to adopt one
- Generate it in the build, in CycloneDX or SPDX, and store it per release.
- Include transitive dependencies with exact versions.
- Reference it in your vulnerability management policy, so it is part of the described process.
- Keep the SBOMs as evidence, dated and tied to releases.
- Do not promise more than the process delivers. If you refresh monthly, say monthly.
How to word it in your policy
If you adopt an SBOM, describe it in plain terms. For example: an SBOM is generated for each release, stored with the release record, and used to check for newly published vulnerabilities. Then make sure the practice matches the sentence. A Type 2 period will test whether it ran each time, so a promise of every release means every release.
Quick check
Will an auditor fail me for not having an SBOM?
The criteria do not name one, so not having it is not a failure by itself. Failing to follow the process you described would be.
Is an SBOM evidence for CC7.1?
It can support the inventory side. The detection side still needs scan results, dated across the period, and records of what you did about them.
Where Safeguard fits
Safeguard's SBOM and dependency scanning generates inventories, and its compliance and evidence automation keeps dated results with related controls. Try a free scan.
Sources
- AICPA, 2017 Trust Services Criteria with revised points of focus (2022), aicpa-cima.com (criteria are principles established by the Assurance Services Executive Committee).
Last reviewed: 19 October 2026.
