The Assessor’s Guide to Understanding SAQ A Changes

Unless entities have measures in place to protect their site, not just their payment pages, it is unlikely that they will be able to use SAQ A from 31 March 2025.

SAQ A v4.0.1 is Dead! Long Live SAQ A v4.0.1!

On Thursday, 30 January 2025, PCI SSC published an update to SAQ A 4.0.1, which is available in the PCI SSC Document Library. This means there are two slightly different SAQs, both with the same name, with only a publication date and revision number to differentiate them.

According to the PCI Council’s blog post about the update, SAQ A v4.0.1 published in October 2024, is valid until 31 March 2025. SAQ A v4.0.1 published in January 2025, is valid from 31 March 2025.

To keep things simple, I’ll refer to them as “current SAQ A” to refer to the October 2024 version, and “future SAQ A” to refer to the January 2025 version from now on.

What’s in a version number?

Historically, PCI standard updates which have kept the same version number have simply reflected changes to requirements that were previously best practices until a certain date which, due to the passage of time, have now become requirements. For example, when future-dated requirements in PCI DSS v3.2.1 - published in May 2018 - became full requirements in September 2022, the PCI Council published PCI DSS v3.2.1r1 at the same time and removed all references to the requirements being future-dated. However, in this update, PCI SSC has made some more substantive changes despite keeping the same version number.

Before I jump into this analysis, I want to highlight this sentence from the PCI Council’s blog post:
“Organizations must consult with their compliance enforcing entity if they have questions regarding PCI DSS compliance validation requirements or the applicable validation tools that they may be eligible to use.”

In other words, while it’s the PCI Council that’s written future SAQ A, it’s ultimately up to the Compliance Enforcing Entity (CEE) how they accept interpretations of them, although they’ll often rely on a QSA’s interpretation when making their final determination. 

What’s changed?

The most obvious change is the removal of requirements 6.4.3, 11.6.1, and 12.3.1 from the future SAQ A requirements. As a refresher, requirements 6.4.3 and 11.6.1 were added to  PCI DSS in version 4 to help prevent certain types of web skimming attacks, and requirement 12.3.1 is the Targeted Risk Assessment requirement, which is only referenced in requirement 11.6.1 in the current SAQ A. If 11.6.1 is removed, it makes sense to remove 12.3.1 too. However, the Council has added new eligibility criteria to future SAQ A, which seems much broader than the requirements being removed from current SAQ A. The new criteria read as follows:
The merchant has confirmed that their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).

Requirements 6.4.3 and 11.6.1 apply to the payment pages, but these new eligibility criteria apply to the whole site. I know from previous experience that the Council puts a huge amount of effort into the words it chooses, so this increase in scope can only be assumed to be deliberate.

Following this through logically, if a merchant is planning to continue using SAQ A in the future, they will now need to ensure that the way they protect against script-originated attacks covers the whole site and not just the payment page. If they can’t do this, they won’t meet the new eligibility criteria, and so they’ll likely need to complete SAQ A-EP instead. This would be a huge uplift, going from 27 applicable requirements in future SAQ A, up to 151 requirements and sub-requirements in SAQ A-EP.

SAQ A merchants typically outsource their payment processing either by redirecting to a TPSP or by embedding a payment form in an iframe. It’s this redirection or iframe embedding that the merchant needs to be able to confirm isn’t susceptible to an attack from another JavaScript  – whether that’s a first- or third-party JavaScript.

There will be many different ways a merchant can consider being effective for them to be able to make that confirmation. It could be as simple as having no scripts on their site, or ensuring that all scripts came from validated PCI DSS compliant service providers, or (and you might find this strange) implementing the types of controls that are in requirements 6.4.3 and 11.6.1. Of course, we’d suggest that implementing Jscrambler’s Webpage Integrity would be a preferred solution.

When does this become effective, exactly?

This should be an easy one to answer, but… it’s complicated. PCI DSS says that the new requirements are best practices until 31 March, after which they become requirements, whereas this SAQ is valid from 31 March, rather than after 31 March. My best guess is that this is a simple mistake and the Council meant to align the dates, but unless that gets clarified, if you happen to be sending in an SAQ on March 31, it may be better to submit before that date using the current October 2024 version of SAQ A, or after it using the future version of SAQ A, to avoid any potential confusion.

What about merchants completing an On-site Assessment & Report on Compliance?

FAQ 1331 is probably familiar to most assessors, as it allows merchants to potentially reduce the number of applicable requirements of their on-site assessment significantly, provided they meet all the eligibility criteria of one of the SAQs. This means any on-site assessment from 31 March relying on FAQ 1331 and the SAQ eligibility criteria, will need to use the updated eligibility criteria that apply at that point in time. This would also apply to assessments that have already begun, that are scheduled to complete after that switch-over date. Merchants that previously expected to only need a solution for their parent pages that included an embedded TPSP’s iframe, now need a solution that covers their whole site to be able to meet the revised eligibility criteria.

It’s important to remember that requirements 6.4.3 and 11.6.1 were published as best practices in PCI DSS v4.0 on March 31st, 2022, and merchants have used those 3 years to plan, budget, and implement those new requirements to protect against attacks from malicious scripts. Given the relatively last-minute nature of this update, the safest path for a merchant is to understand how the protection they had put in place to secure the parent page can now be applied to their whole site, and validate with their assessor that this would allow them to meet the new eligibility criteria.

And for the future? Where requirements 6.4.3 and 11.6.1 are already in place, but the future SAQ A eligibility criteria are not met, the merchant, with support and guidance from their assessor, can determine which PCI DSS requirements are applicable. If they previously met the eligibility criteria for current SAQ A, then the applicable requirements could reasonably be expected to be fairly similar to those in the future SAQ A, but expanded to cover the whole site.

Jscrambler is here to help. For ISAs and QSAs please join the QSA Alliance Program to gain access to additional SAQ A enablement. Or fill out our hotline and work directly with Gareth Bowker and John Elliott.