PCI DSS v4.0 adds two requirements aimed at the part of an e-commerce transaction most merchants have never had to control: the customer's browser. Requirement 6.4.3 says you must keep an inventory of every script that runs on your payment pages, justify why each one is there, confirm each is authorized, and assure its integrity. Requirement 11.6.1 says you must detect and alert on unauthorized changes to the HTTP headers and content of payment pages as the browser receives them, at least every seven days or at a frequency set by a targeted risk analysis.

Both are best practice until March 31, 2025, when they become mandatory. They also appear in SAQ A and SAQ A-EP, so they reach merchants who have outsourced card handling. Fourteen months sounds like plenty of time, but building a script inventory and a monitoring process takes longer than most teams expect.

Why do payment page scripts need their own requirements?

A typical checkout page loads far more code than the developers who built it wrote. Analytics, tag managers, A/B testing tools, chat widgets and fraud detection services all arrive as scripts, often from third parties, and those scripts frequently pull in more scripts from fourth parties.

Every one of those scripts runs with the same access to the page as your own code. A malicious or modified script can read what a customer types into the card fields and quietly send it somewhere else. The change might come from a compromised third-party script host, an unauthorized edit to your site, or a tag manager configured by someone outside the change process.

Server-side controls don't see any of this. The card data leaves from the customer's browser, not from your servers, which is exactly why the Council wrote requirements that look at the page as the browser receives it.

What does requirement 6.4.3 require?

Requirement 6.4.3 applies to all payment page scripts that are loaded and executed in the consumer's browser. They must be managed as follows:

  • A method is implemented to confirm that each script is authorized.
  • A method is implemented to assure the integrity of each script.
  • An inventory of all scripts is maintained with written justification as to why each is necessary.

The applicability notes make clear this covers scripts loaded from your own environment and scripts loaded from third and fourth parties. A script you don't know about is still in scope.

The inventory and written justification

The inventory is the foundation for everything else. For each script, record where it loads from, who owns it internally, what it does, and why the payment page needs it. That last field is where most of the value comes from, because scripts that nobody can justify tend to be the ones worth removing.

Authorization

Authorization means a named person or process approved the script before it appeared on the page. In practice this usually rides on your existing change management process, with a specific approval step for anything that adds, removes or changes a payment page script. Tag managers need attention here, since they can let marketing or analytics staff add scripts without a code deployment.

Integrity

Integrity means you have a way to know the script running is the one you approved. The guidance in the standard points to mechanisms such as Subresource Integrity (SRI), which lets the browser verify a script's hash before running it, and a Content Security Policy (CSP), which limits where the browser can load scripts from and send data to. Script and tag-management systems that block unapproved code are another option.

What does requirement 11.6.1 require?

Requirement 11.6.1 calls for a change- and tamper-detection mechanism that alerts personnel to unauthorized modification of the HTTP headers and the contents of payment pages as received by the consumer browser. That includes indicators of compromise, changes, additions and deletions.

The mechanism must evaluate the received HTTP headers and payment page, and it must run at least once every seven days. Alternatively, you can run it periodically at a frequency defined in a targeted risk analysis performed according to requirement 12.3.1.

The applicability notes say the intent isn't for you to install software in your customers' browsers. Instead, the standard's guidance describes techniques you can combine:

  • CSP violation reports sent to you through the report-to or report-uri directives, along with watching for changes to the CSP header itself
  • External monitoring that requests and analyzes your payment pages, sometimes called synthetic user monitoring, and alerts on changes to scripts
  • A tamper-detection script embedded in the payment page that alerts on, or blocks, malicious script behavior
  • Reverse proxies and content delivery networks that detect script changes and alert personnel

Alerts only matter if someone acts on them. Route them to people who know what a legitimate change looks like, and connect them to your incident response plan under requirement 12.10.

How do 6.4.3 and 11.6.1 fit together?

The two requirements are designed to be used as a pair. One controls what should be on the page and the other tells you when the page no longer matches.

Requirement 6.4.3 Requirement 11.6.1
Focus Managing the scripts you intend to run Detecting changes you didn't intend
What it covers Every script on payment pages, first, third and fourth party HTTP headers and payment page content as received by the browser
Core activities Inventory with justification, authorization, integrity assurance Change and tamper detection with alerting
Frequency Ongoing, tied to change management At least every seven days, or per a targeted risk analysis
Mandatory from March 31, 2025 March 31, 2025

Your 6.4.3 inventory becomes the baseline that 11.6.1 monitoring compares against. Without a clean inventory, tamper alerts are noise because nobody can say which changes were approved.

Do 6.4.3 and 11.6.1 apply to SAQ A merchants?

Yes, with a nuance. SAQ A for PCI DSS v4.0 includes both requirements. That surprised many merchants who use a payment provider's hosted form and assumed their site was out of the picture.

The SAQ's completion guidance for 11.6.1 draws a line between two designs. If you use a URL redirect that sends customers to your payment provider's page, you mark 11.6.1 as Not Applicable and explain why in Appendix D. If your page embeds the provider's payment form in an inline frame (iframe), 11.6.1 applies. The SAQ doesn't include a similar carve-out for 6.4.3, so confirm with your acquirer or assessor how they expect you to handle it for your specific setup.

The reasoning behind the iframe distinction is that you still control the page hosting the frame. A script on that parent page could replace or overlay the embedded form, even though the form itself comes from your provider.

SAQ A-EP merchants, whose websites affect how card data reaches a payment provider, must meet both requirements in full. So must merchants validating with SAQ D or a Report on Compliance.

How should you get started?

A practical sequence we'd suggest for most small and mid-sized e-commerce teams:

  1. Identify every payment page. Include checkout steps, account pages where customers save cards, and any page that hosts an embedded payment form.
  2. Discover what actually loads. Use browser developer tools on each page and deploy a CSP in report-only mode to collect a list of script sources without blocking anything.
  3. Build the inventory. Record source, owner, purpose and justification for each script. Remove anything that doesn't need to be there.
  4. Put scripts under change control. Add a payment page script approval step to your change process, and restrict who can publish through tag managers.
  5. Apply integrity controls. Use SRI for scripts that don't change, and a CSP allowlist for sources. For third-party scripts that change without notice, talk to the vendor about versioned URLs or consider hosting a pinned copy.
  6. Deploy change and tamper detection. Choose a method or combination of methods that evaluates headers and page content as the browser receives them, and send alerts to people who can act.
  7. Set the frequency. Seven days is the default. If you want a different frequency, document a targeted risk analysis that meets requirement 12.3.1.
  8. Keep evidence as you go. Assessors will want the inventory, approval records, configuration of your integrity controls, and alert and response history.

Know the limits of CSP and SRI

SRI breaks any script whose content changes, so it suits pinned libraries and not vendor scripts that update frequently. A CSP controls where scripts come from but not what an allowed source serves, so a modified script on an approved domain passes straight through. Policies that rely on unsafe-inline also lose much of their protective value. These tools are strong building blocks, but they rarely satisfy both requirements on their own.

Frequently asked questions

Do we need to install anything in our customers' browsers?

No. The applicability notes for 11.6.1 state that the intent isn't for entities to install software in consumers' systems or browsers. The techniques described in the guidance work from your side, through headers, page content, external monitoring and scripts you serve.

Is a Content Security Policy enough on its own?

Usually not. A CSP helps with authorization and gives you violation reporting, but 6.4.3 also expects a justified inventory and integrity assurance for the script content itself. Treat CSP as one layer alongside SRI, change control and monitoring.

Can we check for changes less often than every seven days?

Yes, if a targeted risk analysis supports it. That analysis must follow requirement 12.3.1, which covers the assets, threats, likelihood and impact factors, and the justification for the chosen frequency. Requirement 12.3.1 itself also becomes mandatory on March 31, 2025.

What evidence will an assessor ask for?

Expect requests for the script inventory with justifications, records showing scripts were approved, the configuration of integrity mechanisms such as CSP headers and SRI attributes, and proof the 11.6.1 mechanism is running at the required frequency. Examples of alerts and how your team responded carry a lot of weight.

Key takeaways

  • Requirement 6.4.3 is about knowing and controlling every script on your payment pages. Requirement 11.6.1 is about detecting when those pages change without approval.
  • Both are best practice now and become mandatory on March 31, 2025. PCI DSS v3.2.1 retires on March 31, 2024, so most organizations will assess against v4.0 well before these deadlines arrive.
  • SAQ A merchants that embed a payment iframe should plan for both requirements. Redirect merchants should read the SAQ guidance for 11.6.1 closely and confirm their approach to 6.4.3 with their acquirer.
  • Start with the inventory. Every other control depends on knowing what is supposed to be on the page.