The future-dated requirements in PCI DSS 4.0 became mandatory on March 31, 2025, and the 2026 assessment cycle is the first one in which QSAs are testing the full standard without transitional accommodations. The requirements that have generated the most assessment friction in our experience are the ones touching software supply chain, third-party service providers, and the customized approach for security controls. This post walks through what we have learned helping merchants and service providers pass their first full 4.0 ROCs.
PCI DSS 4.0 is structurally different from 3.2.1 in ways that affect how you build your evidence file. The customized approach allows you to meet a requirement through alternative controls if you can show the control objective is met, which is more flexible than the defined approach but requires substantially more documentation. Most organizations should default to the defined approach and reserve the customized approach for requirements where a clean fit is genuinely impossible.
Which 4.0 requirements actually changed the supply chain bar?
Requirement 6.3.2 mandates an inventory of bespoke and custom software, including third-party components, that are used in or by payment applications. The plain reading is that you need an SBOM equivalent for every component your payment software depends on, with the ability to identify the version in use at any given time. Requirement 6.3.3 extends this to vulnerability identification and risk-based response, with documented procedures and assigned roles.
Requirement 12.8 was reworked to require a documented list of third-party service providers, including a description of services provided and the PCI DSS requirements managed by each provider. The associated 12.9 requires written acknowledgments from each TPSP that they are responsible for the security of the cardholder data they touch. Where 3.2.1 allowed substantial latitude in how this documentation was maintained, 4.0 expects a current and complete register that the QSA can sample.
How are QSAs testing requirement 6.3.2 in practice?
QSAs in 2026 are testing 6.3.2 by sampling specific payment application builds and asking the assessed organization to produce the component inventory for that exact build. Producing a generic dependency list for the application as a whole is not sufficient; the inventory must be tied to a specific build artifact. The cleanest evidence pattern is an SBOM generated as part of the CI pipeline, signed or hashed, and stored with the build artifact in your registry.
The follow-on test is requirement 6.3.3, where the QSA picks a CVE that affects a component in the inventory and asks for the risk-based response. Acceptable responses include patching, mitigating compensating controls, or documented risk acceptance with executive sign-off. Unacceptable responses are silence, a backlog ticket with no triage, or an inventory that does not match what is actually deployed. The audit failure pattern is consistently a stale inventory that the operations team has not been keeping current.
What is the deal with the customized approach?
The customized approach lets an organization meet a requirement through an alternative control set, provided the control objective is met and the customized approach is documented in a Targeted Risk Analysis, scoped, tested, and reviewed annually. It is a useful escape valve for organizations with mature security programs that do not map cleanly onto the defined controls. For supply chain requirements specifically, the customized approach has been used to substitute continuous reachability-based scanning for the prescriptive vulnerability ranking in the defined approach.
The hidden cost is documentation burden. A customized approach control package typically includes the TRA, the control description, the testing procedure, the evidence sources, and the annual review. QSAs in 2026 are scrutinizing customized approach submissions carefully because the early implementations were uneven in quality. Reserve the customized approach for cases where the defined approach genuinely does not fit the architecture, not as a workaround for missing controls.
How does the targeted risk analysis fit in?
The Targeted Risk Analysis is a documented analysis required for each instance where the standard explicitly permits one, typically to justify the frequency of a recurring activity such as scanning, log review, or training. The TRA must consider the likelihood and impact of the relevant threats and document the rationale for the chosen frequency. QSAs are asking to see the TRA itself, not just a reference to it, and weak TRAs are now generating findings that did not exist in 3.2.1.
For supply chain controls, the relevant TRAs are typically the ones covering vulnerability scanning frequency and component inventory refresh frequency. The defensible TRA ties the frequency to the rate of change in the underlying system: a payment application with daily deploys needs more frequent inventory refresh than one that deploys quarterly. Generic TRAs that claim a frequency without showing the analysis are now being challenged.
How Safeguard Helps
Safeguard produces the build-tied SBOMs that requirement 6.3.2 expects and retains them across the full assessment period for QSA sampling. Griffin AI prioritizes the CVEs in those SBOMs by reachability and exploitation signal, which is the basis for the risk-based response that 6.3.3 requires. Policy gates in CI enforce the defined controls on every build, producing the operating effectiveness evidence QSAs sample. TPRM scoring of dependencies and third-party service providers feeds directly into the 12.8 and 12.9 register, and zero-CVE base images shrink the surface area your TRA has to defend. The result is a 4.0 evidence file built in the normal course of engineering work.