Introduction: The evolution of e-commerce security and PCI DSS

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.

Overview of Requirements 6.4.3 and 11.6.1

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: Ensuring the integrity of payment pages through script management

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: Monitoring HTTP headers and script contents of payment pages for security implications

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.

Planning to successfully achieve the controls and meet compliance

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:

• Define initial scope and software bill of materials (SBOM). In recent years, supply-chain risk has become a highly visible risk with several high-profile disruptions. Those events have been the catalyst for regulators looking at the responsibility of technology providers (e.g., SaaS providers) and what is “good enough” security.  This step should challenge the existing practice to determine whether the payment footprint can reduce the complexity and attack surface by assuring all assets have been accounted for within the scope.
• Deploy a solution like Client-Side Defense across all web assets. Next, organizations need a solution to monitor all the complex and automated updates required in modern architecture.  The solution you deploy should have the capability to detect anomalous behavior of client-side code in real users’ browsers as it is constantly changing and likely derived from hundreds of resource locations.
• Regularly test roles and permissions to limit access to specific tasks required. Access control and correct permissions may be the most critical controls in modern payment architecture. They are vital to confirm correct assignment, quick revocation, and other functions. This is why zero-trust methodology has grown in popularity. You should regularly check access and not trust formerly approved access.
• Scope review and adjustment. Using tools like Client-Side Defense, you will most likely discover changes that require you to adjust your scope, modify your service-level agreement (SLA) potentially with providers and other adjustments. I’d recommend leveraging automation as much as possible but commit to regular reviews, at a minimum, to confirm changes in the environment.
• Identify key stakeholders. PCI DSS compliance should never be on the shoulders of the governance, risk, and compliance (GRC) team alone. I highly recommend you identify champions throughout the security and business teams that are relevant to the success of your e-commerce strategy — and then enable them to execute compliance tasks in their existing tools. Additionally, this list of stakeholders should be evaluated for resiliency when individuals are unavailable or have left and verified regularly.
  
  
• Develop standard operating procedures (SOPs). Now that everything is in place, there needs to be assurance it will be maintained as people rotate roles and other expected company changes occur.  SOPs should be created to maintain consistency of expectations. An SOP could define how the company tests and deploys scripts to specific payment pages, how to obtain authorization prior to deployment, how to address automated alerts from Client-side Defense for unauthorized changes, etc.
• Develop a training and communication strategy specifically for the e-commerce channel. All of the above can only maintain success with awareness that the procedures exist and why they are important to the success of the organization.  Security is not every colleague’s primary role and roles can change often, so regular communication that is concise and effective is vital.

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.

Additional PCI DSS requirements to reference

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.

1. Requirement 3: Protect stored cardholder data

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.

2. Requirement 8: Identify and authenticate access to system components

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.

3. Requirement 10: Track and monitor all access to network resources and cardholder data

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.

Conclusion: Achieving and maintaining compliance of payment pages

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