PCI DSS 4.0.1 and SBOMs: A Guide to Controls 6.3.2 and 11.3.1.1

Updated 28 September 2026: the future-dated requirements of PCI DSS v4.x, including 6.3.2 and 11.3.1.1, have been mandatory since 31 March 2025, and PCI DSS v4.0.1 is the only active version of the Standard.

Why the 31 March 2025 deadline still matters

PCI DSS v4.0 was the first major update to the Standard in over a decade, and it added a lot of new requirements. Of the 64 new requirements, 51 were future-dated and became mandatory on 31 March 2025. PCI DSS v4.0.1, a limited revision published in June 2024, added clarifications and guidance but no new requirements.

• PCI DSS v3.2.1 is gone: the Council retired it on 31 March 2024 PCI Perspectives.
• Version 4.x added 64 new requirements; 51 were “future-dated” until 31 March 2025.
• Two of those controls, 6.3.2 and 11.3.1.1, implicitly require a living, searchable Software Bill of Materials (SBOM).
• Since 31 March 2025, assessors score them as required, so organizations need a production-grade SBOM management tool in place now.

Why SBOMs are pivotal for PCI compliance

Requirement 6.3.2: keep a complete software component inventory

PCI DSS 6.3.2 requires organizations to maintain an up-to-date inventory of all bespoke and custom software, including any third-party software components integrated into that custom software. In other words, for every in-house or custom application in the cardholder data environment, you need to know exactly what’s inside it – from custom-developed code to open-source libraries, APIs, runtime platforms, and other dependencies. This inventory is essentially a Software Bill of Materials for your in-scope applications. The goal is to facilitate vulnerability and patch management by ensuring no component is overlooked.

This was a new requirement in v4.0 and a best practice until 31 March 2025. Since then it has been required and must be fully considered during every PCI DSS assessment. By maintaining an SBOM for each custom application, organizations can quickly identify if a newly disclosed vulnerability (for example, in a popular open-source library like Log4j) is present in their environment, and then take action to remediate or patch it.

What does an SBOM for PCI DSS include? At minimum, it should list all custom applications and all components within those applications, whether first-party or third-party. This includes things like external libraries, frameworks, modules, APIs used, and even the underlying platforms or services the software relies on. The PCI DSS testing procedures for 6.3.2 make it clear that assessors will expect to see a documented inventory and will verify it against the software in use. In fact, testing procedure 6.3.2.a notes that “the inventory is used to identify and address vulnerabilities”, meaning it’s not enough to just catalog components – you must actively use this SBOM in your vulnerability management program. The SBOM should be kept current (e.g. updated when software is updated) and should be leveraged to track the patch status or known vulnerabilities of each component.

Implementation Tip: To comply with 6.3.2, organizations should establish a process (potentially using automated Software Composition Analysis tools) to generate and maintain SBOMs for all custom applications. Ensure that for each SBOM entry (each component) there is a mapped owner or process to monitor for vulnerabilities and apply updates. This could involve:

• Integrating SBOM generation into your build or deployment pipelines (so you always have an updated list of components for each build and release).
• Deploying tools to automate the monitoring of vulnerabilities and shifting responsibility to developers or security team members to review SBOMs feeds (e.g. CVE, OSV databases) regularly.
• Requiring your software suppliers to provide SBOMs for any third-party or open-source components they deliver, so you can include those in your inventory as well (PCI DSS expects you to include third-party components, which may require reaching out to vendors for information)

Requirement 11.3.1.1 – Addressing All Vulnerabilities from Scans

PCI DSS has long required regular internal and external vulnerability scans (Requirement 11.3.1 and 11.3.2). In PCI DSS 4.0, Requirement 11.3.1.1 is a new control that ensures a more comprehensive approach to scan results. In the Standard’s words, 11.3.1.1 requires that “all other applicable vulnerabilities (those not ranked as high-risk vulnerabilities or critical vulnerabilities according to the entity’s vulnerability risk rankings defined at Requirement 6.3.1)” are addressed based on the risk defined in the entity’s targeted risk analysis, with rescans as needed. Like 6.3.2, it has been required since 31 March 2025. This closes a potential gap where previously an entity might focus only on high-severity findings and neglect medium/low findings. Under 4.0, no discovered vulnerability can be simply ignored; even lower-risk issues need to be evaluated and addressed (through remediation or risk mitigation).

Where SBOM Studio fills the gap

• SBOM monitoring: A background job watches every component in every SBOM for newly published CVEs.
• Alert policies and Jira: Trigger alerts on KEV, EPSS, CVSS and severity thresholds, and open Jira tickets pre-filled with CVE, CVSS, EPSS and CWE details.
• Unified evidence Platform: VEX and VDP functionality lets you capture findings, adjust the risk based on your environment and stay audit ready.

Key points for 11.3.1.1 compliance:

• Develop internal processes to triage all vulnerabilities found in scans, not just critical ones. For example, define what remediation timelines are “appropriate” for medium and low findings, and perform a risk assessment if choosing to defer any fixes.
• Ensure that scan reports are tracked to closure. PCI DSS assessors will expect to see evidence that you review scan results and remediate or formally accept the risk of each finding.
• Use your SBOM and other tools to supplement vulnerability detection. If a component in your SBOM has a known vulnerability, treat it as if your scan found it – i.e. include it in your vulnerability management workflow. This aligns with the intent of 11.3.1.1 to leave no stone unturned.

By addressing all vulnerabilities (with priority and timing commensurate with risk), organizations reduce their attack surface and meet the stricter expectations of PCI DSS 4.0. In summary, requirement 11.3.1.1 reinforces that security teams can’t ignore “minor” vulnerabilities – these must be managed, and SBOM-driven visibility can help ensure nothing slips through the cracks.

Choosing the right SBOM platform checklist

PCI SSF and SBOM: The Software Security Framework’s Take

While PCI DSS 4.0 applies to entities handling card data (merchants, service providers), the PCI Software Security Framework (SSF) is a set of standards aimed at payment software vendors. It includes the Secure Software Standard (for security of payment applications) and the Secure SLC Standard (for the vendor’s secure development lifecycle). SBOM concepts feature prominently here as well, underscoring an industry-wide move toward transparency of software components.

In fact, the PCI Secure Software Standard requires vendors to inventory and manage their software components much like PCI DSS 6.3.2 does. For example, guidance for vendors building web-based payment software calls for maintaining an SBOM of all third-party and open source dependencies. This ensures that software developers track their libraries and frameworks and keep them updated against vulnerabilities. A compliance checklist for PCI Secure Software even explicitly lists: “Maintain a Software Bill of Materials (SBOM) to track all dependencies. Continuously monitor and update third-party libraries.”. The intention is that a payment application submitted for validation under PCI SSF should come with a full inventory of its components and evidence of vulnerability management for those components.

How SBOMs in SSF benefit PCI DSS entities: If you are an entity deploying a payment application that has been validated under PCI’s Secure Software Program, you should receive documentation from the vendor about the software’s components (effectively an SBOM) and known vulnerabilities. PCI DSS v4.0 even includes Appendix F to describe how using software developed per the PCI Secure Software Standard can help meet PCI DSS Requirement 6 controls. In other words, a PCI-validated payment software product is expected to adhere to secure design practices – including supply chain security – thereby assisting the entity in complying with requirements like 6.3.2. The Council is actively encouraging this synergy. For instance, at the 2024 PCI Community Meeting, a session titled “You Dropped a ‘BOM’ on me, baby…” was dedicated to the role of software BOMs and how the PCI SSF leverages them now and will in the future. This shows that going forward, SBOMs will likely become even more formalized in the PCI Secure Software Program.

For software vendors: Embracing SBOMs is not just about compliance but also market expectation. Vendors should build the capability to produce SBOMs for their products and share them with clients. Not only will this help your customers meet PCI DSS 4.0 (they can plug your SBOM into their 6.3.2 inventory and use it for their 11.3.1.1 vulnerability management), but it also demonstrates transparency and due diligence in your secure development practices. Many security-conscious customers now expect SBOMs as part of software procurement due to broader supply-chain initiatives and regulations.

Practical Tips for Implementation and Compliance

Implementing SBOM practices for PCI compliance may seem daunting, but it can be broken down into manageable steps. Here are some actionable insights for technical teams:

• Integrate SBOM generation into development workflows: Use build tools or CI/CD pipeline steps to automatically generate SBOMs (in formats like SPDX or CycloneDX) for each release of your custom software. This ensures your inventory (PCI DSS 6.3.2) is always up to date with minimal manual effort. Remember, PCI DSS doesn’t mandate a specific format or tool – use what best fits your environment, but ensure it captures all components.
• Centralize and maintain the inventory: Store the SBOMs or software inventory in a central repository or dashboard that the security team can access. Each entry in the inventory should ideally include details like component name, version, vendor/source, and whether it’s still supported. This will help in tracking patches and end-of-life status. Pro tip: Don’t forget to include “indirect” components like the runtime environment or OS if the software is dependent on them – they are part of the overall stack that needs vulnerability management.
• Link SBOM to vulnerability intelligence: Leverage vulnerability scanning tools and subscription feeds to map SBOM components to known vulnerabilities. Many software composition analysis tools can ingest SBOMs and alert you to CVEs affecting components. This addresses the spirit of both 6.3.2 and 11.3.1.1 by ensuring that even if a vulnerability wasn’t found in a live network scan, it’s identified via the SBOM. For every vulnerability identified, document how it was handled (patched, mitigated, or risk-accepted via a risk analysis) – this will be evidence for 11.3.1.1 that you “managed” the issue.
• Establish patching timelines and escalation: Define what constitutes high, medium, and low risk in your environment (if you haven’t already) and set internal SLA deadlines for fixing them. For example, you might adopt a policy like: critical vulns patched in <30 days, mediums in <60 days, lows in <90 days (or use a risk-based approach with sign-off if deviating). The key is to not leave lower-risk issues unaddressed indefinitely. This policy will support compliance with 11.3.1.1 and 6.3.3. Ensure your teams are aware of these timelines and there’s a tracking mechanism (e.g. a ticketing system) to follow up on all findings.
• Leverage PCI SSF-validated software when possible: If you procure third-party payment applications, consider those listed as PCI Secure Software validated. These vendors have committed to secure development practices. Ask them for an SBOM of their product and any guidance on known vulnerabilities or patch frequency. Using such software can help satisfy some of your PCI DSS requirements by inheritance – for instance, a vendor’s SBOM and vulnerability management practices can feed into your own compliance evidence.
• Train developers and stakeholders: Ensure that developers, DevOps, and security personnel understand the importance of the new SBOM requirement. They should be aware that an assessor will explicitly ask for the inventory of software components and will expect that it’s being used for vulnerability management, not just a paperwork exercise. Incorporate SBOM management into your secure coding training or PCI compliance training so everyone knows their role (this ties in with PCI DSS’s broader emphasis on roles and responsibilities in v4.0).

The transition period ended on 31 March 2025. If these processes are not fully in place yet, start by building SBOMs for your applications and integrating them with your vulnerability management workflow. If you’re a software vendor in the payments space, align with PCI SSF expectations now – it not only prepares you for potential future validation, but also makes your product more trustworthy to clients who must meet PCI DSS. The PCI Security Standards Council’s guidance and resource hub provide clarity on these new controls, and it’s clear that SBOMs are here to stay as a foundational element of software security compliance.

By approaching SBOM requirements as an opportunity to strengthen software governance, developers and cybersecurity professionals can both meet PCI DSS 4.0/SSF obligations and significantly reduce risk in their environments. In the end, an up-to-date SBOM coupled with diligent vulnerability management is a powerful tool to protect cardholder data in today’s complex ecosystem of software and services.