As businesses race to comply with PCI DSS v4.0 requirements 6.4.3 and 11.6.1 ahead of the March 31st deadline to protect their payment pages from e-skimming, more and more are finding that the task isn’t a straightforward “check the box” exercise. 

‍

Rather, there’s a lot of work involved in getting lots of different teams (from web development to marketing to IT operations) all on the same page, finding and adding the right technical controls, and setting up solid script auditing and change management processes.

‍

When it comes time to get your Qualified Security Assessor (QSA) to examine your system, you might run into a few big – yet unnoticed – gaps.

‍

So, to help, our very own Thomas Borrel, Chief Product Officer at DataStealth, connected with Robert Spivak, the Director of Business Development at ControlGap. ControlGap is one of the largest QSAs in North America (and DataStealth’s QSA!). 

‍

Together, they shared a few insights about the best practices you can put to use to get your PCI compliance efforts on the right track.

Who Needs to Meet PCI DSS v4.0 Requirements 6.4.3 & 11.6.1?

Every organization – be it big or small – that’s involved in processing, storing, and transmitting payment card data must comply with PCI DSS v4.0. 

‍

So, whether you’re a retailer or merchant, service provider, or whatever else, if you’re handling payment card data, you need to comply with PCI DSS v4.0. Moreover, any organization that has an online payment page needs to be compliant with requirements 6.4.3 and 11.6.1

‍

In particular, if you’re running scripts (like web traffic analytics tools, website plugins, etc) on your payment pages, then PCI requirements 6.4.3 and 11.6.1 apply to you. 

4 Things QSAs Want to See for Requirement 6.4.3

When assessing compliance with PCI DSS v4.0 requirement 6.4.3, a QSA will look at these:

1. Comprehensive Script Inventory

The QSA will confirm that the organization has created and maintains a detailed inventory of all scripts used on payment pages. 

‍

This inventory must include the script names, origins, vendors, version numbers, and a clear justification for each script's inclusion. 

‍

The QSA will likely review documentation to ensure this inventory is accurate and up to date, as well as see whether unauthorized or unnecessary scripts have been removed from the payment page.

Mistakes to Avoid:

Incomplete inventory: Organizations often fail to inventory all scripts on payment pages, including those from third and fourth parties, leading to gaps in visibility.

‍

Thomas spoke about how easy it is to underestimate how many scripts you could actually have running: "We've had clients where the page loads and you have seven, eight scripts. By the time you make it to the payment page, you get to 150, 200 scripts, sometimes even more."

‍

Assuming scripts are out of scope: Many merchants mistakenly believe scripts outside of third-party iframes are not part of their compliance scope, leaving them unmonitored.

‍

Robert adds that even when using iFrames to reduce PCI scope, the scripts attached to the iframe or payment page still need monitoring, “There are scripts that are attached to that iframe and to the payment page in general. And that's where the delivery to the consumer... should really take a broader approach."

‍

Failure to update regularly: Static inventories that aren’t updated to reflect changes in scripts or new additions result in outdated records. 

‍

Robert emphasized that it’s easy for organizations to lose track of how many scripts they could add over time, especially when unchecked. “We’ve had it with many of our clients…upwards of 400 scripts when you go through all the layers.”

2. Script Authorization Process

The QSA will examine the organization's process for authorizing scripts before deployment. 

‍

This includes verifying that there is a formal process to justify the inclusion of each script based on business or technical needs. 

‍

The QSA may look for evidence of internal approvals and controls that ensure only authorized scripts are deployed on payment pages.

Mistakes to Avoid:

Lack of formal authorization: Organizations often do not establish a robust process to authorize scripts before deployment, which can lead to unauthorized or malicious scripts being executed.

‍

Misclassification of scripts: Misunderstanding the purpose of certain scripts (e.g., mistaking a marketing script for a functional one) can lead to inappropriate authorization decisions.

‍

Overlooking business justifications: Failing to document clear business or technical justifications for each script is a common oversight that QSAs will flag during audits.

3. Script Integrity Assurance

The QSA will check if mechanisms are implemented to ensure the integrity of authorized scripts. 

‍

This could include Subresource Integrity (SRI) tags, which validate that scripts have not been tampered with, or dynamic tools that monitor and remove unauthorized or modified scripts before they reach consumers' browsers.

‍

However, SRI tags provide limited capabilities and don’t apply to all the types of scripts embedded in a payment page. For example, SRI tags can cover internal scripts under your direct control, but they don’t address risks from third-party scripts whose vendors rely on other tools/vendors and, in turn, generate fourth-party scripts. 

Mistakes to Avoid:

Weak integrity validation mechanisms: Many organizations neglect to implement real-time tampering detection and protection to validate script integrity and block malicious and/or unauthorized script changes around the clock, exposing them to tampering between scheduled checks.

‍

Delayed detection of changes: Relying on periodic checks instead of real-time monitoring means unauthorized changes can go undetected for extended periods, increasing security risks.

‍

Assuming browser reliance: Some organizations use tools or solutions that execute on the consumer’s browser. However, these tools aren’t compatible with every single browser, and, in turn, may leave a big gap of exposed users. Exploits on these unsupported browsers can lead to a breach and, in turn, a compliance problem for you down the line. 

‍

Thomas emphasized that the right approach to browsers is to “not expect the consumer’s browser to do the right thing.” In other words, look for solutions that monitor, alert, and/or neutralize threats independently of the user’s browser. 

4. Documentation

QSAs will require documentation demonstrating compliance with requirement 6.4.3. This includes maintaining records of script inventories, authorization processes, risk assessments, and any changes made to scripts or payment pages. 

‍

The documentation should also outline how the organization ensures ongoing compliance and addresses any issues identified during monitoring.

‍

Overall, Robert stresses that “demonstrating compliance” is key and “having a policy…the people who are involved in the compliance process, [and] having the processes to be able to communicate how they deal with the different things” should all be in place.

Mistakes to Avoid:

Failure to maintain records: Not keeping comprehensive documentation of script inventories, authorizations, and monitoring activities undermines compliance efforts and audit readiness.

‍

Inadequate audit trails: Without detailed logs showing who authorized scripts and when changes occurred, organizations cannot demonstrate accountability or compliance.

‍

Outdated policies and procedures: Policies related to script management are often not updated to reflect current practices or PCI DSS v4.0 requirements, leading to gaps during assessments.

Pro Tips to Meeting Requirements 6.4.3

There are a few tools and processes you can leverage to avoid the common mistakes and ensure your script management practices follow PCI DSS 6.4.3.

1. Implement Dynamic Script  Management Solutions

Use tools (like DataStealth) to dynamically manage and monitor scripts on payment pages. These tools can automatically inventory all scripts, remove unauthorized ones, and validate script integrity tags in real-time. 

‍

This ensures that only necessary and authorized scripts reach the consumer's browser, reducing the risk of malicious activity or compliance gaps.

2. Establish a Robust Authorization and Monitoring Process

Develop a formal process for authorizing scripts before deploying them, including maintaining written justifications for their inclusion. 

‍

Combine this with real-time monitoring solutions to detect unauthorized changes or suspicious script behavior as they occur. This approach ensures compliance with the inventory and integrity requirements

3. Centralize Documentation and Audit Readiness

Maintain a centralized repository for all script-related records, including inventories, authorizations, and monitoring logs. 

‍

Regularly update this documentation to reflect changes in scripts or processes, ensuring it is readily available for audits and demonstrates compliance with PCI DSS requirements

4 Things QSAs Want to See for Requirement 11.6.1

When examining your systems for PCI DSS requirement 11.6.1, a QSA will look at the following:

1. Tamper Detection Mechanisms

QSAs will verify that organizations have deployed robust tamper detection mechanisms to identify unauthorized changes to HTTP headers and payment page contents. 

‍

For some organizations, this may include tools like SRI tags or Content Security Policies (CSPs). However, they don’t address the runtime monitoring or periodic verification checks required under 11.6.1.

‍

QSAs will examine system settings and monitoring logs to confirm that these mechanisms are actively deployed and functioning as intended.

Mistakes to Avoid:

Ineffective or missing mechanisms: Organizations often fail to implement robust tamper detection mechanisms, such as those that monitor HTTP headers and payment page content for unauthorized changes in real-time. Without these, client-side attacks like Magecart skimming can go undetected.

‍

Over-reliance on CSPs alone: While Content Security Policies (CSPs) can restrict domains, they do not monitor script behavior or detect compromised third-party scripts, leaving gaps in protection.

‍

Delayed setup: Many organizations underestimate the complexity of setting up tamper detection mechanisms, leading to incomplete or misconfigured solutions.

2. Alert Mechanism

QSAs will ensure that the tamper detection system generates timely alerts for unauthorized modifications, such as changes, deletions, or additions to payment pages or headers. The alerts must be configured to notify personnel promptly.

‍

QSAs will review the alert configuration settings and logs to confirm that alerts are generated immediately upon detecting suspicious activity and are directed to the appropriate personnel for action.

Mistakes to Avoid:

No real-time alerts: Failing to configure alerts for unauthorized modifications means organizations may remain unaware of breaches until significant damage has occurred.

‍

Excessive false positives: Poorly calibrated systems generate too many false positives, overwhelming teams and causing critical alerts to be ignored or delayed.

‍

Lack of integration with SIEM tools: Alerts that are not integrated into centralized incident management systems (like SIEM) make it harder to respond promptly and effectively.

‍

3. Periodic Reviews

Organizations must conduct periodic reviews of their tamper detection systems at least once every seven days or at intervals determined by a targeted risk analysis in accordance with PCI DSS requirement 12.3.1.

‍

QSAs will check the frequency of reviews and analyze risk assessments to ensure compliance with the defined schedule. They will also verify whether periodic tests validate the effectiveness of the detection mechanisms.

‍

Mistakes to Avoid:

Infrequent monitoring: Some organizations only perform checks weekly or less frequently, which can leave a window for attackers to exploit vulnerabilities undetected.

‍

Failure to conduct risk-based analysis: Not tailoring review frequencies based on the risk profile of systems and environments leads to inadequate monitoring for high-risk components.

‍

Overlooking system updates: Periodic reviews often miss changes in scripts or system configurations introduced by third-party vendors, especially in dynamic environments.

4. Incident Response Mechanism

QSAs will confirm that organizations have a documented incident response plan for handling alerts triggered by tamper detection systems. This plan should include steps for investigating alerts, mitigating risks, and preventing recurrence.

‍

QSAs will review incident response documentation, including records of past incidents, actions taken, and lessons learned. They may also interview staff to evaluate their understanding of response procedures.

Mistakes to Avoid:

Outdated or generic plans: Incident response plans are often outdated, generic, or not tailored to address modern threats like client-side attacks and script tampering.

‍

Lack of testing and training: Many organizations fail to conduct regular tabletop exercises or red-team simulations to test their incident response plans, leaving teams unprepared during actual incidents.

‍

Poor documentation and accountability: Incident response activities are not properly documented, making it difficult to analyze incidents post-mortem or demonstrate compliance during audits.

‍

Pro Tips for Meeting Requirements 11.6.1

Here are a few measures you can take to meet and exceed PCI DSS v4.0 requirements 11.6.1:

1. Deploy Real-Time Tamper Detection and Protection Solutions

Use advanced solutions to implement tamper detection mechanisms that monitor payment page scripts, HTTP headers, and content in real time. 

‍

DataStealth, for example, can dynamically remove unauthorized or high-risk changes to headers and scripts and validate their integrity. It also runs at the DNS layer, which ensures that every type of browser – no matter its version, market adoption, or platform - is covered. 

2. Set Up Comprehensive Alerting and Incident Response Processes

Configure alerts to notify personnel immediately upon detecting unauthorized changes, as required by PCI DSS 11.6.1. These alerts should integrate with incident response plans to ensure swift action.

3. Conduct Regular Reviews and Establish Baselines

Perform periodic reviews of tamper detection systems at least every seven days or based on targeted risk analysis. Establish baseline configurations for payment pages to detect deviations effectively.

Need More Help?

Whether you’re in the middle of reaching compliance or are just starting out, we have a webinar coming up in partnership with the Canadian Cybersecurity Network. 

‍

With a panelist of experts – including veteran QSA Steve Porter - you’ll get a walkthrough of how to meet PCI DSS v4.0 requirements 6.4.3 and 11.6.1. It’s also a great opportunity to ask questions for directions more suited to your specific needs.

Or, if you’re ready to explore what DataStealth can do for your PCI DSS v4.0 compliance needs – especially requirements 6.4.3 and 11.6.1 – then reach out to us today!