PCI DSS 4.0.1 SAQ A and Client-Side Security: A Plain-English FAQ

The run-up to the PCI DSS 4.0 deadline was, to put it kindly, confusing — requirements added, softened, pulled from questionnaires, then reintroduced as guidance weeks before merchants had to comply. Strip away the noise and one question is left for every e-commerce merchant: do you actually know what's running on your payment page right now, and would you know if it changed? If the honest answer is no, that's the whole of client-side security in one sentence — and it's the question Report URI answers for you. This FAQ covers the rest.

What are Requirements 6.4.3 and 11.6.1?

They are the two PCI DSS 4.0 requirements that govern the security of scripts on payment pages.

• 6.4.3 requires that every script on a payment page is authorised, has its integrity assured, and is inventoried with a written justification for why it is needed.
• 11.6.1 requires a mechanism to detect unauthorised changes to the security-relevant HTTP headers and script content of payment pages, and to alert on those changes.

Together they exist to prevent Magecart-style skimming attacks, where malicious JavaScript steals card data directly in the customer's browser.

What is SAQ A, and why does it matter here?

The Self-Assessment Questionnaire (SAQ) is how eligible merchants attest to their PCI DSS compliance. SAQ A is the shortest version, intended for merchants who have outsourced payment handling — typically by embedding a payment provider's page in an iframe, so the merchant never directly touches card data.

The complication is that the merchant still controls the parent page hosting that iframe. If the parent page is compromised, an attacker can manipulate what the customer sees and does — which is why client-side security reached even the lightest-touch merchants.

Didn't the council remove 6.4.3 and 11.6.1 from SAQ A?

Kind of — and this is the source of much of the confusion. In a revision to SAQ A (published 31 January 2025), the council removed Requirements 6.4.3, 11.6.1 and 12.3.1 from the questionnaire. But at the same time it added a new eligibility condition, requiring merchants to confirm that:

"their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s)."

So the specific technical requirements were removed, but a broad new obligation to prove your site is not vulnerable to script-based attacks took their place. Clear standards were replaced with a vaguer expectation — which raised the obvious question of how a merchant is supposed to demonstrate that.

How do I actually meet the new SAQ A eligibility condition?

The council answered this in FAQ 1588, published on 28 February 2025. It set out two ways to satisfy the condition:

• Option 1: Use techniques such as — but not limited to — those described in Requirements 6.4.3 and 11.6.1 to protect the merchant's page from scripts that target account data.
• Option 2: Obtain confirmation from a PCI DSS-compliant third-party service provider (TPSP) or payment processor that their solution includes techniques protecting the payment page from script attacks.

In effect, the requirements that were removed came straight back as the recommended way to meet the eligibility criteria.

Which of those two options is realistic?

For most merchants, Option 1 is the only viable path. Option 2 sounds convenient, but it runs into practical problems: your payment provider generally has no visibility into the security of your parent page, and few will take on the liability of formally attesting that your site is protected against script attacks. That leaves you implementing the 6.4.3 and 11.6.1 techniques yourself — which is exactly what Option 1 describes.

The good news is that these techniques are well understood and largely built into the browser: a Content Security Policy to authorise scripts and restrict where data can be sent, Subresource Integrity to pin scripts to known-good versions, and CSP reporting to detect change continuously.

Is there official guidance I can point my auditor to?

Yes. In March 2025 the council released an Information Supplement, Guidance for PCI DSS Requirements 6.4.3 and 11.6.1. It matters because it settles the disagreements that had been playing out between merchants, QSAs and vendors about which approaches are acceptable — in particular, confirming that CSP and related JavaScript governance techniques are a legitimate way to meet the requirements. If an assessor has previously pushed back on a CSP-based approach, this document is the reference that supports it.

Do I have to block scripts to comply?

No. A Content Security Policy deployed in report-only mode still authorises your known-good scripts and reports anything unauthorised — enough to meet 6.4.3's authorisation obligation and to feed the change detection 11.6.1 asks for, without blocking anything on your page. Moving to an enforcing policy that actively blocks unauthorised scripts is stronger protection, but it is not required for compliance; you can adopt it at your own pace once you are confident your policy is complete.

What should I do now?

If you accept card payments online, the practical steps are the same regardless of which SAQ you complete:

1. Inventory every script on your payment (or parent) page and remove anything unnecessary.
2. Authorise what remains with a Content Security Policy.
3. Pin third-party scripts with Subresource Integrity.
4. Monitor continuously with CSP reporting so you can detect and evidence change.

Report URI produces exactly the structured, exportable evidence this requires — a timestamped script inventory, a record of what your CSP reported, and alerts the moment anything changes. For the full breakdown of PCI DSS 4.0 client-side security, visit our PCI DSS hub; for a QSA-ready mapping of controls to evidence, get the 6.4.3 & 11.6.1 evidence pack; and for step-by-step setup, follow our compliance guides. You can also start a 30-day free trial and begin generating audit-ready evidence today.