PCI DSS 4 Update: Unpacking the Changes to SAQ A in FAQ 1588
Jeff Zitomer
Editor’s note: This blog post was originally published in January 2025. In light of new guidance released by the PCI Security Standards Council on February 28, 2025, we have updated the content to reflect the latest guidance regarding SAQ A eligibility criteria.
With the March 31, 2025, PCI DSS deadline fast approaching, the PCI Security Standards Council has announced important modifications for merchants validating to Self-Assessment Questionnaire A (SAQ A). This has left online merchants, qualified security assessors (QSAs), and payment service providers (PSPs) alike wondering what these changes really mean.
To provide further clarity, the PCI SSC released FAQ 1588 on February 28th, 2025. Specifically, the FAQ clarifies the steps merchants must take to confirm their website is not vulnerable to script-based attacks that could compromise the merchant’s e-commerce system(s).
E-commerce businesses have geared up to comply with requirements 6.4.3 and 11.6.1 since PCI DSS 4.0 was first introduced in 2022, so updating SAQ A just weeks before the deadline is a significant change that may impact the way many of them approach payment page security and compliance.
But should it? Let’s break it down.
How exactly did SAQ A change?
There are two key updates to SAQ A:
- Removal of PCI DSS Requirements 6.4.3 and 11.6.1 for payment page security and Requirement 12.3.1 for a Targeted Risk Analysis to support Requirement 11.6.1. This means that merchants who validate to SAQ A will no longer need to comply with requirements 6.4.3 and 11.6.1.
- Addition of an Eligibility Criterion to SAQ A for merchants to “confirm their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).”
This means that only merchants who can confirm that they meet this criterion will be able to validate to SAQ A. All other merchants who previously used SAQ A will now have to validate to SAQ A-EP or SAQ D.
Per the new FAQ released by the PCI Security Standards Council, this script-related eligibility criterion:
Does not apply to merchants who redirect customers to a PSP or fully outsource payment functions (e.g., sending customers a link in an email to a PSP’s site).
Only applies to e-commerce merchants who embed a third-party payment form (for example, via an iframe) into their website.
What does the new guidance actually mean?
First, there is no impact to PSPs and merchants that are ineligible for SAQ A. They must still implement 6.4.3 and 11.6.1 by the deadline of March 31.
SAQ A merchants are seemingly exempt as long as they can demonstrate that “their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).”
But how can a merchant demonstrate this?
FAQ 1588 now states that:
An e-commerce merchant that embeds a third-party payment form (e.g., via iframe) can confirm their site is not susceptible to script attacks by either:
- Implementing techniques similar to PCI DSS Requirements 6.4.3 and 11.6.1, which secure the payment page from e-skimming or other malicious scripts.
- Obtaining written confirmation from the PCI DSS-compliant PSP/payment processor that their embedded payment solution includes controls protecting the merchant’s site from script-based attacks, provided the merchant implements it according to their instructions.
There is some ambiguity in how the FAQ references “the merchant’s payment page.” In an embedded (iframe) model, the parent site belongs to the merchant, while the actual payment form is served by the PSP. It’s possible the Council meant “parent page” or “merchant’s e-commerce system(s)” rather than “merchant’s payment page.”
What is the outcome of the new guidance?
To qualify for SAQ A under the embedded-PSP model (i.e., an iframe on your webpage), you must confirm your site is “not susceptible” to script attacks. You can do this by effectively deploying client-side security controls from your side or by showing that your PSP’s embedded solution inherently safeguards against malicious scripts.
Although the new guidance provides flexibility in acceptable client-side techniques, merchants may find sticking relatively close to 6.4.3 and 11.6.1 to be the simplest and least controversial approach.
In contrast, merchants relying on the PSPS must engage their PSP to obtain sufficient contractual documentation or detailed technical assurances that these script-protection measures are in place. However, beyond the technical details of the PSP’s technique, merchants should ask PSPs to confirm they are indeed assuming the risk and liability of a breach resulting from scripts on the merchants’ parent page, should the PSP’s controls be bypassed. Some PSPs may or may not be prepared to offer such confirmation without additional legal or risk considerations.
It’s important to remember that a malicious script injected into the parent page can affect the payment flow and steal cardholder data —even if the PSP’s iframe is secure. Comprehensive client-side defenses can help protect the entire environment, not just the iframe.
What should you do
The clock is ticking, and the stakes are higher. With March 31 fast approaching, merchants unable to confirm their site’s insusceptibility risk not only non-compliance but also the loss of their SAQ A eligibility, possibly adding over 100 new requirements to their PCI DSS scope. Therefore, merchants who can’t immediately obtain convincing confirmation (and risk assumption) from their PSPs are strongly advised to cut through the ambiguity and deploy a client-side solution along the lines of 6.4.3 and 11.6.1..
Should you choose the route of deploying client-side security techniques, HUMAN Security is here to help. Our core PCI DSS solution streamlines payment page protection and compliance with requirements 6.4.3 and 11.6.1 (or any similar approach you may choose)..
Those opting for more comprehensive protection to confirm that their website is not susceptible to script attacks will benefit from our complete Client-side Defense solution. This provides complete browser script visibility and control across the entire website, enabling customers to safely benefit from JavaScripts while ensuring compliance with the new eligibility criteria. Click here for more on HUMAN and PCI DSS compliance, or register for our upcoming webinar by clicking the banner below.
