PCI DSS 4.0 Requirement 6.3.2: Why Your SBOM Isn't Enough Without Runtime Context

Here’s a representative Quality Security Accessor (QSA)-style request we are seeing more often in  Payment Card Industry Data Security Standard (PCI DSS) 4.0 assessments of payment processors:

"Provide evidence that the 3,400 third-party components listed in your SBOM are evaluated for vulnerabilities relevant to your in-scope systems."

The team had the SBOM. They had a good one, generated on every build, attested, ready to hand over in CycloneDX or SPDX on request. What they didn't have was the rest of that sentence. The word "evaluated" was doing real work in there, and so was "relevant," and so was "in-scope." More than a year after the March 2025 deadline for many PCI DSS 4.0 evolving requirements, many teams still struggle to answer those three on demand.

That's the gap this post is about, along with what a defensible 6.3.2 answer actually looks like in a 2026 assessment binder.

The 6.3.2 Misread

Requirement 6.3.2, in plain English, says to maintain an inventory of custom software, plus the third-party software components incorporated into the custom software, in order to facilitate vulnerability and patch management.

Most teams read the first clause, generated an SBOM, and considered the requirement closed.

It's an understandable shortcut. The SBOM industry spent five years, through SolarWinds and Log4Shell and the U.S. Executive Order on software supply chain, telling the market that the bill of materials was the answer. By the time PCI DSS 4.0 arrived with a component-inventory requirement, SBOM tooling was the obvious off-the-shelf response.

What PCI DSS 4.0 Requirement 6.3.2 actually says:

But 6.3.2 doesn't end at "maintain an inventory." It ends at "to facilitate vulnerability and patch management." The inventory clause exists in service of the management clause, and QSAs are increasingly reading the requirement that way. They're asking for evidence of both halves, and the SBOM-only response runs out of road on the second one.

Why PCI DSS 4.0 Vulnerability Management Depends on Runtime Context"

Read 6.3.2 next to its neighbors and the picture changes.

Requirement 6.3.1 asks you to identify and risk-rank vulnerabilities using a process you define, prioritized by impact to your environment. Requirement 6.3.3 sets the remediation clock at one month for critical patches and a documented schedule for everything else. Requirement 11.3.1.1 closes the loop on the vulnerabilities that aren't critical or high, requiring a targeted risk analysis so nothing gets quietly ignored. And 11.3.1.2 now insists those internal scans be authenticated, which means they have to actually see what's running on the box.

Stitched together, the control family describes a workflow rather than a deliverable. Identify what you have (6.3.2). Find what's wrong with it (11.3.1). Rank it by risk to your environment (6.3.1). Justify the rest (11.3.1.1). Fix it on a clock (6.3.3).

The SBOM gets you to step one. That's necessary, but it doesn't get you to step five.

The word "manage" in 6.3.2's clause is doing real work. Managing 3,400 components means knowing which of them matter: what's loaded, what's reachable, what sits on a code path touching cardholder data, what's dormant inside a transitive dependency nobody has called in two years. Without that context, every CVE that drops turns into a fire drill against the full 3,400, when the actual live blast radius in your CDE is in the dozens.

QSAs have noticed. The questions are getting more specific.

CDE-in-Practice vs. CDE-on-Paper

The other thing that has changed is the architecture being assessed.

A payment processor in 2018 had a legible CDE. A handful of services inside a clear network boundary, traceable on a scope diagram with your finger. A payment processor in 2026 runs hundreds of microservices, asynchronous message queues, embedded SDKs in partner mobile apps, BaaS partners doing card issuance over API, and a feature flag system that can move a code path in or out of scope between two quarterly reviews.

The official scope diagram describes the CDE that was approved. The running system describes the CDE that exists. In our experience those two documents drift apart by twelve to eighteen months, which is long enough that any given quarterly assessment is, at the margin, working from a map that no longer matches the territory.

Runtime evidence is what reconciles them, answering questions the diagram can't:

• Which services actually loaded the jackson-databind artifact in the last 30 days?
• Of those, which run inside the CDE network zone?
• Of those, which executed the deserialization path the CVE actually exploits?

That last one is the question QSAs didn't used to ask. They're starting to.

Runtime Evidence vs. Static Scope Diagrams

If your 6.3.2 evidence is a static SBOM bolted to a static scope diagram, your audit defense is two snapshots that are quietly going stale at different rates. Runtime telemetry collapses them into a single current picture. It also happens to make 6.3.3 prioritization tractable, because you finally know which CVEs are theoretical and which are sitting on the hot path.

Here's the data point we keep finding in customer environments: across modern payment-stack repos, fewer than 1% of declared dependencies are actually loaded at runtime inside the CDE. One representative engagement, 10,000 declared dependencies, 37 loaded in the CDE. The remediation backlog those teams had been working from was 99% noise.

If you'd rather work through this against your own environment, we built a one-page PCI DSS 4.0 Runtime Readiness Checklist that mirrors the QSA questions in this post. Grab it here.

What QSAs Are Starting to Ask and Why

The shift in QSA posture isn't formal yet. The PCI SSC hasn't published prescriptive guidance on runtime evidence. But the pattern is visible across assessments we've reviewed in the last two cycles, and the questions are sharper.

A 2023-era QSA might have asked to see the SBOM and the vulnerability scan output and checked the box. A 2025–2026 QSA is asking for:

• Reachability evidence. It's no longer enough to confirm a library is in the build. The question is whether the vulnerable function is actually called by your code path. This is consistent with how 6.3.1 frames risk ranking. A vulnerability you can't reach is not the same risk as one you can.
• Load-time confirmation in the CDE. A list of libraries the running JVM, Node process, or Python interpreter actually loaded inside in-scope systems over the assessment window.
• Runtime call graphs touching sensitive data flows. Particularly for cryptographic libraries that handle PAN, or for serializers and parsers on the payment-input path. When a CVE drops in a crypto library, the QSA wants to know whether the affected code is on your hot path.
• Continuous evidence rather than point-in-time. 11.3.1.2's authenticated-scan requirement and the broader 11.3.1 cadence push assessors toward evidence that the program is operating continuously across the year, not produced specifically for the audit window.

The standard doesn't name any of these explicitly. They follow reasonably from what "facilitate vulnerability management" has to mean in a system that changes faster than the documentation.

A Practical Mapping: SBOM + Runtime = 6.3.2 Done Properly

Think about this as an evidence stack with two layers. The SBOM is the foundation. Runtime context is what makes the SBOM legible to a QSA.

What the SBOM gives you. A declared inventory of every direct and transitive dependency, with versions, licenses, and hashes, attested at build time and distributable to QSAs or partners on request. This satisfies the literal text of 6.3.2's first clause.

What runtime adds. An active inventory: which of those declared components were actually loaded into a running process inside the CDE during the assessment window, which ran code paths that touched cardholder data, and which are dormant (present in the binary but never executed). This is the evidence that lets you connect 6.3.2 to 6.3.1's risk ranking and 6.3.3's remediation clock.

What the combined evidence looks like in an assessment binder:

1. The SBOM for each in-scope application, regenerated on every build, with a chain of custody back to source.
2. A runtime-loaded-components report for each in-scope service covering the last 90 days, showing which of the declared components were observed in memory.
3. A reachability overlay for the current open CVEs against those services: which vulnerabilities are on a reachable code path, which are not, and the justification for any deprioritized findings. This is your 11.3.1.1 targeted risk analysis input.
4. A remediation log keyed off the reachable-and-loaded subset, with timestamps showing 6.3.3 clocks were met.

When a QSA asks you to evaluate 3,400 components for relevance to your in-scope systems, that's what you hand over. The SBOM on its own doesn't get you there. The SBOM plus the three artifacts on top of it does.

This is also the moment where most teams realize the SBOM-only program isn't producing audit-defensible evidence. It's producing a list that requires a manual interpretation layer the team doesn't have.

Three Steps Before Your Next PCI DSS 4.0 QSA Audit

If your next assessment is inside the next two quarters, three concrete moves you can make starting this week:

1. Reconcile CDE-in-scope services against your current architecture. Pull the deployment manifest, check it against the scope diagram, and write down the drift. The drift itself ends up being useful evidence of due diligence.
2. Instrument runtime collection on at least one in-scope service. You don't need to boil the ocean. One service over 30 days is enough to demonstrate the methodology to a QSA and to validate the loaded-vs-declared ratio in your own environment.
3. Generate a "components loaded in the CDE" report for your next quarterly review. Compare it to the SBOM. The delta is the conversation worth having internally before a QSA has it with you.

If that maps to the way your team is already thinking about 6.3.2, the PCI DSS 4.0 Runtime Readiness Checklist makes the first pass faster. It walks the same QSA questions in one page.

Download the PCI DSS 4.0 Runtime Readiness Checklist →

Or, if you'd like to see how UK payment and fintech teams are approaching PCI DSS 4.0 assessments, watch our webinar on building a defensible evidence binder for 2026.

Kodem helps fintech SaaS, wealth-tech, and lending platforms produce the runtime evidence modern procurement reviews demand. This piece is part of our 2026 series on the structural shifts reshaping AppSec in regulated industries.

References

1. Kodem Security. November 4, 2025. From Reachability to Reality: Proving Vulnerable Code was Executed & Exploited in Production. Kodem Security.
2. IISS. March 31, 2021. Lessons of the SolarWinds hack. IISS.
3. Security Standards Council. Qualified Security Assessors. Security Standards Council.

Security Standards Council. PCI Data Security Standard (PCI DSS). Security Standards Council.