When the PCI Security Standards Council launched in 2006, the risks associated with e-commerce transactions were significantly different.
E-commerce transactions were approximately 5% of total retail sales, direct employees generated most code on-premises and that code serviced only a small percentage of the global population. So while the Payment Card Industry Data Security Standard (PCI DSS) v1.1 addressed e-commerce and introduced web application security concepts, this was not its core focus.
Today, the digital payment landscape has changed significantly. With the ubiquity of cellular service, cloud computing and other advanced technology, e-commerce represents easily 25%-30% of overall retail sales, with the vast majority of software development relying on multiple third-party sources.
As the protection of online payments has become more complex, PCI DSS had to evolve. Two key updates in v4, which go into effect in March 2025, aim to strengthen the security of payment pages by managing browser scripts (DSS Req 6.4.3) and monitoring security-impacting HTTP headers (DSS Req 11.6.1).
So how do you know if your organization has adequate controls in place to keep payment information confidential and can demonstrate PCI DSS compliance?
I’d like to share my advice and planning for these, and other PCI DSS requirements, with the example of HUMAN Security’s Client-side Defense, to address this growing risk to companies of all sizes.
Any good plan starts with understanding the overall intent. That allows enterprises to identify not only the best approach for protecting customer payment data but also preferred methods to manage the ongoing compliance requirements.
Requirement 6.4.3 of PCI DSS 4 mandates that organizations inventory and actively manage scripts running on digital payment pages, including authorizing, justifying, and assuring the integrity of scripts. The objective is to protect payment transactions from malicious or unauthorized scripts that could lead to data theft or compromise. Attackers increasingly target browser scripts to exfiltrate sensitive information. This tactic has been successful in many Magecart-style or e-skimmer attacks for nearly a decade. Snippets of code—whether for analytics, marketing, or some other functionality—may not always receive the same scrutiny and validation prior to being introduced into production or delivered to client-side devices outside of traditional monitoring controls.
Requirement 11.6.1 requires a change and tamper detection for security-impacting HTTP headers and the script contents of payment pages, which are a critical component of web security. Headers like Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), and X-Frame-Options help protect against a range of web-based attacks, including digital skimming, cross-site scripting (XSS), and clickjacking. PCI DSS v4 highlights the need to monitor these headers and script-based payment page content, ensuring they are configured and enforced to prevent attackers from exploiting vulnerabilities.
Throughout my nearly two decades of interviewing CISOs and CROs about their governance to PCI DSS, the single most cost-effective step was hands-down always quality preparation and consistent internal testing. Having an understanding of expectations prior to a QSA assessment and regular checkpoints throughout the year could save organizations a significant amount on overall cost to demonstrate compliance as several studies have shown, including the Ponemon Institute’s True Cost of Compliance with Data Protection Regulation (Page 16).
Successful compliance with PCI DSS v4 begins with upfront preparation, aligning people, processes, and tools to ensure seamless management and monitoring of scripts and headers. That is to say, “compliance” is being able to demonstrate that activities are in place that should evolve alongside the organization as change occurs.
The following steps are my recommendations for a secure approach that also ensures that the spirit of the requirements are met:
I recommend working with technology providers that can help train on their solutions and how to best establish SOPs, as well as leveraging creative sources (like large language models, or LLMs) to generate more personalized training specifically for your industry, organization and employee responsibilities. If sales reps have examples that resonate with them personally, they are more likely to retain the information.
While I have focused on the new PCI DSS v4 requirements that have extended some of the scope of prior versions of the standard, it is important to identify other requirements that these controls complement.
Requirement 3 emphasizes confidentiality of stored cardholder data and makes changes for how authentication data should be protected. This is the crux of the entire PCI DSS, always has been, and by extending the monitoring capabilities of payment pages, this principle is reinforced with every transaction.
Many future attacks will try to manipulate authentication, especially with new generative AI malicious capabilities. Monitoring changes and access to payment environments to prevent such manipulation and limiting access for third-party software updates will enhance your overall adherence to the intent of the standard.
Audit trails for modification events and ensuring integrity of the payment environment are woven throughout all of PCI DSS 4. Requirement 10 states that is not enough to have the records. Organizations must also be able to create an automated response, or a recommended response, when anomalies are detected in the logs, including any form of payment page.
Complying with PCI DSS v4, particularly Requirements 6.4.3 and 11.6.1, is crucial for securing payment environments against evolving threats. By deploying procedures and automated solutions as well as adhering to best practices in scoping, consistent incident response, and training, organizations can successfully meet the new PC