Navigating SAQ A Changes: A Risk Management and Security Perspective

On January 30th, the PCI SSC published a new version of Self-assessment Questionnaire (SAQ) A, which will take effect on April 1st, 2025. This update removes the PCI DSS v4.0.1 e-skimming requirements 6.4.3 and 11.6.1 but introduces a new eligibility criterion:
 

“The merchant has confirmed that their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).”

When this change was announced, it caused confusion. Many - including Jscrambler - stated that meeting requirements 6.4.3 and 11.6.1 were still the best way to confirm that their site was not susceptible to attacks. Additionally, the use of the term “site” sparked debate about whether security controls should apply to the entire merchant website or just to the payment page and parent page.

One month later, on February 28th, the PCI SSC published a new FAQ 1588 to clarify this new eligibility criterion for merchants relying on SAQ A. The FAQ specifies that merchants can confirm their webpage (not their site) “is not susceptible to script attacks” - (presumably those that could affect the merchant’s e-commerce system(s)) through one of two options, which I will explore in detail. 

While this update may seem like a minor compliance clarification, it carries important security and risk management implications, particularly given that SAQ A is not exclusively used by small merchants, but also by much larger businesses processing substantial transaction volumes.

Understanding the Risk: Web Skimming in its Many Forms

Before diving into how merchants can demonstrate non-susceptibility, it's important to understand the security threats posed by malicious scripts. Web skimming, also known as Magecart attacks, occurs when attackers inject malicious scripts into a merchant’s website. This can happen through vulnerable JavaScript dependencies, compromised third-party integrations, or direct attacks on the merchant's JavaScript through the hosting environment.

Web skimming can take several forms. The most common are:

• Silent Skimming – Payment data is exfiltrated in the background as the customer types it into the payment form in the browser. This often occurs through compromised third-party resources and does not introduce noticeable changes in user experience.

• Double-entry Skimming – The attacker presents a fake form mimicking the legitimate payment page. Customers enter their card details, which are stolen before they are redirected to the real payment page. Often, an authorization or processing error message is used to justify the need for the second entry, ensuring the real transaction still takes place. This is to prevent early detection due to an obvious break in the number of transactions.

Additionally, skimming can also be classified based on where the data is being skimmed from (i.e. where the skimmer code is running):

• Same-page Skimming – Payment data is skimmed by a script running in the same browser execution environment as the legitimate payment form (i.e., within the same DOM context).

• Parent-page Skimming – Payment data intended to be entered into a form in  a child iframe, is skimmed by a script running on the parent page that hosts the iframe.

For clarity, if the skimming script runs inside the iframe itself, rather than from the parent page, this is considered Same-page Skimming rather than Parent-page Skimming. It would have been really helpful if the PCI SSC had described the threat it is trying to mitigate in terms of Silent or Double-entry Skimming, and Same-page or Parent-page skimming.
 

Each of these attack vectors presents a serious risk to the security of cardholder data, and the new SAQ A eligibility criterion acknowledges the need for risk mitigation strategies that go beyond the previous assumptions that iframe-based isolation would suffice.

Examining the two paths to Non-Susceptibility

The new FAQ 1588 outlines two ways merchants can confirm their webpage is not susceptible to script attacks. For simplicity, let's call them Option A and Option B:

Option A: Merchants Implement Their Own Security Measures

One immediate question arises: What techniques qualify under this option? The FAQ mentions PCI DSS Requirements 6.4.3 and 11.6.1, but it also allows for alternative techniques. Does this mean equivalent techniques in scope and level of protection or just those that achieve the same outcome? The FAQ does not specify. We don’t know what the Council has in mind, but as a vendor, we do offer some alternatives that I plan to cover in a separate blog post.

This added flexibility is not new. Previously, merchants using SAQ A as the basis for a  Report on Compliance (ROC) and meeting 6.4.3/11.6.1 could implement compensating controls or use a customized approach to meet the same security objectives as 6.4.3/11.6.1. Such an approach would require additional documentation, including a risk assessment and assessor validation. Now that these requirements are merged into an eligibility criterion, validation has become less clear-cut — but assessors are still responsible for verifying compliance.

For merchants who already comply (or plan to comply) with 6.4.3 and 11.6.1, the path ahead is straightforward and predictable. This FAQ confirms that they step on solid ground.

Option B: TPSPs deploy their own security techniques

The FAQ also states that it should be possible for TPSPs providing an embedded payment page/form to implement their own solutions, including techniques that protect the merchant’s payment page (referring to the embedded payment page/form).  So, it clarifies what to protect, but not the how, and also not the where from. 

The FAQ also mentions that to make option B viable, merchants must follow the TPSP guidance when implementing the TPSP’s solution. This suggests that there are correct ways to do it, but also incorrect ways to do it, in which case the effectiveness of the TPSP solution might be hindered. 

Another key takeaway is that TPSPs may offer a solution but are not required to. This means merchants relying on this option must actively engage with their TPSPs to determine what protections, if any, are available. Until TPSPs clarify their stance, this path remains uncertain.

Interestingly, following Option B could also be seen as fulfilling Option A, since the FAQ states that "these techniques may be deployed by the merchant or a third party." If a TPSP implements security measures and delivers them on behalf of the merchant (for instance, on the parent page), the same protection could satisfy both options.

The Bigger Picture: Why This Change Matters

The flexibility provided by FAQ 1588 is beneficial from a security standpoint, as it allows merchants to take a security-outcome, risk-informed approach. However, it also introduces challenges:

• What qualifies as "non-susceptibility"? Without specific benchmarks, different merchants and assessors may interpret this differently.

• Larger merchants pose a higher risk. Many Level 1 merchants who process millions of transactions base their PCI DSS assessment on SAQ A following FAQ 1331. A single skimming attack could have massive consequences for the security of their customers' payment card data and their reputation. 

Initially, like all self-assessment questionnaires, SAQ A was intended for smaller merchants accepting a low volume of card-based transactions because their low volumes presented a lower risk to the card brands. A lighter security burden might be justified if that were still the case. However, via FAQ 1331, SAQ A is used as the basis of their PCI DSS assessment by many high-profile merchants. By strengthening SAQ A eligibility criteria, FAQ 1588 acknowledges that iframe isolation alone is insufficient to protect against modern web-skimming threats.

Moving Forward: A Security-First Approach

To align with the risk-based intent of this update, merchants should:

1. Re-evaluate their security posture – Treat the eligibility criteria and requirements within SAQ A not as a minimal compliance exercise but as an opportunity to strengthen defenses against evolving threats.

2. Demand clarity from TPSPs – Ensure that any service provider offering iframe-based payment solutions provides concrete security guarantees beyond basic cross-origin iframe isolation.

3. Implement proactive security measures – Go beyond checkbox compliance by adopting best practices in script integrity, behavior-based detection, and continuous monitoring.

4. Work closely with assessors and acquirers – The compliance-accepting entities should ensure that merchants are not simply ticking a box but genuinely mitigating script-based risks. Ensure compliance efforts lead to actual risk reduction.

Conclusion

FAQ 1588 helped clarify how merchants can confirm their site’s non-susceptibility to script-based attacks. They have two paths, one clear and predictable and another uncertain until TPSPs define their security approach. 

The SAQ A eligibility criteria change is more than a compliance update—it’s a recognition that skimming risks have evolved. While iframe-based payment solutions reduce some risks, they do not eliminate them. By reinforcing the need to secure merchant websites from script-based attacks, the Council is moving towards a more realistic and risk-informed approach, which should please larger merchants. 

Whether merchants choose to implement their own security controls or rely on a TPSP’s assurances, the ultimate goal remains the same: preventing web-based skimming attacks before they lead to cardholder data breaches. Most merchants understand that breaches may not result only in potential fines, but more importantly, they can result in reputation damage impacting their brands. Now that merchants are encouraged to take a risk-based approach, it also matters how high they set the bar, as that will send a strong message to their customers.