What do requirements 6.4.3 and 11.6.1 ask for?
A payment page loads scripts: for the payment form, for fraud checks, for analytics. A script that is altered without anyone noticing can copy card details as a customer types them. The Council calls this e-skimming [3]. The two requirements deal with it from two sides. One governs which scripts are allowed on the page. The other watches the page’s scripts and its security-impacting headers for change.
| Requirement | What it asks for |
|---|---|
| 6.4.3 | A method to confirm that each script is authorised |
| A method to assure that each script has not been altered | |
| An inventory of all scripts, with a written business or technical reason why each is needed | |
| 11.6.1 | A mechanism that alerts your staff to unauthorised changes to the security-impacting HTTP headers and the script contents of the payment page, as the customer’s browser receives them |
| The mechanism is set to evaluate the HTTP headers and the payment page as received | |
| It runs at least weekly, or at the frequency your targeted risk analysis defines (requirement 12.3.1) |
Requirement 6.4.3 covers scripts loaded from your own environment and scripts loaded from third and fourth parties. Requirement 11.6.1 does not expect you to install anything in a customer’s browser. Both also apply to a page of yours that includes a provider’s embedded payment form. Neither applies to you for the scripts inside that form, which are the provider’s to manage.
This is a paraphrase, checked against the Council’s version 4.0.1 questionnaire D for merchants [4]. Version 4.0.1 narrowed 11.6.1 from the page’s headers and contents to its security-impacting headers and its scripts. The full wording is in PCI DSS v4.0.1, which the PCI Security Standards Council publishes in its document library.
Who do they apply to?
Any merchant or service provider that takes card payments through a web page [3]. What you have to show depends on how your page takes the payment.
| Your situation | What applies |
|---|---|
| You are assessed against the full standard | Both requirements apply to the payment pages in your scope, and to any page of yours that includes a provider’s embedded payment form. The scripts inside the provider’s form are the provider’s |
| Your page includes a provider’s embedded payment form, and you validate on questionnaire A | You confirm that your site is not susceptible to attacks from scripts. You can do that with techniques like those in the two requirements, or with confirmation from your PCI DSS compliant provider that its solution, set up as it instructs, protects the payment page [2] |
| Your page redirects the customer to a provider’s page, or you send a payment link | That confirmation does not apply to you [2] |
Which questionnaire or report you use is decided by your acquirer or the card schemes, not by the standard [1].
What changed for questionnaire A in 2025?
On 30 January 2025 the Council announced three changes to self-assessment questionnaire A [1]:
- It took out requirements 6.4.3 and 11.6.1.
- It took out requirement 12.3.1, the targeted risk analysis that supports 11.6.1.
- It added an eligibility criterion: the merchant confirms that its site is not susceptible to attacks from scripts that could affect its e-commerce systems.
The new questionnaire took effect on 31 March 2025, the day the previous one was retired. The Council said the changes do not remove or reduce the underlying requirements in the standard [1]. The questionnaire changed. The standard did not.
In March 2025 the Council published an information supplement, “Payment Page Security and Preventing E-Skimming: Guidance for PCI DSS Requirements 6.4.3 and 11.6.1”. It is guidance. The Council says it does not add to, extend or replace any requirement [3].
How often does the page have to be checked?
At least weekly, or at the frequency your targeted risk analysis defines, carried out as requirement 12.3.1 sets out.
What an assessor will ask to see
For each payment page in scope, expect to be asked for five things.
- The inventory of scripts, with the business or technical reason each one is there
- How a script is authorised before it goes on the page
- How you would know if a script had been altered
- Alerts raised by change detection, and what was done about each
- The targeted risk analysis, if you check less often than weekly
How the platform helps
The platform holds the evidence you add for 6.4.3 and 11.6.1 under each number. Where it cannot check a requirement from your cloud accounts, it marks it not checked. Whether a requirement is in place is for your QSA to decide, or for you on a self-assessment.
Sources
- “Important Updates Announced for Merchants Validating to Self-Assessment Questionnaire A”, PCI Security Standards Council, 30 January 2025, https://blog.pcisecuritystandards.org/important-updates-announced-for-merchants-validating-to-self-assessment-questionnaire-a, read 13 October 2026
- FAQ 1588, “How does an e-commerce merchant meet the SAQ A eligibility criteria for scripts?”, PCI Security Standards Council, February 2025, https://www.pcisecuritystandards.org/faqs/1588/, read 13 October 2026
- “New Information Supplement: Payment Page Security and Preventing E-Skimming”, PCI Security Standards Council, 10 March 2025, https://blog.pcisecuritystandards.org/new-information-supplement-payment-page-security-and-preventing-e-skimming, read 13 October 2026
- Self-Assessment Questionnaire D for Merchants and Attestation of Compliance, for use with PCI DSS version 4.0.1, PCI Security Standards Council, October 2024, https://docs-prv.pcisecuritystandards.org/SAQ%20(Assessment)/SAQ/PCI-DSS-v4-0-1-SAQ-D-Merchant.pdf, read 13 October 2026