Ask a compliance lead how many times she’s answered “what’s running in your software” this quarter. PCI wants it in one format. SOC 2 wants a different export. The ISO surveillance auditor wants a third version. NIST wants a fourth, for SSDF attestation. Same question, four spreadsheets, and at least one of them is already stale by the time it lands on someone’s desk.
One SBOM scan can satisfy the software inventory requirement in PCI DSS 4.0.1, SOC 2, the proposed HIPAA Security Rule, and NIST’s Secure Software Development Framework (SSDF, SP 800-218). All five are essentially asking the same question: what’s in your software, and is any of it vulnerable?
An SBOM (Software Bill of Materials), a machine-readable list of every component in a piece of software, generated in a standard format like SPDX or CycloneDX can answer that question. The simplest way to start is with our open source scanner, Syft, that generates one from a container image or filesystem in seconds. Then Grype can check that list against known vulnerability databases. The result is a single source of truth that different auditors can query various different ways, instead of generating the same document over and over and drifts apart the moment someone ships a patch.
Here’s what each framework actually requires, as of August 2026, including which deadlines already passed and which are proposals at this moment.
PCI DSS 4.0.1: Requirements 6.3.2 and 11.3.1.1
PCI DSS 4.0.1 replaced 4.0 on December 31, 2024, and requires a maintained inventory of bespoke, custom, and third-party software components under Requirement 6.3.2. Requirement 11.3.1.1 ties that inventory to ongoing vulnerability management. This was scored as a best practice until March 31, 2025. After that date, QSAs treat it as a hard requirement, not a recommendation.
The standard doesn’t mandate SPDX or CycloneDX specifically. It just requires the inventory to exist and stay current, which is the part manual spreadsheets fail at first.
Learn more about the critical role of SBOMs in PCI DSS 4.0 compliance.
ISO/IEC 27001:2022: Annex A 5.9 and 8.8
The three-year grace period to transition from ISO 27001:2013 to the 2022 revision closed on October 31, 2025. Certificates that didn’t make the switch are no longer valid.
Annex A 5.9 (inventory of information and other associated assets) replaced the old asset management control. Annex A 8.8 (management of technical vulnerabilities) depends on 5.9 being current: you can’t triage a vulnerability in a component you don’t know you’re running.
An SBOM is the mechanism that keeps 5.9 accurate enough for 8.8 to mean anything.
SOC 2: CC7.1 and CC7.2
SOC 2 doesn’t name SBOMs by name, and we won’t pretend it does. Auditors currently treat dependency management as supporting evidence for secure SDLC practices, not a checkbox with its own line item.
That said, CC7.1 and CC7.2 both expect an ongoing process for detecting and monitoring vulnerabilities across your asset inventory. An SBOM is the fastest way we’ve seen teams satisfy that expectation with evidence an auditor can actually verify, rather than a policy document describing a process nobody follows.
HIPAA: where the proposed Security Rule actually stands
This one’s still a proposal, not law, and we want to be precise about that distinction.
The Department of Health and Human Services published a Notice of Proposed Rulemaking on January 6, 2025. The comment period closed March 7, 2025. The draft would make encryption and multi-factor authentication mandatory (currently just “addressable”), and add a 72-hour incident reporting window.
OCR had targeted spring 2026 for a final rule. That date passed with nothing published, and there’s no confirmed timeline for when, or if, a final rule ships. If you’re a covered entity or business associate, none of this is enforceable yet. Build toward it anyway, because the direction of travel is clear even if the date isn’t.
NIST SSDF (SP 800-218): what changed after EO 14306
Federal RFPs increasingly ask vendors for SSDF attestation alongside an SBOM, and the mechanics of that attestation changed in 2025.
Executive Order 14306, signed in June 2025, removed CISA’s role as the central validator of vendor attestations and struck the associated Federal Acquisition Regulation update. The practical effect: the burden shifted to vendors to hold their own audit-ready proof of SSDF conformance, rather than routing it through a central government review.
NIST published a draft of SP 800-218 Revision 1 on December 17, 2025. Its public comment period closed January 30, 2026. Version 1.1 remains the version vendors are actually held to today.
Framework quick reference
| Framework | Control(s) | Status as of August 2026 | SBOM required? |
|---|---|---|---|
| PCI DSS 4.0.1 | 6.3.2, 11.3.1.1 | Mandatory since March 31, 2025 | Effectively yes |
| ISO/IEC 27001:2022 | Annex A 5.9, 8.8 | Mandatory since October 31, 2025 transition deadline | Supports the requirement, not named directly |
| SOC 2 | CC7.1, CC7.2 | Current, ongoing | Optional, but common evidence |
| HIPAA Security Rule (proposed) | Encryption, MFA, 72-hr reporting | NPRM only, not finalized | Not required (no final rule yet) |
| NIST SSDF (SP 800-218) | Full framework, v1.1 | Rev 1 draft in comment through Jan 30, 2026 | Expected alongside attestation |
What this looks like when it’s not a spreadsheet
A few Anchore customers have already put this to the test, in frameworks adjacent to the ones above.
Mattermost builds a secure collaboration platform for defense and critical infrastructure customers. By enforcing NIST 800-53 out of the box through Anchore Enterprise, the team replaced a noisy, manual scanning process with a policy-driven workflow, and is now positioned for the DISA STIG requirements its regulated customers will demand next.
Cisco Umbrella had to hit FedRAMP, FIPS, STIG, and EO 14028 compliance for its entire GovCloud deployment on a deadline measured in weeks, not quarters. Anchore Enterprise met all six FedRAMP vulnerability scanning requirements within that window.
Sabel Systems runs a DevSecOps pipeline for Department of Defense missions, with a team of 10 supporting over 100 developers. Vulnerability review dropped from 2 weeks to 3 days, a 75% reduction, while the team maintained zero critical vulnerabilities across multiple IL5 environments and moved toward ATO.
ModuleQ is an enterprise AI copilot vendor operating inside customer-controlled tenants in financial services, a sector where 25,000 new vulnerabilities landed in 2023 alone. Anchore Secure cut the team’s vulnerability management time by 80%.
None of these four are a direct ISO 27001 or SOC 2 case study but what they show is the same underlying mechanic (one accurate inventory, checked continuously, mapped to whatever control an auditor asks about) working at DoD, federal, and financial-services scale. That’s the mechanic ISO 27001, SOC 2, PCI DSS, and HIPAA all lean on too as well.
FAQ
Does having an SBOM make you PCI DSS compliant?
No. It satisfies the inventory piece of Requirements 6.3.2 and 11.3.1.1. PCI DSS 4.0.1 has over 300 other requirements an SBOM doesn’t touch.
Is an SBOM required for SOC 2?
Not by name. Auditors accept it as strong evidence for CC7.1 and CC7.2’s vulnerability monitoring expectations, but SOC 2’s own criteria never use the term “SBOM.”
What’s the ISO 27001:2022 transition deadline?
October 31, 2025. It already passed. Certificates still on the 2013 version are no longer valid.
Is the HIPAA Security Rule update enforceable right now?
No. It’s a proposed rule (NPRM published January 6, 2025) with no confirmed final rule date as of August 2026.
What changed for NIST SSDF attestation in 2025?
Executive Order 14306 removed CISA’s central validation role in June 2025. Vendors now hold their own audit-ready proof of SSDF conformance instead of routing attestation through a central government review.
If you’re mapping one inventory across any of these frameworks right now, then talk to us and we are happy to demo our current product capabilities.
