PCI DSS Script Requirements 6.4.3 & 11.6.1: Who They Apply To

PCI DSS 4.0 introduced two requirements about payment-page scripts: Requirement 6.4.3 (script inventory and authorization) and Requirement 11.6.1 (change and tamper detection). There is a lot of confusion about who actually has to implement them. This explainer covers what each requirement asks for, which merchants it applies to, and how a script inventory and change-detection report satisfies it.

First: do these requirements apply to you?

This is the part most articles get wrong. Requirements 6.4.3 and 11.6.1 apply to merchants who validate with SAQ A-EP (your own payment page) or SAQ D (you handle card data directly). Most small and mid-size e-shops use a hosted or redirect payment page from a compliant provider and validate with SAQ A — and as of March 31, 2025, the updated SAQ A removed 6.4.3 and 11.6.1. So if you file SAQ A, you generally do not need them. The client-side risk, however, is real for everyone — which is why monitoring still makes sense regardless of your SAQ type.

Requirement 6.4.3: Script Inventory and Authorization

For the merchants it applies to, this requirement asks that every script loaded on your payment pages is inventoried, explicitly authorized, and justified. The goal is that merchants know exactly what code is running where customers enter card data — and that every piece of code has a documented business reason for being there.

Requirement 6.4.3 Checklist

Complete script inventory for every payment page

Every JavaScript file (external and inline) loaded on each payment page must be cataloged. This includes third-party analytics, tag managers, payment processors, and any dynamically injected scripts.

Business justification documented for each script

Each script in your inventory needs a written justification explaining why it is necessary on the payment page. "We've always had it" is not a valid justification.

Explicit authorization for each script

Someone with appropriate authority must approve each script's presence on payment pages. This creates an allowlist of authorized scripts that can be verified during audits.

Integrity verification mechanism in place

You need a way to verify that authorized scripts have not been modified. This typically means hash-based verification (SHA-256 or similar) that detects any change to script content.

Coverage of all payment page variants

If your checkout flow spans multiple URLs (cart, shipping, payment, confirmation), every page that handles cardholder data needs its own script inventory.

Requirement 11.6.1: Change and Tamper Detection

While 6.4.3 focuses on knowing what scripts should be on your payment pages, 11.6.1 focuses on detecting when something changes. For the merchants it applies to, this requirement calls for a mechanism that alerts you when scripts are added, removed, or modified — and when HTTP security headers are tampered with.

Requirement 11.6.1 Checklist

Automated change detection mechanism

You need a system that regularly scans payment pages and compares current scripts and headers against the authorized baseline. Manual checks are not sufficient for this requirement.

HTTP header monitoring

Beyond scripts, 11.6.1 explicitly requires monitoring of HTTP security headers (Content-Security-Policy, X-Frame-Options, Strict-Transport-Security, etc.) on payment pages.

Alerting on unauthorized changes

When a change is detected, personnel responsible for payment page security must be alerted promptly. The alert should identify what changed, when, and on which page.

Regular scan frequency

The PCI Council expects change detection to run at least weekly, though best practice is daily or more frequent. Your scan frequency should be documented and consistently followed.

Evidence retention for audit

Every scan result, every change detected, and every alert generated must be logged and retained. An assessor will want to see a continuous timeline of monitoring activity.

Response process for detected changes

When an unauthorized change is detected, you need a documented process: investigate the change, determine if it is legitimate, update the baseline or remediate, and log the outcome.

What an Assessor Will Actually Ask

If you file SAQ A-EP or SAQ D, a QSA or your own self-assessment won't just check a box. They will look for evidence of genuine controls. Here are the questions you should be prepared to answer:

Show me the complete script inventory for each payment page in scope.

How do you verify that only authorized scripts are running on your payment pages?

Demonstrate the change detection mechanism. How often does it run?

Show me the alert you received when the last script change was detected.

What is your process when an unauthorized script change is found?

How do you handle payment pages behind WAF or bot protection? Can your scanner still monitor them?

Show me the evidence logs for the past 90 days of continuous monitoring.

How do you inventory inline scripts versus external scripts?

Common Compliance Mistakes

Mistakes That Will Fail Your Audit

Relying on Content-Security-Policy headers alone — CSP is a useful control but does not satisfy the inventory or change detection requirements by itself

Scanning only the final checkout page — every page in the payment flow that handles cardholder data is in scope

Ignoring inline scripts — Magecart attacks frequently inject malicious code as inline script tags, not external files

Manual inventory spreadsheets — a static document quickly becomes outdated and provides no proof of continuous monitoring

Skipping WAF-protected pages — if your compliance scanner can't get past Cloudflare, you have a gap in your evidence

How ScriptPatrol Covers Both Requirements

ScriptPatrol does the client-side monitoring these requirements describe — and produces the evidence to prove it. If you file SAQ A-EP or SAQ D, every feature below maps to the specific controls an assessor looks for. If you don't, you still get the protection.

Automatic Script Inventory

Every external and inline script on your payment pages is automatically cataloged with SHA-256 hashes, source URLs, and discovery timestamps.

Continuous Change Detection

Payment pages are scanned on your configured schedule. Any script addition, removal, or modification triggers an immediate alert with full change details.

Header Monitoring

HTTP security headers are tracked alongside scripts. Changes to Content-Security-Policy, X-Frame-Options, and other headers are detected and reported.

Allowlist Management

Authorize specific scripts and document business justifications directly in ScriptPatrol. Unauthorized scripts are flagged automatically.

Audit-Ready Evidence Export

Generate reports that map directly to Requirements 6.4.3 and 11.6.1. Complete audit trail with timestamps, hashes, and change history.

WAF-Compatible Scanning

Payment pages behind Cloudflare and other WAF services are scanned without requiring IP whitelisting or disabling bot protection.

Key Takeaways

Requirements 6.4.3 and 11.6.1 apply to SAQ A-EP and SAQ D merchants — SAQ A dropped them in March 2025
If they apply, you need both a complete script inventory AND continuous change detection
For those merchants, every payment page in the checkout flow is in scope, including WAF-protected pages
An assessor will look for an ongoing timeline of monitoring evidence
Manual spreadsheets and CSP-only approaches are hard to keep current and easy to gap
ScriptPatrol automates the whole workflow from inventory to evidence export — and protects every SAQ type

PCI DSS Script Requirements (6.4.3 & 11.6.1): Who They Apply To, and How