PCI DSS 4.0 Requirements 6.4.3 and 11.6.1: Your Checkout Page Scripts Are Now a Compliance Obligation

What PCI DSS 4.0 Requires for Checkout Page Scripts

PCI DSS 4.0 introduced two requirements that directly affect every e-commerce site running third-party scripts on payment pages. These requirements went into effect on 31 March 2025. If your site processes, stores, or transmits cardholder data, you must comply.

Requirement 6.4.3: All payment page scripts that are loaded and executed in the consumer’s browser are managed as follows:

• A method is implemented to confirm that each script is authorised
• 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

Requirement 11.6.1: A change- and tamper-detection mechanism is deployed as follows:

• To alert personnel to unauthorised modification (including indicators of compromise, changes, additions, and deletions) to the HTTP headers and the contents of payment pages as received by the consumer browser
• The mechanism is configured to evaluate the received HTTP header and payment page
• The mechanism functions are performed at least once every seven days, or periodically at a frequency defined in the entity’s targeted risk analysis

What This Means for Your GTM Container

If your GTM container loads on your checkout or payment page, every tag within that container is a “script loaded and executed in the consumer’s browser” per 6.4.3. That means:

1. You must have a documented list of every GTM tag that fires on the payment page
2. Each tag must have a written business justification (e.g., “GA4 purchase event — required for revenue tracking”)
3. You must have a mechanism to verify each script’s integrity (e.g., hash comparison, content verification)
4. You must detect when any script changes (a new tag added, an existing tag modified, a tag removed)

This is not optional. Your QSA (Qualified Security Assessor) will ask for evidence of compliance during your next assessment. “We use GTM” is not sufficient. You need a documented inventory, justifications, and a working change-detection system.

Building a Script Inventory for Payment Pages

Step one is identifying every script that runs on your checkout page. This includes:

• GTM container script: The main gtm.js file
• Tags within GTM: Every tag that fires on the checkout page (not just the purchase event — any tag with a trigger that includes the checkout URL)
• Hardcoded scripts: Any <script> tags in the page source (payment processor JS, chat widgets, A/B testing tools)
• Dynamically injected scripts: Scripts loaded by other scripts (e.g., Meta Pixel loading connect.facebook.net)

For each script, document:

Field	Example
Script name	Google Analytics 4
Source URL	google-analytics.com/g/collect
Loaded via	GTM Tag ID: GA4-Config
Business justification	Revenue tracking for marketing attribution
Data owner	Marketing Analytics Team
Last reviewed	2026-03-15
Integrity check method	Runtime content hash comparison

Change Detection: Meeting Requirement 11.6.1

The change-detection mechanism must detect four types of modifications:

Script additions: A new tag appears on the payment page that was not in the approved inventory. This could indicate a compromised GTM account (Magecart attack) or an unauthorised GTM publish.

Script modifications: An existing script’s content changes. The tag is still there, but its code or configuration is different. This could indicate a supply chain attack where a third-party vendor’s script was compromised.

Script removals: An approved script disappears from the payment page. This could indicate a site deployment that accidentally removed the GTM container, or a GTM publish that removed a required tag.

HTTP header changes: The Content-Security-Policy, Strict-Transport-Security, or other security-relevant HTTP headers on the payment page change. This could indicate a server compromise or misconfiguration.

The requirement specifies monitoring at least once every seven days. But for a payment page, weekly monitoring is the minimum — not the target. A Magecart skimmer that runs for seven days before detection compromises thousands of cards. Real-time or near-real-time detection (within minutes) is the operational standard for effective protection.

QSA Evidence Requirements

During your PCI DSS assessment, your QSA will request:

1. The script inventory document (see table above)
2. Evidence that the inventory is maintained and updated (change log with dates)
3. Demonstration that the change-detection mechanism is operational (alert logs, detection reports)
4. Evidence of response procedures when a change is detected (incident response plan)
5. Proof that the mechanism has been tested (test results from a simulated unauthorised change)

Automated tag monitoring produces all five evidence types as a byproduct of normal operation. The script inventory is generated automatically. Changes are detected and logged with timestamps. Alert history provides the detection evidence. The system can be tested by adding a benign test tag and verifying the alert fires.