TL;DR: PCI DSS compliance checklist for 2026
- Two new items for every SAQ variant touching a payment page: 6.4.3 (authorize and inventory every script) and 11.6.1 (detect unauthorized modification).
- SAQ-A merchants on redirect or iframe are not exempt. Both apply because your parent page loads the scripts.
- Enforcement started 31 March 2025. QSAs now fail assessments where the merchant cannot produce evidence for both.
What Requirements 6.4.3 and 11.6.1 actually cover
The PCI DSS framework spans twelve requirement domains covering network security, access control, encryption, monitoring, and policy. Most of them predate the current version of the standard. Requirements 6.4.3 and 11.6.1 are the additions in PCI DSS v4.0 that address a risk earlier versions left uncovered: client-side script attacks on payment pages.
Requirement 6.4.3 covers script management. Every script loaded on a payment page has to be inventoried, carry a documented business justification, be explicitly authorised, and have its integrity verified on an ongoing basis. It applies to all scripts, including those loaded from third-party vendors.
Requirement 11.6.1 covers change and tamper detection. It requires a mechanism that detects and alerts on unauthorised changes to payment page HTTP headers and content. The standard sets a weekly floor, but continuous monitoring is what QSAs now expect to see as evidence.
Together these two form the client-side portion of the checklist for any merchant that accepts card payments on a web page.
Requirement 6.4.3 checklist
Each row below maps a 6.4.3 control to the manual way of satisfying it and the automated equivalent.
| Item | Requirement | Manual approach | Automated with cside |
|---|---|---|---|
| Script inventory | List all scripts on payment pages | Manual audit per deploy cycle | Automated, continuous |
| Business justification | Document reason for each script | Spreadsheet per script, updated manually | Prompted on new script detection |
| Authorisation status | Each script confirmed authorised | Sign-off process per deploy | Auto-flagged for review on change |
| Integrity verification | Hash/integrity check per script | Manual hash comparison per cycle | Real-time hash monitoring, per session |
Requirement 11.6.1 checklist
Requirement 11.6.1 is about catching change quickly and being able to prove you caught it.
| Item | Requirement | Manual approach | Automated with cside |
|---|---|---|---|
| Change detection | Monitor headers and scripts for changes | Scheduled scans (weekly minimum) | Real-session, continuous |
| Alert mechanism | Alert on any detected change | Scheduled email report | Real-time alert, under a minute |
| Frequency | Minimum weekly, continuous preferred | Manual weekly check | Continuous, every session |
| Evidence for QSA | Documented alert and response records | Manual log compilation (4 to 16 hours) | Report export in seconds |
PCI DSS compliance cost by merchant level
Annual PCI compliance cost scales with merchant level. The ranges below reflect the total programme cost, of which client-side tooling for 6.4.3 and 11.6.1 is one line item.
| Merchant level | Annual compliance cost |
|---|---|
| Level 4 (SME) | $5K to $25K |
| Level 3 | $50K to $150K |
| Level 2 | $100K to $500K |
| Level 1 (enterprise) | $1.5M to $5M |
Source: PCI Security Standards Council / Verizon PCI Compliance Report.
Tooling that covers 6.4.3 and 11.6.1 script monitoring typically accounts for 15 to 25 percent of the total. Automation cuts both the tooling cost and the engineering hours that manual checklist work would otherwise consume.
Manual vs automated: what the checklist looks like in practice
A manual approach to the 6.4.3 and 11.6.1 checklist means a script audit at every deployment, a spreadsheet-based authorisation workflow, periodic hash comparisons, and a log-compilation exercise before every QSA review. For a merchant running 20 to 50 third-party scripts on its payment pages, that adds up to roughly 15 to 30 engineering days a year.
The manual process also carries a detection lag. If a supply chain attack modifies a trusted script overnight, a weekly scan will not catch it until the next scheduled run. A QSA reviewing 11.6.1 evidence will ask what the maximum detection window was, and a seven-day window reads very differently from a one-minute window.
Automating the checklist collapses that window to under a minute. The tooling handles inventory, hash monitoring, change alerting, and report generation continuously, with no manual step between deployment cycles.
How cside PCI Shield automates the full checklist
cside PCI Shield implements the full 6.4.3 and 11.6.1 checklist from a single script tag.
On the 6.4.3 side, it keeps a continuous script inventory, flags new or changed scripts for authorisation review, and hashes every payload in real browser sessions using 100+ signals, holding high accuracy across incognito, VPN, and cookie-clearing sessions.
On the 11.6.1 side, it monitors HTTP headers and payment page content in live sessions, fires an alert within a minute of any unauthorised change, and keeps a timestamped alert log formatted for QSA review. Reports export in seconds rather than the hours a manual log compilation takes.
The methodology has been validated by an independent QSA (VikingCloud), and PCI Shield has a strong track record across customer audits. The same timestamped integrity log doubles as chargeback dispute evidence: showing exactly when a script was clean and when a change occurred strengthens a dispute package.
Further reading
- PCI DSS 4.0.1 client-side compliance guide
- Build the 6.4.3 script inventory and authorisation record
- Solution comparison for PCI DSS 6.4.3 and 11.6.1
- cside PCI Shield
As of 2026-07-29, treat this as operational guidance, not legal advice. Confirm the exact control language with your QSA, counsel, or risk owner.
