PCI DSS 6.3.2 asks you to keep an inventory of bespoke and custom software and the third-party components incorporated into it, so vulnerability and patch management can work. The standard does not prescribe a format. A useful inventory lists each application, its components, versions, owners and where it runs. This is not legal advice.
What the text says
The SAQ D wording: "An inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software is maintained to facilitate vulnerability and patch management." It was marked a recommended practice until 31 March 2025, after which it is required and must be fully considered in an assessment. The expected testing is to examine documentation and interview personnel.
The purpose clause is the guide: if the list cannot answer "are we exposed to this new vulnerability?" quickly, it is not doing its job.
Fields worth recording
| Field | Why it helps |
|---|---|
| Application name and owner | Who patches it |
| Repository or source location | Where to look |
| Component name | Match to advisories |
| Component version | Decide if affected |
| Direct or transitive | Know how to upgrade |
| Where deployed | Prioritise payment path systems |
| License | Optional, but often collected at the same time |
| Date last reviewed | Show the list is maintained |
These columns are a suggestion, not a requirement of PCI DSS.
How to keep it current
- Generate the inventory from build files and lockfiles instead of typing it.
- Regenerate on every release.
- Store each version so you can show what shipped on a given date.
- Link the inventory to your ranking process in 6.3.1.
- Review it at least every time scope changes.
A software bill of materials (SBOM) is one common format for this. Our post on how PCI DSS meets SBOM requirements covers the link in more depth.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how each component is listed.
Quick check
Does 6.3.2 require an SBOM?
No format is named in the SAQ D text. An SBOM is one way to produce the inventory.
Do commercial off-the-shelf products belong on the list?
6.3.2 targets bespoke and custom software and the third-party components in it. Other products are covered by 6.3.1 and 6.3.3 for vulnerabilities and patches.
On Safeguard: SBOM and dependency scanning produces a component inventory per repository that you can export. Try the free scan at gold.safeguard.sh/scan.
Sources
Wording is from v4.0. Confirm in the current version.
Last reviewed: 19 October 2026.
