The PCI SSC released an FAQ regarding eligibility for SAQ A companies, concerning scripts on their site, referring to requirements 6.4.3 and 11.6.1 in PCI DSS 4.0.1.
This update caused confusion with assessors, our customers and prospects alike.
SAQ A is for merchants who fully outsource payment processing to PCI DSS-validated third-party service providers. No cardholder data should be processed, stored, or transmitted via the merchant’s systems
A common misconception is that using an iframe or redirect is enough. It’s not.
The key requirement is that the merchant must not load scripts that interact with the payment page. If scripts from the merchant’s domain or third parties are present, SAQ A will not apply.
The role of scripts in SAQ A compliance
- The payment form must be hosted and controlled entirely by a PCI-compliant provider.
- The merchant cannot load scripts that modify, monitor, or interact with the payment form in any way.
- The only scripts allowed must be directly managed by the validated payment provider.
If your checkout page includes JavaScript—whether for analytics, UI enhancements, or third-party tools in general—you might not qualify for SAQ A. Even if a script doesn’t touch payment fields, it can still introduce risks, such as:
- Form-jacking attacks that capture user input before it reaches the payment provider.
- Unauthorized DOM modifications affecting the payment process.
- Supply chain attacks leveraging third-party scripts.
One sentence sparks debate
The merchant has confirmed that their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).
This was added in the January update regarding SAQ A companies.
While PCI DSS applies to payments and payment pages, this sentence clearly states that the whole site is not susceptible to attacks from scripts. This makes sense. If for example a link leading to a payment page is not protected or monitored, a malicious 3rd party JavaScript inject can redirect the link and still compromise the user.
How that should be done is unclear, leading to confusion
The PCI SSC says to refer to the latest version of the PCI DSS SAQ A list for the complete list of eligibility criteria, but this does not reveal any information specifically linked to the quote above.
In the SAQ A list, this quote directly mentions scripts to monitor and/or secure:
In 6.4.3 (page 7):
All payment page scripts that are loaded and executed in the consumer’s browser are managed as follows: A method is implemented to confirm that each script is authorized. A method is implemented to assure the integrity of each script. An inventory of all scripts is maintained with written justification as to why each is necessary.
In this section, they mention solely all payment page scripts. Yet in the applicability notes below, it states:
This requirement applies to all scripts loaded from the entity’s environment and scripts loaded from third and fourth parties.
The entity’s environment blurs the lines, and opens the door to “their site” as a whole used in the sentence that spurred this debate.
Because sites load scripts dynamically, a script from any page can persist into checkout, potentially interfering with payments. Third-party scripts, even if unrelated or on pages loaded before the payment pages, can introduce vulnerabilities.
On Single Page Apps (SPAs), scripts persist across views, meaning a script loaded on any page can still be active during checkout. Similarly, with Progressive Web Apps (PWAs), scripts run continuously as users navigate, increasing the risk of unintended interactions with the payment flow.
In 11.6.1 (page 16), applicability notes:
The intention of this requirement is not that an entity installs software in the systems or browsers of its consumers, but rather that the entity uses techniques such as those described under Examples in the PCI DSS Guidance column (of PCI DSS Requirements and Testing Procedures) to prevent and detect unexpected script activities.
This road takes us to those examples, found in the SAQ A list on page vi. In the section “Not Applicable” it states:
The requirement does not apply to the merchant’s environment. (See “Guidance for Not Applicable Requirements” below for examples.) All responses in this column require a supporting explanation in Appendix D of this SAQ.
Only one example is found in “Guidance for Not Applicable Requirements”:
Requirements for securing all media with cardholder data (Requirements 9.4.1 - 9.4.6) only apply if a merchant stores paper media with cardholder data; if paper media is not stored, the merchant can select Not Applicable for those requirements.
“Appendix D” just refers to an area where the company applying for SAQ A status, or assessors assessing these companies, can fill out their findings and conclusion regarding this subject.
How to be compliant?
Next to all other SAQ A requirements, companies need to prove their website is protected against unauthorized script-based attacks. How they prove that, is up in the air. We at c/side created a tool that does that and makes companies check the box for requirements 6.4.3 and 11.6.1). Depending on the website set up however, there are other ways, provided they comply with other requirements needed to be eligible for SAQ A.
Do you need to comply with 6.4.3 and 11.6.1?
If you are eligible for SAQ A, you are technically exempt from both requirement 6.4.3 and 11.6.1.
However, SAQ A eligibility requires you to confirm that your whole site is not susceptible to script-based attacks that could compromise your e-commerce system. While the PCI SSC does not explicitly define how to validate this, it means you must ensure that:
- No unauthorized scripts are running on your site.
- Your checkout process is protected from manipulations (e.g., redirect hijacking).
- You monitor and secure all third-party integrations.
If you are not eligible for SAQ A, you must comply with both 6.4.3 and 11.6.1, as your environment falls into a higher compliance category where additional security controls are required.
And, this all on the whole site as the sentence - “The merchant has confirmed that their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).” - states.
Non-qualifying examples (SAQ A not allowed)
- Custom-built checkout with direct API calls to a processor (SAQ D required).
- A checkout page that includes any un-secured scripts affecting payment fields.
- Using third-party hosted fields but modifying them via JavaScript.
- Not confirming the site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce systems.
Conclusion
SAQ A provides a simplified compliance path for merchants who can fully outsource payment processing, but the latest clarifications highlight a critical shift: security responsibilities don’t stop at the payment page.
While 6.4.3 and 11.6.1 do not apply to SAQ A merchants, ensuring that the entire site is protected from script-based attacks is now a requirement.
This means merchants must take proactive security measures—not just to maintain compliance, but to prevent threats that could compromise their e-commerce ecosystem. CSP, SRI, and script integrity monitoring are likely to become baseline expectations rather than optional safeguards.
With c/side you are automatically compliant with 6.4.3 and 11.6.1.
We help merchants detect, monitor, and mitigate script-based risks. If you’re unsure about your compliance, we can help you check the box and stay secure.
Reach out to us to secure your client-side environment and maintain SAQ A compliance with confidence.