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:

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.

The Cost of PCI DSS 4.0 Non-Compliance for Indian Businesses

For an Indian e-commerce merchant processing ₹5 crore/month in card transactions (approximately 50,000 transactions at a ₹1,000 average ticket), non-compliance with PCI DSS 4.0 has a direct commercial cost even before a breach occurs. Card brands (Visa, Mastercard, RuPay through NPCI) impose fines of $5,000–$100,000 per month (₹4 lakh–₹83 lakh) for documented non-compliance. Acquiring banks may suspend card processing entirely, which for a digital-first business can translate to a 70–85% revenue halt within 48 hours. On a ₹5 crore/month base, that is ₹3.5–4.25 crore/month of revenue at risk during a suspension period.

Beyond fines and suspensions, the assessment cost itself has tripled under 4.0. A Level 1 merchant’s annual QSA engagement has gone from $25,000–$45,000 to $60,000–$120,000 (₹5–10 lakh) due to the expanded scope of Req 6.4.3 and 11.6.1. Merchants without automated script-monitoring evidence find themselves in protracted remediation discussions with QSAs, each hour of which bills at $300–$500. A single poorly-prepared assessment can run 40+ billable hours longer than expected. The business case for automated monitoring pays back on reduced assessment hours alone.

Case Study: A South Indian Jewelry E-commerce Merchant

A jewelry e-commerce merchant based in Chennai processing ₹18 crore/month in card transactions had their PCI DSS 4.0 assessment scheduled for April 2026. Their existing compliance posture covered traditional vulnerability management, network segmentation, and physical security. The QSA flagged during the pre-assessment that Req 6.4.3 and 11.6.1 were not addressable with their existing toolchain.

During our engagement, we discovered their checkout page loaded 23 distinct scripts — only 11 of which the CTO could immediately justify. The other 12 included: two abandoned A/B test scripts that had been live for 14 months, a legacy Segment implementation that was replaced by GA4 but never removed, four marketing vendor scripts from a previous agency engagement, and three unknown scripts that had been injected via a compromised WordPress plugin a quarter earlier. The last finding was the most serious — one of the unknown scripts was exfiltrating form-input data to a Russian-hosted endpoint. The incident response required notifying the acquiring bank, engaging a PCI Forensic Investigator for ₹38 lakh, notifying approximately 22,000 customers whose cards had interacted with the compromised checkout flow, and offering 12-month identity-theft protection (₹24 lakh). Total direct cost: ₹72 lakh. The merchant’s assessment was deferred 9 months. Had continuous script monitoring been in place, the unknown scripts would have been detected within 2 hours of injection.

Step-by-Step PCI DSS 4.0 Script Inventory Playbook

1. Open your checkout page in DevTools. Go to the Network tab and record a full page load.
2. Filter to JS, HTML, and Other. Export the complete list of loaded resources.
3. For each script, document: source URL, domain, loaded-via (direct HTML, GTM, another script), size, purpose, data owner, business justification, and last reviewed date.
4. Use the Chrome Performance → Coverage tab to identify scripts loaded but not executed. Unused scripts are candidates for removal — they add attack surface without business value.
5. For each GTM tag firing on the checkout URL, document the same fields plus GTM Tag ID and Trigger configuration.
6. Generate an integrity hash (SHA-256) for each script’s content at a known-good state. Store these hashes in a change-detection system.
7. Configure your change-detection mechanism to compare runtime script content against the stored hashes on every page load. Alert on any mismatch.
8. Set up DNS monitoring for every script’s origin domain. If the domain’s WHOIS record changes unexpectedly, alert.
9. Establish a quarterly review cadence: for each script, re-verify the business justification and data-owner sign-off. Remove any script that lacks current justification.
10. Document an incident response playbook for script-level compromises: immediate tag removal, credential rotation, PCI forensic investigator engagement criteria, and breach notification thresholds.

Common Mistakes Merchants Make

Scoping Only Payment Processor Pages

4.0’s scope includes every page where cardholder data is entered or where scripts from the payment flow can be influenced. For most sites, this extends to the cart, account creation, and login pages — not just the final checkout step.

Relying on a CSP as the Only Control

CSP prevents loading scripts from unauthorised domains. It does not prevent malicious behaviour from scripts loaded from authorised domains. 4.0 requires integrity verification, not just source control.

Using Manual Weekly Reviews

Req 11.6.1 specifies “at least once every seven days.” Weekly is the floor. For payment pages, real-time or near-real-time detection is the operational standard. A skimmer running for 6.5 days before the weekly scan compromises thousands of cards.

Not Including GTM Container Changes in the Change-Detection Scope

GTM publishes are scripts loading on the payment page. A GTM publish that adds an unauthorised tag satisfies the letter of “unauthorised script modification” in Req 11.6.1. Monitor GTM publishes as a first-class compliance event.

Documenting the Script Inventory Once and Forgetting

QSAs expect the inventory to reflect the last 90 days of reality. A stale inventory — with scripts that no longer fire or missing scripts that were recently added — is worse than no inventory because it signals a broken process.

What QSAs Are Asking For in 2026

• A live-fire demonstration of tamper detection: the QSA adds a benign test script (a single console.log or an inert tag) to the payment page. Your monitoring must alert within the defined detection window.
• Change-history logs covering every script addition, modification, and removal for the past 12 months — with approver names, timestamps, and business justifications.
• Evidence of integrity-verification execution — not just “we check,” but logs showing the check ran, the hashes compared, and any mismatches detected.
• Incident response records for any script-level alerts that fired in the past 12 months — including false positives, remediated true positives, and documented root causes.
• Training records for every user with GTM Publish access, covering phishing awareness and the 4.0 obligations.
• A targeted risk analysis (under Req 12.3.1) that justifies your chosen detection frequency. If you monitor daily rather than real-time, the analysis must explain why daily is adequate for your threat model.

Implementation Checklist for Req 6.4.3 and 11.6.1

• Generate the baseline inventory: Every script on every payment page, documented with the required fields.
• Assign script owners: One named person per script; review quarterly.
• Deploy runtime integrity verification: Automated hash comparison on every page load.
• Configure real-time alerting: Critical alerts within 5 minutes to security operations.
• Establish GTM access controls: MFA mandatory, quarterly access reviews, least-privilege principles.
• Log every GTM publish: Version, user, timestamp, diff, approval record.
• Configure DNS monitoring: For every third-party script origin, alert on domain registration changes.
• Build a test harness: Periodic injection of benign test scripts to verify detection remains functional.
• Retain evidence for 12 months: Alert logs, inventory snapshots, change histories.
• Run tabletop exercises quarterly: Simulated Magecart incident, validate IR playbook.
• Update the targeted risk analysis annually: Reflect evolving threat landscape.
• Coordinate with your QSA quarterly: Ensure your evidence package is aligned with their expectations.

Evidence Collection Patterns That Satisfy QSAs

QSA assessments for PCI DSS 4.0 are increasingly evidence-driven. The five artefacts that consistently satisfy assessors: (1) an inventory report generated within 48 hours of the assessment, showing every script on payment pages with owner, source, and purpose; (2) a tamper-detection alert log showing at least 90 days of operational history, including at least one test-triggered alert to demonstrate the system fires; (3) a change-approval log for every script addition or modification in the preceding 12 months; (4) a quarterly access-review record showing which users had GTM Publish access and why; (5) a tabletop exercise report showing the incident-response playbook has been practised in the preceding 12 months.

Merchants that produce these five artefacts in under 2 hours typically pass the script-monitoring controls assessment cleanly. Merchants that cannot produce them in under 24 hours typically receive findings that require remediation before certification. Invest in evidence automation — it is cheaper than remediation cycles.

Indian Market Specific Considerations

Indian payment ecosystems add complexity. UPI integrations: when users are redirected to a UPI payment app and back, the “payment page” scope under PCI DSS may extend to the pre-redirect page capturing the user intent. Scope determination requires QSA consultation; do not assume the redirect externalises all PCI concern.

RBI regulations: India’s Reserve Bank has tokenisation mandates that interact with PCI DSS. Merchants using card-on-file tokens still face some PCI scope on the token-capture page. Script monitoring applies to these pages even when the token exchange minimises PAN exposure.

Card network requirements: Visa, Mastercard, RuPay, and Amex each have network-specific operational requirements that overlay PCI DSS. Merchants operating across networks must satisfy the strictest common denominator. RuPay’s NPCI requirements are evolving rapidly; review quarterly.

Bottom Line

PCI DSS 4.0’s script-monitoring requirements are not a paperwork exercise — they are a functional control with teeth. QSAs in 2026 are executing live-fire tamper tests during assessments. Merchants without automated detection are failing assessments and facing card-brand fines within 30 days of non-compliance findings. The cost of getting this wrong is fines of ₹4–83 lakh/month plus incident costs of ₹50 lakh–₹3 crore per skimmer incident. The cost of getting it right is a small-to-moderate line item on the annual compliance budget. The ROI is among the most favourable in the entire compliance stack.