On March 31, 2024, PCI DSS v3.2.1 was officially retired and PCI DSS v4.0 became the only version the PCI Security Standards Council accepts for assessments. A second wave of "future-dated" requirements, including many of the software security controls in Requirement 6, becomes mandatory on March 31, 2025. For merchants, acquirers, processors, and service providers, this is the largest rewrite of the standard since 2006, and the expansion into software inventory, bespoke software, and scripts on payment pages creates new obligations that cannot be met with a traditional SAST-only program. This article walks through the specific articles and sub-requirements, jurisdictional enforcement model, and penalty exposure, then maps Safeguard's controls to each obligation.
What Changed Between PCI DSS 3.2.1 and 4.0?
PCI DSS 4.0 reorganizes Requirement 6 around "bespoke and custom software" and introduces a customized approach where entities can document how their compensating controls meet the stated objective. The biggest shifts are Requirement 6.3.2, which demands a maintained inventory of bespoke and custom software including third-party components, Requirement 6.4.3 covering payment-page script integrity, Requirement 11.6.1 tamper-detection on payment pages, and Requirement 12.3.4 which requires a review of hardware and software technologies in use at least once every 12 months. The Council published v4.0 in March 2022 and v4.0.1 in June 2024 as a clarification release; the substantive requirements did not change.
Which Requirements Are Future-Dated to March 31, 2025?
Several controls were treated as "best practice" until March 31, 2025 and then become mandatory. These include 6.3.2 (component inventory), 6.4.3 (authorized scripts on payment pages), 11.6.1 (change-and-tamper detection), 12.3.1 (targeted risk analyses), and 8.3.6 (minimum 12-character passwords for user accounts with access to the CDE). For any QSA assessment dated April 1, 2025 or later, failing to produce evidence for these controls will produce a "Not in Place" finding. Merchants self-assessing via SAQ A, SAQ A-EP, and SAQ D must answer the same questions when the future-dated controls apply to their environment.
How Does Requirement 6.3.2 Change Software Inventory Obligations?
Requirement 6.3.2 requires "an inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software" that is maintained and used to facilitate vulnerability and patch management. The Council's guidance is explicit that this inventory should include the name, version, and source of each third-party component — effectively requiring an SBOM-equivalent artifact. A spreadsheet exported from a package manager is not sufficient when the assessor asks how the inventory is kept current between releases. The inventory also feeds Requirement 6.3.3, which obliges entities to apply critical-severity patches within one month and other applicable vendor-supplied patches within an appropriate time frame.
What Does Requirement 6.4.3 Mean for Payment-Page Scripts?
Requirement 6.4.3 targets Magecart-style skimming by requiring entities to manage scripts that are loaded and executed in the consumer's browser on payment pages. Three controls must be in place: a method to confirm each script is authorized, a method to assure the integrity of each script, and an inventory of all scripts with written justification for why each is necessary. The FAQ #1588 from the PCI SSC clarifies that this applies to all scripts on the payment page regardless of origin — first-party, third-party tag managers, analytics, and chat widgets are all in scope. Subresource Integrity (SRI) is one accepted integrity mechanism but only when combined with a tamper-detection process.
What Are the Jurisdiction and Penalty Implications?
PCI DSS is enforced contractually by the card brands — Visa, Mastercard, American Express, Discover, and JCB — rather than by statute in most jurisdictions, but penalty exposure is still material. Visa's Global Compliance Validation program can levy fines of USD 5,000 to USD 100,000 per month against acquirers for merchant non-compliance, and Mastercard's Account Data Compromise program can add USD 100,000 per incident plus fraud recovery and forensic costs. In the event of a breach, non-compliance at the time of the incident typically elevates the merchant from Tier 4 to Level 1 requirements and triggers mandatory PCI Forensic Investigator (PFI) engagement. Several U.S. states, including Nevada (NRS 603A.215) and Washington (RCW 19.255), incorporate PCI DSS into state law, which converts contractual obligations into statutory duties.
How Should Teams Evidence Software Supply Chain Controls During an Assessment?
QSAs are being trained to ask for three artifacts: the current bespoke-and-custom software inventory, evidence that the inventory is refreshed on each release (pipeline logs are typical), and evidence that third-party components are evaluated against the vulnerability management timelines in Requirement 6.3.3. For scripts on payment pages, assessors expect a mechanism diagram, a signed inventory with justifications, and sample evidence from production showing the authorization and integrity checks executing. "We use our CDN" is not a response that closes the finding.
How Safeguard Helps
Safeguard generates and maintains the CycloneDX SBOM that satisfies the 6.3.2 inventory requirement, automatically refreshed on every build so evidence matches the production artifact. Reachability analysis and Griffin AI prioritize the vulnerability remediation work required under 6.3.3 by filtering out components whose vulnerable functions are not invoked, which keeps the one-month clock focused on real exposure. TPRM workflows track third-party script vendors for 6.4.3 with attestations and change detection, and policy gates block any build that introduces an unauthorized component or a critical CVE. The PCI DSS compliance mapping in Safeguard links each control to the evidence store QSAs request, shortening the assessment cycle from weeks to days.