Preparing for PCI DSS v4.0.1 Requirements 6.4.3 and 11.6.1

March 31, 2025, is an important date for entities that need to maintain Payment Card Industry Data Security Standard (PCI DSS) compliance. This is the date on which requirements that have previously been considered to be best practices must be met going forward.  

The intention of two of the new requirements, requirements 6.4.3 and 11.6.1, is to address the ever-growing threat of client-side attacks that exploit vulnerabilities to facilitate the unauthorized exposure of account data.  

The PCI Security Standards Council (PCI SSC) has published a through and insightful payment page security guidance document that explains the threats, details of the requirements and best practices to mitigate the risks.  

For many organizations, maintaining these requirements could be a challenge for a multitude of reasons, including the following: 

• Maintaining an accurate inventory of scripts running on payment pages, and the purpose for each script, can be difficult, especially if it involves manual processes. 
• Without a reliable inventory, it is difficult to determine what each script does and if the scripts are authorized to conduct the associated functions. Additionally, there would be nothing in place to maintain the integrity of authorized scripts such that existing scripts cannot be tampered with and new scripts cannot be introduced to execute malicious code. 
• Resource constraints may prevent adequate amounts of time, money and/or personnel from being dedicated to appropriately implement and maintain controls that meet these requirements, resulting in greater risk to account data and noncompliance with the PCI DSS. 

The intention of this article is to provide additional guidance that may help with overcoming these challenges. 

Demonstrating Compliance With Requirements 6.4.3 and 11.6.1 

The intent of requirements 6.4.3 and 11.6.1 is to reduce the risk of acquirers, merchants, service providers and consumers becoming victims of cyber attacks related to compromised payment pages. There is no reason to wait until your next PCI assessment to protect web payment pages. Here are some questions to ask yourself as you identify or implement a solution for these requirements, or that may be asked by your Qualified Security Assessor (QSA) during your PCI DSS compliance assessment: 

• Is there a payment page script inventory that includes any third-party scripts that are running on payment pages? Who maintains it? How is it kept up to date? 
• Are the functions and purposes of each script known and documented? How are scripts authorized for continued use? 
• Who can explain what each script does (features, data accessed, etc.)? 
• How often, and by what means, are scripts reviewed for vulnerabilities (e.g., secure code reviews, penetration testing)? 
• When a script changes or a new one is added: 
  • Who authorizes the change and who implements the change? 
  • Does the change go through change management processes? 
  • Is the script necessary? 
  • Are alerts generated when scripts change? 
• Is there documentation that details roles and responsibilities for authorizing, securing, inventorying and monitoring payment page scripts? Examples of documentation may include the following: 
  • Responsibility matrix 
  • Policies 
  • Procedures 
  • Targeted Risk Analysis (TRA) for requirement 11.6.1 
  • Configurations of components and their outputs 

Invest In Adequate Resources 

To be able to provide evidence demonstrating the effectiveness of payment page protections, it is critical to invest resources that reflect the consequences of a breach of account data and the potential cost of noncompliance. As we have worked with clients to address these new requirements, we have observed some common keys to success: 

• Use of automated technical solutions – There are ways to implement the controls using non-automated mechanisms (see page 17 of the PCI SSC payment page security guidance document). However, many clients have invested in automated solutions to avoid potential configuration mistakes, monitor for breakdowns, and reduce the level of internal resources that may be needed to implement manual solutions. 
  • Look at the following features when comparing automated solutions: 
    • Real-time inventories that capture details, including when new scripts are added, or existing ones are changed 
    • Alerting capabilities for when new scripts or changes are detected 
    • Alignment with existing change management processes (formal approvals, scheduled changes, etc.) 
    • The ability to capture business justification and descriptions for each script in the inventory 
    • Real-time monitoring of script behavior and indicators for risky behavior or scripts that may be inherently risky 
    • Potential for integration with other solutions (SOC, SIEM, SOAR, etc.) 
    • Monitoring for both web payment pages and scripts 
    • Consider a solution that provides detection as well as prevention (capabilities to block unauthorized web page and script changes), but note that this could cause business disruptions if not configured/managed correctly 
• Alignment of personnel – Maintain responsibility matrices to document the personnel responsible for various aspects of complying with requirements 6.4.3 and 11.6.1(see page 12 of the PCI SSC payment page security guidance document). 
  • Define roles for each of the requirements 
  • Assign responsibilities for developers, security teams, compliance officers, and third parties 
  • Ensure accountability in secure script management for the entire software development life cycle (SDLC) 
  • Implement and maintain documentation (policies, procedures, targeted risk analysis (TRAs), etc.)  
• Maintenance of the incident response plan – Keep the incident response plan updated to address new and serious risks to the environment. 
  • Document payment page threats and response playbooks 
  • Define actions for script-related alerts 
  • Train staff on how to respond to payment page attacks 

Key Takeaways and Next Steps 

PCI DSS requirements 6.4.3 and 11.6.1 are critical to protecting consumers’ account data that is stored, processed and transmitted on payment pages. The next step is to determine if you can provide adequate answers to the previously mentioned questions and offer substantial evidence to demonstrate that you’re meeting the requirements outlined in the PCI SSC payment page security guidance document.  

In addition to maintaining PCI DSS compliance, it is also critical to protect your organization’s reputation so customers can trust you to safeguard customer account data. To learn more about how Sikich can help your organization protect your web payment pages from attackers, contact Sikich today to set up a meeting with a Sikich QSA.