PCI DSS: inventory and monitor your payment page scripts
Since March 2025, PCI DSS 4.x enforces new requirements directly tied to your web attack surface: inventorying and authorizing the scripts running on payment pages, and detecting unauthorized changes. The standard's answer to e-skimming attacks — and a domain where continuous monitoring changes everything.
.svg)
PCI DSS 4.x at a glance
What changed with PCI DSS 4.x,
in three points
- The global standard for card data Any organization that stores, processes or transmits payment card data is concerned: e-commerce, retail, platforms, payment providers — across Europe and beyond.
- Two requirements target your payment pages Mandatory since 31 March 2025: requirement 6.4.3 mandates an inventory, authorization and justification of every script executed on payment pages; requirement 11.6.1 mandates a mechanism to detect unauthorized changes to those pages (checks at least weekly).
- The target: e-skimming These requirements answer Magecart-style attacks: a compromised third-party script silently exfiltrating card data straight from the customer's browser. The server is untouched; the page is not.
Where Purplemet fits
We observe what your payment pages actually run
Requirements 6.4.3 and 11.6.1 both raise the same prior question: do you know, at any moment, which scripts and technologies your exposed pages actually run? That is exactly what Purplemet observes — from the outside, the way an attacker or an assessor would.
- Script and technology inventory (requirement 6.4.3) Purplemet continuously inventories the technologies present on your exposed pages: scripts, JavaScript libraries, third-party tags, frameworks — and their versions. The inventory the standard requires stops being a hand-maintained document: it reflects what is actually served to your customers' browsers.
- Change detection (requirement 11.6.1) Every change in what your pages expose — a script added, a component modified, a version changed — is detected as it happens. An unauthorized third-party tag, an altered library: you know without waiting for the next weekly check or the next audit.
- Vulnerable component watch Beyond payment pages, PCI DSS expects vulnerability management across the perimeter. Purplemet continuously matches your exposed application inventory against published vulnerabilities (CVEs): you know the same day whether a component is affected.
- Scoping honestly Your PCI DSS scope is not limited to the pages you know about: a forgotten payment page, an exposed test environment, an inherited subdomain can silently enter it. Purplemet discovers what your organization actually exposes — and helps you draw an honest perimeter.
Common questions about PCI DSS and Web ASM
Can Purplemet validate my PCI DSS compliance?
No. Validation is the role of Qualified Security Assessors (QSA), and the quarterly scans the standard requires are performed by Approved Scanning Vendors (ASV), both listed by the PCI Security Standards Council. Purplemet is neither: it is a continuous monitoring tool that feeds several requirements of the standard — notably the payment page script inventory and change detection.
What do PCI DSS requirements 6.4.3 and 11.6.1 demand?
Requirement 6.4.3 mandates maintaining an inventory of all scripts executed on payment pages, with authorization and justification for each, and assurance of their integrity. Requirement 11.6.1 mandates a mechanism detecting unauthorized changes to those pages, with checks at least weekly. Both have been mandatory since 31 March 2025 and target e-skimming attacks. Their exact applicability depends on your acceptance channel — validate with your QSA.
What is e-skimming (Magecart)?
An attack in which a script loaded by your payment page — often a compromised but legitimate third-party component — captures card data directly in the customer's browser and exfiltrates it to the attacker. The server is not breached; the page's script chain is. Hence the requirement to inventory and continuously monitor what your pages actually execute.