The Impact of PCI DSS 4.0.1 Updates on E-commerce Security

A Step Back or Strategic Flexibility?

00:00

When the proposed changes to PCI DSS 4.0 first appeared around  2022, there was wide praise for PCI Council’s tough new stance on JavaScript security for payment pages, particularly the requirements around Content Security Policy and Subresource Integrity (a feature that enables browsers to verify that resources they fetch are delivered without manipulation). These measures were specifically designed to combat Magecart-style attacks that have plagued major retailers like British Airways and Ticketmaster.

However, the January 2025 update to PCI DSS 4.0.1 appears to be softening some of these requirements, at least for certain merchants. PCI Council has announced a modification to SAQ A, with the removal of Requirements 6.4.3 and 11.6.1 for payment page security, along with Requirement 12.3.1 for Targeted Risk Analysis. Instead, merchants now need to “confirm their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).” This represents a notable shift from the prescriptive technical controls to a more flexible, risk-based approach.

The timing of these changes is particularly interesting. They come just ahead of the March 31, 2025, deadline when these requirements become mandatory, suggesting that feedback from the e-commerce community has highlighted implementation challenges, particularly for smaller merchants.

For businesses currently qualifying for SAQ A, those who completely outsource payment processing and retain only paper records, this creates both opportunities and challenges. While the removal of specific technical requirements might seem like a relief, the new eligibility criteria could actually push some merchants toward other questionnaires such as SAQ A-EP compliance instead (SAQ A-EP applies to those e-commerce merchants that partially outsource their e-commerce payment channel to PCI DSS validated and compliant third parties and do not electronically store, process, or transmit any account data on their systems or premises). This is especially true for merchants using iframe implementations for payments, as the PCI Council appears to be taking a broader view of payment page security responsibility.

The potential move from SAQ A to A-EP would significantly impact assessment scope, increasing the number of required controls from 27 to 131.

The changes reflect a delicate balance between security and practicality. While there is no doubting the importance of strict JavaScript controls on payment pages, PCI Council seems to be acknowledging that a one-size-fits-all approach may not be practical across the diverse e-commerce landscape.

However, merchants should not interpret these changes as a relaxation of security requirements. The underlying threats, particularly Magecart-style attacks, remain very real. The new requirements still demand that merchants take responsibility for script security, just with more flexibility in how they achieve this goal.

For merchants currently using SAQ A, the key question becomes whether their existing implementations truly isolate them from script-based attacks. Merchants should review their setups, as they may find themselves needing to implement more robust controls or face moving to SAQ A-EP.

These changes underscore a broader trend in payment security: the move toward risk-based approaches rather than purely prescriptive requirements. While this offers more flexibility, it also places greater responsibility on merchants to understand and actively manage their security posture, rather than simply following a checklist of technical controls.

The effectiveness of these changes will likely become apparent in the months following the March 2025 deadline. Until then, merchants would be wise to maintain robust security practices, even if they are no longer explicitly required by SAQ A.

Update to Advice on PCI DSS 4.0.1 E-commerce Security Requirements 

PCI Council has released two new documents on this subject: the “Guidance for PCI DSS Requirements 6.4.3 and 11.6.1” information supplement and FAQ 1588 “How does an e-commerce merchant meet the SAQ A eligibility criteria for scripts?”. The documents offer detailed explanations and practical implementation paths.

What Has Changed in Our Understanding 

The new guidance document significantly clarifies several key areas that affect how merchants should approach payment page security: 

1. Merchant Responsibilities Based on Implementation Type

Our previous advice suggested that merchants using iframe implementations might be pushed toward SAQ A-EP compliance. The guidance now explicitly outlines responsibilities based on different payment scenarios: 

• For iframe implementations: Merchants are responsible for scripts on their parent pages (non-payment pages), while Third-Party Service Providers (TPSP) are responsible for scripts within the iframe (payment pages) 
• For redirect mechanisms: If merchants use server-side redirects or HTML tags without JavaScript, Requirements 6.4.3 and 11.6.1 don’t apply to them 
• For fully outsourced solutions: Merchants have no responsibilities related to Requirements 6.4.3 and 11.6.1 

This clarification means some merchants who previously thought they might need to move to SAQ A-EP may still qualify for SAQ A, provided they implement the appropriate controls on their parent pages. 

2. Small Merchant Compliance Path

The original article noted concerns about smaller merchants facing implementation challenges. The guidance now offers a clear(er) compliance path for small merchants who use SAQ A by providing specific best practices:

• Working with TPSPs that confirm their solutions include techniques to protect against script attacks when implemented according to instructions 
• Getting specific confirmation from TPSPs about script security protections 
• Understanding that SAQ A merchants need only “confirm that their site is not susceptible to attacks from scripts” rather than implementing all technical controls 

Getting the necessary information from a TPSP (with the associated inference of limiting liability) may prove more difficult then anticipated, but it does, nonetheless, offer a pathway for merchants.

3. Flexible Implementation Options

We previously characterised the changes as “a delicate balance between security and practicality.” The guidance document now details numerous implementation options that support this flexible approach: 

• Manual processes can be acceptable for script authorisation and inventory 
• Multiple controls and techniques can be combined to meet requirements 
• Compensating controls and customised approaches are explicitly supported 
• Various technical approaches (Content Security Policies (CSP),  Subresource Integrity (SRI), webpage monitoring and proxy-based solutions) are equally valid 

Revised Advice for Merchants 

In light of this new guidance, we’re updating our advice to merchants: 

For SAQ A Merchants 

1. Engage with your payment processors/TPSPs: Request specific documentation confirming that their solutions protect against script-based attacks when implemented according to their instructions. 
2. Document your implementation: Maintain records showing you’ve followed provider instructions and implemented any recommended security measures. 
3. Understand your page structure: The guidance clarifies that SAQ A merchants using iframes must still address script security on their parent pages. Review your implementation to ensure you understand which pages are your responsibility. 
4. Consider simple controls: Even basic controls like limiting script sources or using a CSP can significantly reduce risk without major technical complexity. 

For SAQ A-EP and ROC Reporting Merchants 

1. Choose appropriate technical controls: The guidance outlines numerous controls and techniques that can be mixed and matched based on your environment. There’s no one-size-fits-all approach. 
2. Leverage your existing tools: Many existing security tools can be repurposed to meet these requirements; you may not need new solutions. 
3. Prepare assessment evidence: The guidance provides clear details about what evidence assessors will expect, allowing you to prepare appropriately. 
4. Consider targeted risk analysis: If weekly monitoring isn’t feasible, a properly documented targeted risk analysis per Requirement 12.3.1 can justify alternative frequencies. 

For All Merchants 

1. Inventory your scripts: Regardless of your assessment approach, knowing which scripts run on your payment pages is fundamental to security. 
2. Minimise unnecessary scripts: The most effective way to reduce risk is to limit the number of scripts to only those necessary for payment functionality. 
3. Document responsibilities: Clearly document which aspects of payment security are your responsibility versus your service providers’. 
4. Implement detection alongside prevention: Even with preventive controls, implement detection mechanisms to identify potential compromises quickly. 

Final Thoughts 

Our original assessment that “merchants should not interpret these changes as a relaxation of security requirements” remains valid. However, the guidance document now provides multiple paths to compliance that attempt to balance security with practical implementation.

The key takeaway is that all merchants, regardless of size or assessment type, must take responsibility for payment page script security, but they have more options than was originally thought. Ultimately implementing Requirements 6.4.3 and 11.6.1 will still remain the best way to ensure payment security.

In the first instance, if you are a merchant with concerns about these changes, you should approach your compliance enforcing entity (normally your acquirer or payment service provider) for their help and advice.

Learn more about DigitalXRAID’s penetration testing service for PCI DSS compliance.

Chris Leppard is Head of DigitalXRAID’s consultancy team and has more than 25 years’ experience in cyber security with 7 of those as a PCI QSA.