What is the difference between current SAQ A and future SAQ A in PCI DSS validation?

Current SAQ A is the October 2024 version and remains valid until 31 March 2025. Future SAQ A is the January 2025 version and applies from 31 March 2025. The key difference is not just the date. The revised version changes eligibility expectations, especially by requiring merchants to confirm their whole site is not susceptible to attacks from scripts.

What Actually Changes Between the Two SAQ A Versions

The practical difference is not just a calendar cutover. The current SAQ A reflects the October 2024 validation expectations, while the future SAQ A becomes the operative version from 31 March 2025 and tightens what merchants must be able to affirm about their payment pages. The most important shift is that eligibility now depends on the site being resilient to script-based attack paths, not only on using a simplified questionnaire.

That matters because SAQ A is designed for a narrow merchant profile, where the merchant has reduced PCI DSS scope by relying on a third-party payment approach. The revised version makes the merchant’s own website behavior part of the validation story, so teams need to think about checkout pages, embedded content, tag managers, and any script that can influence payment collection or redirection. For the standard itself, see the PCI DSS v4.0 – PCI Security Standards Council.

Why the New Eligibility Expectation Matters

The key change is that future SAQ A is more explicit about whole-site susceptibility to script attacks. In practice, that means the merchant cannot treat only the payment widget or hosted payment page as the security boundary. If other parts of the site can be altered, injected into, or used to manipulate customer-facing payment flows, the simplified validation posture may no longer be defensible.

This is a control problem, not just a form change. Merchants need evidence that the site’s scripts are managed, reviewed, and constrained enough that attacker-controlled code cannot intercept cardholder data flows or alter the checkout experience. The change aligns with broader PCI DSS expectations around least privilege and secure handling of system and application behavior, which are central in PCI DSS v4.0.

For practitioners who want a broader control lens on script and application hardening, the OWASP ASVS is a useful companion reference because it maps cleanly to access control, validation, and application security expectations that support safer checkout implementations.

What Merchant Teams Should Verify Before Treating SAQ A as Stable

Merchants should verify the exact payment flow, not the intended one. That means testing every page and embedded dependency involved in checkout, confirming which scripts load, and identifying whether third-party code or tag management can change payment-related behavior without strong governance. If the site has dynamic content, marketing tags, or shared front-end components, those deserve the same scrutiny as the payment page itself.

Confirm which pages are in scope for payment collection and redirection.
Inventory all scripts, tags, and third-party dependencies on those pages.
Check whether any script can be modified, injected, or repurposed to alter checkout behavior.
Retain evidence of the review so the eligibility statement is supportable during validation.

For implementation support, the OWASP Cheat Sheet Series is a practical reference point for secure development and review patterns, while OWASP ASVS helps teams test whether the site is actually behaving in a controlled way rather than merely appearing compliant on paper.

Risk and Threat Considerations

The main risk is scope drift: a merchant may assume SAQ A still applies even when its site can be influenced by scripts, embedded services, or front-end changes that affect payment collection. That creates validation risk and, more importantly, a real exposure path for checkout tampering or data interception.

Failure mechanism: An attacker abuses injected or compromised JavaScript, third-party content, or front-end modification paths to alter the payment journey, redirect users, or capture sensitive data before it reaches the intended hosted payment control.

Impact: The merchant can lose SAQ A eligibility, inherit broader PCI DSS obligations, and expose customers to payment fraud or credential and card-data compromise through the web channel.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 address the attack surface, CIS Controls v8 and NIST CSF 2.0 set the technical controls, and PCI DSS v4.0 define the regulatory obligations.

Framework	Control / Reference	Relevance
PCI DSS v4.0	7 — Restrict Access by Business Need to Know	Payment-page scripts and checkout controls depend on least-privilege access and change control.
	8.6 — System and Application Accounts and Authentication Management	Scripted checkout flows and supporting application accounts require tight authentication control.
Recommendation — Restrict checkout and script-management access to only the roles that need it. Manage application and system accounts supporting payment flows with strong authentication and lifecycle control.
CIS Controls v8	16 — Application Software Security	The question turns on whether payment pages and scripts are safely built and maintained.
Recommendation — Review and harden payment-page code paths and third-party script dependencies.
OWASP Agentic AI Top 10	A1 — Prompt Injection and Tool Misuse	Selected only as a general script-abuse analogue is not material here, so omitted.
NIST CSF 2.0	PR.AC — Identity Management, Authentication and Access Control	Access control over payment-related page changes and scripts materially affects checkout integrity.
Recommendation — Apply access controls to limit who can alter payment-page behavior and dependencies.

Practitioner Guidance

What to verify: Treat the future SAQ A as a site-wide assurance question, not a checkout-page checkbox. Validate whether every script source, tag manager, and embedded component on payment-related pages is necessary, controlled, and resistant to unauthorized change.

Decision rule: If you cannot confidently show that the whole site is not susceptible to script-based manipulation affecting payment flow, do not assume the simplified validation path still fits. Re-check scope and evidence before the next attestation cycle.

Practitioner takeaway: The operational shift is from “we use a hosted payment page” to “we can prove our site cannot be used to subvert that payment page.” That proof is now the difference that matters.