PCI DSS Requirements 6.4.3 and 11.6.1 : Explained: Securing Your Payment Page Scripts

Every time I sit down for a PCI compliance audit these days, there's one conversation that comes up almost without fail — client-side script security. Not firewalls, not encryption keys, not even network segmentation. Scripts. The small bits of JavaScript sitting on a checkout page that most development teams have never really inventoried, let alone controlled.

That's exactly the gap PCI DSS Requirements 6.4.3 and 11.6.1 were written to close. Both became mandatory on March 31, 2025, and I can tell you from first-hand PCI QSA audit experience that they're still catching organisations off guard well into 2026 — mostly because teams assume “we use a payment gateway, so this doesn't apply to us.” That assumption is usually wrong, and it's one of the first things I correct during scoping calls.

Why These Two Requirements Exist

Payment breaches used to mean someone broke into a server. That's changed. Attacks like the Magecart-style incidents against British Airways and Ticketmaster didn't touch backend infrastructure at all — they compromised a single third-party JavaScript library loading on the checkout page. The malicious script sat quietly in the browser, reading card numbers as customers typed them, and sending that data straight to the attacker.

No firewall alert. No server log entry. Nothing a traditional PCI DSS audit would have caught under the older version of the standard. The PCI Security Standards Council responded with 6.4.3 and 11.6.1, and honestly, it's one of the more sensible additions in PCI DSS v4.0. It shifts attention to where a lot of modern payment fraud actually happens — the browser, not the backend.

Breaking Down Requirement 6.4.3: Script Authorisation, Integrity, and Inventory. Requirement 6.4.3 asks a fairly simple question: do you actually know what scripts are running on your payment page? Not “roughly,” but with documentation. In practice, this means three things I check for during every assessment:

• Authorisation — you need a method to confirm every script loading on the payment page is approved to be there. That usually means a whitelist with URLs, hash values, and a stated business reason for each one.

• Integrity — you need a way to verify scripts haven't been silently altered. Sub-resource Integrity (SRI) tags and Content Security Policy (CSP) headers are the most common technical controls I see implemented, though neither is sufficient on its own without ongoing monitoring.

• Inventory and justification — a written record of every script, including third-party analytics tags, chat widgets, marketing pixels, and payment SDKs, with a documented reason each one is there. What surprises most clients during a PCI compliance audit is how many scripts they didn't know existed.
  
  Marketing teams add a tracking pixel, a support team installs a chat widget, and six months later nobody remembers who approved what. That untracked sprawl is precisely what 6.4.3 exists to eliminate.
  

Breaking Down Requirement 11.6.1: Detecting Unauthorised Changes

If 6.4.3 is about knowing what should be on the page, 11.6.1 is about catching what shouldn't be. This requirement mandates a mechanism that detects and alerts on unauthorised modifications to payment page scripts and to security-relevant HTTP response headers.

The keyword here is alerting. A monthly manual review doesn't meet the bar. Auditors — myself included — expect evidence of near real-time or at minimum, weekly automated monitoring, with a documented escalation path when something changes unexpectedly. I've seen organisations fail this specific control during a PCI QSA audit not because they lacked a tool, but because nobody could show me what happened after an alert fired. Detection without a response process isn't compliance; it's just noise.

Who Actually Needs to Worry About This

This is where scope gets misunderstood constantly, so let me be direct about it. PCI DSS distinguishes between a payment page and a payment form. A payment page is the entire webpage where the transaction happens. A payment form is the specific embedded element collecting card data.

If your checkout is fully redirected to a third-party processor's hosted page, you're largely outside the scope of these two requirements. If you're embedding a payment form through an iframe — Stripe Elements or Adyen's hosted fields, for example — you may still carry partial responsibility depending on how that iframe is implemented. And if you host or control the payment form directly on your own domain, you are squarely in scope, full stop.

Organisations completing SAQ A-EP or a full Report on Compliance (RoC) through SAQ D are required to fully implement and validate both requirements. This is one of the first scoping conversations I have with any new client — because getting this wrong either creates unnecessary compliance burden or, worse, leaves a genuine gap unaddressed.

What a PCI Qualified Security Assessor Actually Looks For

During an on-site or remote PCI DSS audit, I'm not just asking whether a tool is installed. I'm asking for evidence — the script inventory document itself, change logs from the monitoring tool, sample alerts and how they were triaged, and interviews with whoever owns the payment page to confirm they understand the process, not just the checkbox.

A PCI-certified assessor will also want to see this tied into your broader change management process. If a developer pushes an update to the checkout page next month, is there a step in that workflow that re-validates the script inventory? If the answer is no, that's a finding, regardless of what monitoring tool you've purchased.

Common Mistakes I See During PCI DSS Audits

A few patterns repeat across almost every engagement I've worked on:

Teams confuse having a Content Security Policy with having compliance. CSP is one layer, not the whole answer — it restricts what can load, but doesn't inherently generate the audit trail 11.6.1 requires.

Third-party scripts get overlooked entirely. Payment gateway widgets, fraud detection tags, and A/B testing tools are frequently missed during inventory exercises because nobody considers them “payment-related,” even though they load directly on the checkout page.

Alerting exists, but ownership doesn't. Tools fire notifications into a shared inbox nobody monitors. During a PCI compliance audit, that's functionally the same as having no monitoring at all.

Documentation is created right before the audit instead of maintained continuously. PCI DSS 4.0 pushes hard toward continuous compliance rather than annual scrambling, and 6.4.3/11.6.1 are a good example of why — script environments change weekly, sometimes daily.

How to Get Ahead of This Before Your Next Assessment

If you're preparing for an upcoming PCI compliance audit, start with a genuine script inventory — every script on every page that touches cardholder data, not just the ones your development team remembers offhand. Pair that with CSP and SRI as baseline technical controls, then layer in a monitoring solution that generates auditable alerts, not just dashboard notifications.

From there, build the process piece: who reviews alerts, how fast, and what the escalation path looks like when something unexpected changes. That process documentation is often the difference between a clean PCI QSA audit and a finding that delays your Attestation of Compliance.

Working with experienced PCI QSA services early — during the gap assessment stage rather than right before formal validation — tends to save organisations significant remediation time. PCI DSS QSA companies that specialise in e-commerce and payment environments will typically flag script-related gaps within the first scoping session, because it's become one of the most common findings across the industry since the requirement went mandatory.

At Accorp Partners, this is one of the areas our team spends the most time on during PCI DSS readiness assessments, simply because so few organisations arrive with a complete script inventory already in place.

Frequently Asked Questions

Q: What is PCI DSS Requirement 6.4.3?
It requires businesses to manage every script running on their payment page by confirming authorisation, verifying integrity, and maintaining an inventory with a written justification for each script.

Q: What is PCI DSS Requirement 11.6.1?
It requires a mechanism that detects and generates alerts for any unauthorised changes to payment page scripts or security-relevant HTTP headers.

Q: Do these requirements apply to businesses using a hosted payment page?

If your checkout is fully redirected to a third-party processor, you're generally outside the direct scope of 6.4.3 and 11.6.1. If you host or embed any part of the payment form yourself, you likely remain in scope.