PCI DSS 4.0.1 in 2026 — WooCommerce Audit Findings
- PCI DSS 4.0.1 has been mandatory since March 31, 2025. Of its 64 new requirements, 51 were future-dated to that deadline — and four of those are generating most of the findings on WooCommerce stores in 2026.
- Requirement 6.4.3 requires an inventoried, authorized, integrity-checked list of every script on the payment page. Requirement 11.6.1 requires a weekly-minimum mechanism that detects and alerts on unauthorized changes to that same page.
- The PCI Security Standards Council removed 6.4.3 and 11.6.1 as line items on the SAQ-A questionnaire in 2025 — then replaced them with a new SAQ-A eligibility test, so most stores need the same evidence anyway.
- Requirement 6.3.2 is a separate, frequently confused control: an inventory of your own bespoke plugins and theme code, not the payment-page script list.
PCI DSS 4.0.1 replaced 3.2.1 as the mandatory baseline on March 31, 2025 — sixteen months ago. If your WooCommerce store’s compliance documentation still cites 3.2.1, that documentation is out of date. Four requirements in 4.0.1 are generating the most assessor findings on WooCommerce stores in 2026, and one of the four is routinely mislabeled even in compliance write-ups: 6.3.2 gets confused with the payment-page script rule, when it actually governs something else entirely. This guide covers all four, plus the 2025 SAQ-A change most guides still miss.
Requirement 6.4.3: client-side script authorization and inventory
Every JavaScript file that loads and executes on your payment page must be explicitly authorized, have its integrity verified, and have a documented business or technical justification recorded for why it’s there. That scope catches more than payment-gateway code — Google Analytics, Meta Pixel, live-chat widgets, and anything injected through a tag manager all count, because 6.4.3 doesn’t exempt scripts by vendor or purpose, only by whether they’re inventoried and approved.
| Script type | 6.4.3 requirement | Compliant approach |
|---|---|---|
| Payment gateway JS (Stripe, Braintree) | Authorized, purpose documented, integrity checked | Use an SRI hash on the script tag; document in the security policy |
| Google Tag Manager | Every tag loaded via GTM counts as a separate script | Audit all GTM tags; remove non-essential ones from payment pages |
| Analytics (GA4, Hotjar) | Must be authorized and documented | Block from the payment page or document authorization explicitly |
| Custom WooCommerce JS | In scope if it loads on checkout | Remove from the payment page unless directly needed for payment |
A single container that fires GA4, Meta Pixel, and Hotjar on the checkout page introduces three unauthorized scripts from a PCI perspective — even though none of them touch card data directly. The fix: exclude the payment-page URL from GTM triggers for non-payment tags, or run a separate, minimal GTM container on checkout with only pre-authorized scripts.
6.4.3 doesn’t name a specific technical control — it’s an outcome requirement. A restrictive Content Security Policy paired with Subresource Integrity hashes is the most common way WooCommerce stores satisfy it in practice, because both are enforceable by the browser rather than relying on a manual review catching a rogue script after the fact:
Content-Security-Policy:
default-src 'self';
script-src 'self'
https://js.stripe.com
https://www.googletagmanager.com;
frame-src https://js.stripe.com;
connect-src 'self'
https://api.stripe.com;
style-src 'self' 'unsafe-inline';
img-src 'self' data: https:;
object-src 'none';
base-uri 'self';
A CSP of script-src * or script-src 'unsafe-inline' does not satisfy the intent of 6.4.3 — a broad allow-list is functionally the same as no allow-list. The inventory and the justification still have to exist as documentation; the CSP header enforces what the inventory says should be allowed, it doesn’t replace the paperwork.
Requirement 11.6.1: change and tamper detection
6.4.3 is the guest list. 11.6.1 is the mechanism that checks who actually showed up. It requires a change- and tamper-detection mechanism that alerts personnel to unauthorized modifications — additions, deletions, or changes — to the security-related HTTP headers and script contents of the pages consumers actually see, at a minimum weekly. This is the direct response to Magecart-style e-skimming, where an attacker modifies checkout-page JavaScript after the fact to siphon card data, leaving the server-side code untouched.
Common implementation approaches include Subresource Integrity hash validation, DOM-behavior monitoring against a known-good baseline, and alert routing into whatever system your team already watches — a paging tool, a Slack channel, or the same monitoring stack that watches uptime. Weekly is the floor, not the target; PCI DSS lets you scan more often based on your own risk analysis, and most WooCommerce stores running third-party checkout scripts are better served scanning daily.
Requirement 6.3.2: bespoke and custom software inventory
This is the requirement the current published version of this guide previously mislabeled as a Content Security Policy rule. It isn’t. Requirement 6.3.2 requires you to maintain an inventory of all bespoke and custom software — plus the third-party components (libraries, dependencies, frameworks) built into it — so that a known vulnerability in one of those components can’t quietly sit unpatched because nobody knew it was there. For a WooCommerce store, that means your custom plugins, any child-theme code you wrote or paid a developer to write, and the packages those pull in via Composer or npm during your build.
The distinction from 6.4.3 matters because assessors ask two different questions. 6.4.3 asks: “what scripts run in the customer’s browser on the payment page, and are they authorized?” 6.3.2 asks: “what software did you build or customize, anywhere in the stack, and do you know what’s inside it?” A store can pass one and fail the other — a checkout page with a clean, minimal script inventory can still fail 6.3.2 if the custom order-sync plugin behind it pulls in a library with a known CVE that nobody tracked. Treat 6.3.2 as a lightweight software bill of materials for anything your team built, not an extension of the payment-page script list.
Requirement 5.4.1: targeted phishing protections
Stores must run processes and automated mechanisms — not training alone — to detect and protect personnel against phishing attacks that could lead to a cardholder-data compromise. Security-awareness training is a separate, existing requirement (12.6.3.1); 5.4.1 was written specifically so a store can’t point at an annual training slide deck and call the control satisfied. In practice this means email filtering, inbound anti-phishing tooling, and for stores that send email from their own domain, authenticating that domain.
Run your domain through MX Toolbox’s DMARC lookup. PCI DSS 5.4.1 doesn’t name DMARC or a specific policy level by number — it’s written as an outcome — but a missing record or a p=none policy gives an assessor nothing to point to as evidence of protection. p=quarantine or stronger, with rua reporting configured, is the bar most QSAs will actually accept.
SAQ tier assessment: what changed for SAQ-A in 2025
Your Self-Assessment Questionnaire tier determines how many of PCI DSS’s roughly 300 controls apply to your store directly. The tier itself didn’t change in 2025 — but what SAQ-A merchants have to prove did, and most compliance content written before 2025 still describes the old version.
| SAQ type | Who qualifies | 6.4.3 / 11.6.1 status |
|---|---|---|
| SAQ-A | Payment fully outsourced to a PCI-validated provider (redirect or iframe); no card data touches your server or your scripts | Removed as questionnaire line items in 2025 — but a new eligibility criterion requires you to confirm your site resists script-based attacks |
| SAQ-A-EP | Third-party payment page, but your own scripts still load on the checkout page | Full scope — both requirements apply directly |
| SAQ-D | Card data touches your server, or you use custom card-entry fields | Full scope, plus the rest of PCI DSS’s controls |
The PCI Security Standards Council confirmed the change directly: 6.4.3 and 11.6.1 were pulled from the SAQ-A form itself, along with the 12.3.1 targeted risk analysis that only existed to support 11.6.1. In their place, SAQ-A now requires the merchant to confirm their site isn’t susceptible to script-based attacks — satisfied either by implementing 6.4.3/11.6.1-style controls directly, by getting written confirmation from your payment page provider that their solution includes script-attack protection, or by an equivalent alternative technique. A script provider that doesn’t process payments doesn’t count as a PCI-compliant service provider for this purpose, so a generic tag-manager vendor’s word isn’t sufficient evidence on its own.
Verdict: dropping 6.4.3 and 11.6.1 from the SAQ-A questionnaire did not lower the compliance bar — it moved the evidence from the form into an eligibility test. Stores that can’t get a specific, written script-attack confirmation from their payment provider end up doing the 6.4.3/11.6.1 work anyway, just to stay eligible for the shorter form. Assume you need the evidence regardless of which SAQ you file.
Remediation order for WooCommerce stores
Work these in sequence — each step produces evidence the next step depends on:
- Inventory every script that loads on your checkout and payment pages, including ones injected through a tag manager, and record a business justification for each (6.4.3).
- Deploy a restrictive Content Security Policy and SRI hashes on payment pages to enforce that inventory technically, not just on paper.
- Stand up a change- and tamper-detection scan against payment-page HTTP headers and script content, running at least weekly, with alerts routed to a person who will act on them (11.6.1).
- Catalog your bespoke plugins and custom theme code, plus the third-party libraries built into them, and patch or replace any with known vulnerabilities (6.3.2).
- Confirm your SAQ-A eligibility in writing — get your payment provider’s script-attack-protection confirmation, or document your own 6.4.3/11.6.1 controls if you can’t.
- Deploy DMARC with
ruareporting alongside — not instead of — your existing annual phishing-awareness training (5.4.1 plus 12.6.3.1). - Re-run your SAQ or ASV scan after each change and file the updated attestation with your acquirer.
Compliance work here overlaps with the broader operational checklist most WooCommerce stores skip until an assessor asks for it — see the WooCommerce store-operations guide hub for the full list. If your store is also navigating EU GPSR product-page requirements or NetSuite tax compliance gaps, these deadlines tend to land on the same team in the same quarter — worth auditing all three at once rather than three separate times.
Get the working checklists
The runbooks and decision checklists from these guides, as printable PDFs — free in the SoftXone guide library.
Not sure where your store actually stands against 6.4.3 and 11.6.1 today? A store review can catch a stale script inventory or a missing tamper-detection mechanism before your assessor does.
References
- PCI DSS 4.0.1 Standard DocumentsPCI Security Standards Council — official PCI DSS 4.0.1 requirements documentation and SAQ forms.
- Coffee with the Council: E-Commerce Requirements After March 31, 2025PCI Security Standards Council — the SAQ-A change to 6.4.3 and 11.6.1, direct from the Council.
- Future-Dated Requirements of PCI DSS v4.xPCI Security Standards Council — the 64-total, 51-future-dated requirement count.
- Stripe PCI Compliance GuideStripe — how hosted payment fields reduce PCI scope for WooCommerce stores.
- MDN: Content Security PolicyMozilla Developer Network — CSP directive reference for building a compliant policy header.
Frequently asked questions
What is PCI DSS requirement 6.4.3?
It requires an inventoried, authorized, and integrity-checked list of every script that loads on your payment page, including analytics and tag-manager scripts, with a documented reason for each.
What is PCI DSS requirement 11.6.1, and how is it different from 6.4.3?
6.4.3 is the approved list; 11.6.1 is the weekly-minimum mechanism that detects and alerts on unauthorized changes to that page’s scripts and security headers — the control that catches an attacker modifying checkout JavaScript after the fact.
Does WooCommerce need a Content Security Policy for PCI DSS?
PCI DSS doesn’t name CSP by number, but a restrictive CSP paired with SRI hashes is the most common, browser-enforced way stores satisfy requirement 6.4.3’s authorization and integrity intent.
What does requirement 6.3.2 actually require, and how is it different from 6.4.3?
6.3.2 requires an inventory of your own bespoke plugins, theme code, and their third-party components — a software bill of materials for what you built, not the payment-page script list that 6.4.3 covers.
Which SAQ tier applies to my WooCommerce store, and did the 2025 change affect SAQ-A?
It depends on how your checkout handles card data. Since 2025, SAQ-A no longer lists 6.4.3 and 11.6.1 as questions directly, but it added an eligibility test requiring proof your site resists script-based attacks — most stores still need the same evidence.
Leave a Reply