PCI DSS 6.4.3 and 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 whatever 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) 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 it 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, which an inventory of external files never lists

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 every four hours. Every script addition, removal or modification is recorded with full change details, and after a site's first week a change that looks like an attack or needs your decision is emailed to you.

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

On most sites, payment pages behind Cloudflare and other WAF services are scanned without an allow rule and without disabling bot protection. Where a firewall blocks the scan, Scanner Access in your dashboard shows how to let the scanner through.

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