The Payment Card Industry Security Standards Council (PCI SSC) announced on the 30th January 2025 significant updates to the Self-Assessment Questionnaire A (SAQ A), The latest SAQ A version is now available, but does not take effect until March 31, 2025, which is when the new PCI DSS v4.0.1 requirements become mandatory.
What Are the Key Changes to SAQ A?
1) Removal of Security Requirements
Originally introduced in PCI DSS v4.0 to address payment page integrity and script-based attack risks. These requirements were removed from SAQ A because fully outsourced merchants should not be hosting or controlling payment pages, making these controls unnecessary under SAQ A.
- Requirement 6.4.3 – Previously required merchants to maintain an inventory of all scripts on their payment pages, authorise each script, and implement integrity controls to prevent malicious injections.
- Requirement 11.6.1 – Required merchants to implement tamper detection mechanisms to monitor and alert security teams about unauthorised modifications to payment pages, preventing Magecart-style attacks.
2) New Eligibility Criteria
- Merchants must now confirm that their website is not susceptible to script-based attacks that could compromise e-commerce security.
- Even with fully outsourced payment processing, organizations must secure their entire website against potential script vulnerabilities.
Who Is Affected by These Changes?
This change affects a subgroup of merchants eligible for SAQ A, specifically e-commerce-only merchants who fully outsource payment data processing to PCI DSS-compliant third parties and do not store, process, or transmit any account data themselves.
If your organisation is not currently SAQ A eligible, this update does not apply to you.
What Should Organisations Using SAQ A Know?
Organisations that are eligible for SAQ A may need to implement additional security measures in their website, such as script monitoring, Content Security Policy (CSP), and integrity controls, to maintain compliance.
What If an Organisation No Longer Qualifies for SAQ A?
Merchants who previously used SAQ A, but do not meet the new SAQ A eligibility requirements, no longer qualify to use SAQ A for PCI DSS compliance validation. Instead they will have to validate using SAQ A-EP or SAQ D, which impose more stringent security requirements – including script inventory, justification, and integrity monitoring to protect against malicious script attacks.
Can I Still Be Compliant Without Implementing Script Security?
No. Even with the removal of these requirements, SAQ A merchants are still required to prevent these types of attacks to meet PCI DSS compliance. The new changes do not eliminate the need for securing your site against vulnerabilities such as those caused by malicious scripts. Compliance under SAQ A or any other SAQ still requires organisations to protect customers' data and maintain a secure environment.
Will the Deadline for PCI DSS v4.0.1 Compliance Change?
No, the compliance deadline remains March 31, 2025. Merchants must still comply with the updated requirements, including the new eligibility criteria for SAQ A.
Non-compliance with the correct SAQ could result in penalties from payment brands or acquirers and potential data security risks.
————————————————————————————————————————————————————————————————————————————–
Next Steps for Merchants Using SAQ A
Merchants must proactively secure their web environments to continue qualifying for SAQ A and avoid transitioning to a different Self-Assessment Questionnaire. .
Step 1: Confirm SAQ A Eligibility Criteria
- The merchant's website does not collect cardholder data but, instead directs customers to a third-party payment processor (for example via PCI-compliant iFrames or URL redirection).
- All payment processing is fully outsourced to PCI DSS-compliant third-party service providers.
- The merchant does not electronically store, process, or transmit any cardholder data on its systems or premises.
Step 2: Confirm that your sites are protected against script-based attacks.
- Create a list of all scripts running on your payment pages.
- Then, confirm that each script comes from a reliable and trusted source.
For detailed guidance on how to secure your e-commerce site against script-based attacks, including specific security methods, how to get confirmation from your third-party service provider (TPSP), and other best practices for compliance, please refer to the article “How does an e-commerce merchant meet the SAQ A eligibility criteria for scripts?” on the official PCI Security Standards Council website.
Step 3: Confirm compliance before the March 2025 deadline.
- Conduct a security audit and/ or consult with your PCI Qualified Security Assessor (QSA)
- If, as of March 31, 2025, you cannot ensure your site is protected against script-based risks, you will no longer be eligible for SAQ A and may need to complete SAQ A-EP or SAQ D, depending on your specific circumstances.
Action Steps Based on Outcome
- SAQ A Valid → Proceed with SAQ A attestation.
- If the site cannot ensure script security → you may need to shift to SAQ A-EP or SAQ D, which have additional security requirements.
Key Takeaways
- The updates to SAQ A under PCI DSS v4.0.1 aim to simplify compliance for fully outsourced merchants while maintaining strong security standards. While Requirements 6.4.3 and 11.6.1 have been removed, merchants must still ensure their e-commerce websites are protected against script-based attacks.
- Compliance managers should review their current security posture, confirm eligibility for SAQ A, and implement the necessary protections to prevent unauthorised script execution.
- Organisations that do not meet SAQ A eligibility criteria may need to transition to SAQ A-EP or SAQ D to maintain PCI compliance.
Contact us and talk directly to one of our instructors about the role training plays in PCI DSS compliance and the training course or courses to best suit your needs.
Additionally, learn more about how Security Awareness Training supports an organisation-wide culture of security and how the Secure Coding for PCI DSS course helps developers to apply the secure coding and application security standards needed for applications that process card payments and/or cardholder data.
