Under PCI DSS v4.0.1, SAQ A no longer asks you to attest to requirements 6.4.3 (managing payment page scripts) or 11.6.1 (detecting changes to the payment page). That doesn’t mean script risk is gone from SAQ A. The January 2025 revision swapped those line items for an eligibility criterion: before you can use SAQ A at all, you must confirm your site is “not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).”
So whether you need payment page script monitoring depends on how your checkout is built. A merchant that redirects to a hosted payment page doesn’t need to meet the criterion. A merchant that embeds the provider’s payment form in an iframe has to meet it, and has two ways to do so: deploy protections like those in 6.4.3 and 11.6.1, or get written confirmation from its PCI DSS compliant payment provider that the embedded solution already protects against script attacks. This post walks through what changed, what FAQ 1588 and the August 2026 revision of FAQ 1331 say, and what evidence a merchant or MSP should keep on file. It is general information, not legal or QSA advice. Your acquirer decides which SAQ you file.
What changed in SAQ A in January 2025?
On 30 January 2025 the PCI Security Standards Council (PCI SSC) announced a revised SAQ A. The revision:
- removed Requirement 6.4.3 (payment page script inventory, authorization and integrity),
- removed Requirement 11.6.1 (change and tamper detection on payment pages),
- removed Requirement 12.3.1 (the targeted risk analysis that supports the 11.6.1 frequency), and
- added an eligibility criterion requiring the merchant to confirm its site is not susceptible to attacks from scripts that could affect its e-commerce systems.
According to the Council, the January 2025 SAQ A took effect on 31 March 2025, the same day the October 2024 version was retired and the day 6.4.3, 11.6.1 and 12.3.1 became mandatory in PCI DSS v4.0.1 itself. The Council also said plainly that the change affects how SAQ A merchants report on these requirements. It does not remove or weaken the requirements in PCI DSS.
The April 2025 SAQ Instructions and Guidelines (v4.0.1 r1) now list two e-commerce criteria for SAQ A:
- All elements of the payment page(s) and form(s) delivered to the customer’s browser come only and directly from a PCI DSS compliant third-party service provider (TPSP) or payment processor.
- The merchant has confirmed that its site is not susceptible to attacks from scripts that could affect its e-commerce system(s).
The same guidance puts SAQ A at 27 applicable requirements for redirect and iframe merchants, compared with 139 for SAQ A-EP. It also notes that SAQ A for v4.x includes external vulnerability scanning (Requirements 11.3.2 and 11.3.2.1) for the pages that redirect to or embed the provider’s payment form.
What does FAQ 1588 say about the script criterion?
The Council published FAQ 1588 in February 2025 and explained it on its blog on 28 February 2025. It answers three practical questions.
Who it applies to. The criterion applies to e-commerce merchants whose webpage embeds a TPSP’s or processor’s payment page or form, for example through an iframe. It does not apply to merchants that redirect customers to the provider (HTTP 30x, meta refresh or JavaScript redirect), or to merchants that fully outsource payments, for example by emailing customers a payment link.
How to meet it. The FAQ gives two routes:
- Use techniques such as, but not limited to, those in Requirements 6.4.3 and 11.6.1 to protect the merchant’s payment webpage from scripts that target account data. The merchant can deploy these itself or use a third party.
- Get written confirmation from the PCI DSS compliant TPSP or payment processor that supplies the embedded page or form. The confirmation must state that the provider’s solution, when implemented according to its instructions, includes protection against script attacks.
Who counts as a TPSP. A provider whose only service is non-payment scripts that cannot affect account data is not treated as a TPSP for SAQ A purposes.
The FAQ closes the way most of these do: confirm with your acquirer or the payment brands that SAQ A is the right questionnaire for you.
What did the August 2026 revision of FAQ 1331 change?
FAQ 1331 is about something slightly different. It covers merchants assessed with a full Report on Compliance (ROC), not merchants filing an SAQ. It asks whether SAQ eligibility criteria can be used as a guide to which PCI DSS requirements apply in a ROC.
- The May 2025 bulletin said that if the merchant and its QSA agreed that applying only the requirements in an SAQ was acceptable, that SAQ could be used as a guide to applicability.
- The 4 August 2026 bulletin says the May 2025 wording could lead to misinterpretations about compliance responsibilities. The revised FAQ, dated August 2026, says SAQ eligibility criteria should not be used to decide ROC applicability unless the merchant’s compliance accepting entity, such as its acquirer or a payment brand, has reviewed and agreed to that approach.
The Council’s documents don’t single out 6.4.3 and 11.6.1. Commentators, including Reflectiz, read the change as closing a path some ROC-assessed merchants with iframe or redirect checkouts had used: marking 6.4.3 and 11.6.1 “not applicable” on the strength of SAQ A eligibility, with only the QSA’s agreement. That reading is reasonable, but it is commentary. If you are a ROC merchant, confirm with your acquirer.
For SAQ A filers, FAQ 1331 doesn’t change the SAQ. The January 2025 criterion and FAQ 1588 still apply.
Do I still need payment page script monitoring on SAQ A?
It depends on your checkout pattern:
| Checkout pattern | Likely SAQ | Script criterion applies? | 6.4.3 / 11.6.1 as line items? |
|---|---|---|---|
| Fully hosted: no merchant website involved, or payment by emailed link | SAQ A | No (FAQ 1588) | No |
| Redirect to the provider’s hosted payment page | SAQ A | No (FAQ 1588) | No |
| Provider’s payment form embedded in an iframe on your page | SAQ A | Yes | No, but you must meet the criterion |
| Your site builds the form (direct post) or loads scripts that shape the payment page | SAQ A-EP | Not applicable | Yes |
| Your site receives card data | SAQ D for Merchants | Not applicable | Yes |
For iframe merchants, the easier route is usually written confirmation from your payment provider, so ask whether it will issue the statement FAQ 1588 describes. If it won’t, or you can’t follow the provider’s implementation instructions exactly, then 6.4.3/11.6.1-style controls on the parent page are your evidence.
Even where the criterion doesn’t apply, the risk on the parent page doesn’t go away. A compromised script on a page that hosts or links to the payment step can still swap the iframe or redirect for a fake form. PCI SSC’s March 2025 information supplement, Payment Page Security and Preventing E-Skimming, is the Council’s practical guidance on that risk.
How do I evidence that my site is not susceptible to script attacks?
The SAQ asks you to confirm the criterion. It doesn’t ask you to attach anything. Your acquirer, or a forensic investigator after an incident, may still ask how you reached that conclusion. Keep a short evidence file.
If you rely on the provider’s confirmation:
- The provider’s written statement that its embedded solution, implemented per its instructions, includes script-attack protection. Note the date and the product or version it covers.
- The provider’s current PCI DSS Attestation of Compliance (AOC) covering the service you use.
- A record that your integration follows the provider’s instructions: the integration guide version, the configuration, and who checked it and when.
- A note to re-check whenever you change the checkout, theme, plugins or tag manager setup.
If you rely on your own (or a third party’s) controls:
- An inventory of the scripts that run on the page hosting the payment iframe, with a business reason for each (the 6.4.3 pattern).
- How scripts are authorized and their integrity checked, for example a Content Security Policy, Subresource Integrity, or a script management tool.
- Change and tamper detection on scripts and security-impacting HTTP headers as the browser receives them. Under 11.6.1 that check runs at least weekly, or at a frequency set by a targeted risk analysis. Keep alerts and review records.
- Who responds to an alert, and what happened the last time one fired.
For MSPs managing many merchants: record the checkout pattern for each client, since that decides whether the criterion applies at all. Keep the provider confirmation or monitoring evidence in a per-merchant folder, and re-check after any website change. The merchant still signs the attestation; the MSP organizes the evidence. If you manage systems that can affect a client’s payment security, check your own status too. Our post on MSP AOCs and service provider status covers that.
Frequently asked questions
Were 6.4.3 and 11.6.1 removed from PCI DSS?
No. They were removed only from SAQ A as line items, in the January 2025 revision. They remain in PCI DSS v4.0.1 and have been mandatory since 31 March 2025. They still appear in SAQ A-EP and SAQ D. PCI SSC said the SAQ A change affects how SAQ A merchants report, and that it does not remove or weaken the underlying requirements.
Does the SAQ A script criterion apply if I redirect to a hosted payment page?
Not according to FAQ 1588. It says the criterion applies to merchants that embed a provider’s payment page or form, such as an iframe, and not to merchants that redirect customers to the provider or fully outsource payments, for example with emailed payment links. You still need to meet SAQ A’s other eligibility criteria and its remaining requirements, including external vulnerability scans where they apply.
Is a letter from my payment processor enough to meet the criterion?
FAQ 1588 accepts written confirmation from a PCI DSS compliant TPSP or processor that its embedded solution, implemented according to its instructions, protects against script attacks. That only holds if you actually follow those instructions, so keep the letter, the provider’s AOC and a record of your integration together. Ask your acquirer if anything about your setup is unusual.
Does the 2026 FAQ 1331 revision affect SAQ A merchants?
Not directly. FAQ 1331 covers merchants assessed with a Report on Compliance and whether SAQ eligibility can guide which requirements apply to them. The August 2026 version says to get agreement from your acquirer or payment brand before using that approach. SAQ A filers still follow the January 2025 eligibility criterion and FAQ 1588.
Where CardSecurity fits
CardSecurity is building payment page monitoring aimed at the 6.4.3 and 11.6.1 pattern: script inventory, authorization records and change detection that MSPs can run across many merchants. It is in early access and not generally available yet. You can join the payment page monitoring early access. If your SAQ choice isn’t settled, start with which PCI SAQ you need.