The Challenge
In March 2026, the PCI SSC's Q1 All Assessor Session was inundated with questions about one issue: how should merchants using SAQ A prove their websites aren't vulnerable to script attacks? The volume of inquiries led the Council to feature this topic in its May 2026 Assessor Newsletter's FAQ of the Month, republishing FAQ #1588 in full.
The problem? The FAQ reiterated the requirement without addressing the operational question. Requirements 6.4.3 and 11.6.1, which define script control and detection obligations, were removed from SAQ A, yet merchants are still accountable. The Council offered no practical guidance on demonstrating compliance with criteria that technically don't exist in the questionnaire.
This isn't theoretical. Every merchant using a redirect URL or iFrame to process payments must prove their site won't leak cardholder data through malicious scripts. But the framework meant to govern that proof lacks its own requirements.
The Environment and Constraints
SAQ A applies to three specific payment processing scenarios, as defined in the PCI SSC's eCommerce information supplement:
- The merchant operates no website; everything runs through a third party like Shopify or Amazon Marketplace.
- The merchant hosts a website that redirects to a payment processor (like PayPal) in a separate window.
- The merchant hosts a website with an embedded iFrame, either full-page or field-level, served from a third-party service provider's environment.
Any other payment method requires SAQ A-EP or SAQ D.
The constraint is architectural: in scenarios two and three, the merchant controls the page that invokes the payment process. That page can be compromised by e-skimming scripts before the redirect or iFrame loads. Requirements 6.4.3 and 11.6.1 were designed to address this attack surface, mandating script authorization controls and change detection mechanisms.
When the Council removed these requirements from SAQ A but kept them in the eligibility criteria, they created a compliance Catch-22. Merchants must prove they meet conditions no longer formally assessed. QSAs must validate controls that aren't in scope. Service providers must document responsibility for requirements not appearing in the questionnaire their clients use.
The Approach Taken
The Council's FAQ offers two paths for merchants to confirm their webpages aren't susceptible to script attacks:
Path 1: Use techniques detailed in Requirements 6.4.3 and 11.6.1 to protect the merchant's webpage from scripts targeting account data. These techniques may be deployed by the merchant or a third party.
Path 2: Obtain confirmation from the PCI DSS compliant TPSP or payment processor that their solution, when implemented according to instructions, includes techniques protecting the merchant's payment page from script attacks.
The FAQ concludes with a recommendation: "Merchants are encouraged to work with the merchant's TPSP to obtain guidance about how to implement the TPSP's solution securely."
This approach shifts the burden without clarifying the standard. Path 1 references requirements explicitly removed from the SAQ. Path 2 relies on TPSP confirmation without specifying what that confirmation should contain or how it should be validated.
Results and Metrics
The results have been confusion and inconsistent enforcement. QSAs report that service providers' Responsibility Matrices, which should explicitly call out how providers cover each requirement for merchants, contain vague explanations for script management.
iFrame providers often recommend that merchants implement their own script control methods for their websites. This contradicts the premise of SAQ A, which assumes the merchant's environment doesn't interact with cardholder data.
The assessor community has never received a clear answer on why these requirements were removed if they remain relevant. The Council points to the FAQ as if it contains guidance, but it only restates the problem.
What They Would Do Differently
The fundamental issue is architectural honesty. Any merchant that invokes the payment process from a website they host needs Requirements 6.4.3 and 11.6.1 documented.
If the Council believed these requirements were too burdensome for SAQ A merchants, they should have either:
- Redefined SAQ A eligibility to exclude scenarios where the merchant controls the page invoking payment.
- Created a new SAQ tier between A and A-EP specifically for redirect and iFrame implementations.
- Left the requirements in SAQ A and provided scaled guidance for implementation at this scope level.
Instead, they removed the requirements while keeping the underlying security obligation, creating a compliance framework that contradicts its own structure.
A more defensible approach would acknowledge that e-skimming risk doesn't disappear just because you're using a redirect or iFrame. The merchant's page is still the entry point. That page needs script controls, and those controls need validation criteria that don't reference removed requirements.
Takeaways for Your Team
Don't rely on the SAQ structure to define your security obligations. The removal of 6.4.3 and 11.6.1 from SAQ A doesn't eliminate your exposure to script-based attacks. If you host the page that initiates payment, you own the attack surface.
Demand specifics from your TPSP. The FAQ's suggestion to "obtain confirmation" is too vague to be actionable. You need documented controls: what script authorization mechanism is in place, how changes are detected, what monitoring covers your implementation, and how you'll be notified of anomalies.
Document your own script inventory. Even if your TPSP provides iFrame-based isolation, you need to know what scripts run on your payment pages, where they originate, and what data they can access. This inventory should be version-controlled and reviewed whenever you update your site.
Prepare for inconsistent enforcement. Until the Council provides clearer guidance, different QSAs will interpret these requirements differently. Some will accept TPSP attestations at face value. Others will require evidence of merchant-side controls. Build your program to the stricter standard.
The broader lesson extends beyond PCI DSS: when regulatory frameworks leave critical questions unanswered, you can't wait for clarification to secure your environment. The absence of explicit requirements doesn't reduce your liability when a breach occurs.
