Guide: Continue Working on 6.4.3/11.6.1 or Focus on Qualifying Under SAQ A?
The March 31st, 2025 enforcement deadline is fast approaching, after which, PCI DSS requirements 6.4.3 and 11.6.1 will go from being best practices to mandatory.
Until recently, every merchant with an online payment page was required to comply with requirements 6.4.3 and 11.6.1 at the enforcement deadline.
Requirement 6.4.3 mandates that merchants authorize and justify each script executed in the consumer’s browser and implement mechanisms to detect and prevent tampering of scripts on payment pages, ensuring the integrity of the code that interacts with cardholder data (CHD).
Requirement 11.6.1 requires merchants to monitor for unauthorized changes to both scripts and security-impacting HTTP headers of payment pages, providing alerts when tampering is detected.
Organizations must meet these requirements ahead of the enforcement deadline to avoid compliance gaps, which can lead to regulatory penalties, reputational damage, and an increased risk of data breaches.
On January 31st, 2025, the PCI Security Standards Council (PCI SSC) published a big update to the eligibility criteria under SAQ A that could exempt certain merchants from requirements 6.4.3 and 11.6.1 if they meet two conditions:
“All elements of the payment page(s)/form(s) delivered to the customer’s browser originate only and directly from a PCI DSS compliant TPSP/payment processor.”
“The merchant has confirmed that their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).”
These changes for SAQ A merchants, further qualified with FAQ 1588, could potentially create a new opportunity for SAQ A-EP and SAQ D merchants. Currently, these merchants will still need to comply with requirements 6.43 and 11.6.1, but with a targeted strategy, they could potentially shift to SAQ A, thereby greatly simplifying their PCI DSS compliance lift. However, this is not a short-term change, it will require time to make the shift to SAQ A.
This guide explores both strategies to help you determine whether to continue focusing on 6.4.3 and 11.6.1 or pursue SAQ-A by reducing the number of systems in scope for PCI DSS compliance..
Table of Contents
When to Focus on Requirements 6.4.3 and 11.6.1
Requirement 6.4.3: Script Controls
Requirement 11.6.1: Monitoring Solutions
How to Effectively Comply With Requirements 6.4.3 and 11.6.1
When Should You Consider Reducing Your Audit Scope to SAQ-A?
When You Could Leverage Both
General Considerations
There is no one-size-fits-all solution. Every merchant is different, with unique needs, processes, and workflows. For example, some businesses still use legacy payment methods, such as fax-based credit card processing. This system would, by default, require the merchant to manage cardholder data (CHD) in their environment. Hence, executing on a strategy that reduces their audit scope may not allow them to reach their goal, at least in the short-term.
At DataStealth, our starting point is to closely examine how each organization’s payment flows work and, in turn, provide a tailored solution.
- First, we analyze the organization's payment flows and internal processes,
- Then, using industry best practices, we develop a tailored plan that aligns with the merchant's business complexities and compliance goals.
The plan can focus on:
- Meeting requirements 6.4.3 and 11.6.1,
- Working towards audit scope reduction over the long term,
- Or a combination of the two, which could set you up for both near-term and long-term success.
Contact us for a personalized review of your requirements and a custom plan for your PCI DSS compliance needs.
When to Focus on Requirements 6.4.3 and 11.6.1
PCI DSS v4.0 requirements 6.4.3 and 11.6.1 represent a major shift in online payment security, targeting client-side threats like e-skimming (e.g., Magecart attacks) that have led to hundreds of millions of dollars in losses for businesses worldwide.
With the March 31st, 2025 enforcement deadline approaching rapidly, organizations cannot defer compliance until their next audit cycle. Full implementation of 6.4.3 and 11.6.1 is mandatory by March 31st, even if your next audit is due after the enforcement deadline.
While the PCI SSC has adjusted the eligibility criteria for merchants completing SAQ A, many organizations complete a SAQ D or SAQ A-EP. These merchants typically handle payment processing directly, placing their systems under PCI DSS scope. Therefore, they must comply with requirements 6.4.3 and 11.6.1.
Requirement 6.4.3: Script Controls
The objective of requirement 6.4.3 is to ensure that all of the scripts on your payment pages are inventoried.
In addition to inventorying all scripts, you must also set up a method to:
- Confirm that each script is authorized to execute in the consumer’s browser,
- Provide the business or technical justification in writing for each script, and
- Ensure the integrity of each script.
Script Inventory Creation
When inventorying your scripts, you must account for all script types, including inline first- and third-party scripts, such as Google Analytics, Meta Pixel, call-to-action (CTA) plugins, and so on, including their dependencies. Practically speaking, you may need to work with non-IT teams, such as Marketing and others, to produce a complete inventory of your payment page scripts and obtain technical/business justifications.
Script Integrity Checks and Authorization
The PCI DSS guidelines suggest using Content Security Policies (CSP) and Subresource Integrity (SRI) tags to help meet both requirements 6.4.3 and 11.6.1. However, while CSPs and SRIs offer a starting point, they alone are not enough to properly meet these requirements.
In addition to technical gaps, relying solely on CSPs and SRIs may not be the most effective use of your resources. For example, you could end up with very large volumes of CSP reports which must be reviewed manually. You may also have to manually triage script changes, which can amount to the hundreds on some websites.
When relying on too many manual processes or workflows, you may end-up exposed to more errors and, in turn, compliance gaps.
Requirement 11.6.1: Monitoring Solutions
Under requirement 11.6.1, organizations must introduce mechanisms to monitor both headers and scripts for unauthorized changes. The baseline requirement is to perform an audit every seven days (unless defined otherwise by a risk analysis).
CSPs may help partly address this requirement, but you will need specialized solutions to fully monitor your headers and scripts for unauthorized changes.
How to Effectively Comply With Requirements 6.4.3 and 11.6.1
CSPs and SRIs provide a starting point, however, whether standalone or combined, they are not enough to meet requirements 6.4.3 and 11.6.1 at scale. On their own, these solutions will lead you to adopt many manual processes that may not be an effective use of your internal resources – assuming you can sustainably support those manual workflows in the first place.
Fortunately, there are solutions on the market that automate both script authorization as well as script and header monitoring, freeing your internal teams to focus on their other priorities. But as you can see from the chart below, not all solutions address the full scope of requirements 6.4.3 and 11.6.1.
Rather, only DataStealth’s E-Skimming Protection solution credibly addresses each specific requirement under 6.4.3 and 11.6.1.
In addition to evaluating how well a solution technically complies with requirements 6.4.3 and 11.6.1, you should also evaluate how easy it is to roll out the solution in your organization and how well it shields your payment pages from cyber threats.
Overall, DataStealth’s E-Skimming Protection solution uniquely provides complete coverage for requirements 6.4.3 and 11.6.1 through real-time content inspection before browser delivery. In contrast, other solutions leave gaps in automation, coverage, and protection effectiveness.
Moreover, our E-Skimming Protection solution offers a way to comply with requirements 6.4.3 and 11.6.1 within a short timeframe without the need to install code or change your applications. With DataStealth, all it takes is a simple DNS change.
When Should You Consider Reducing Your Audit Scope to SAQ-A?
Organizations that currently qualify under SAQ D or SAQ A-EP can consider streamlining their long-term compliance requirements by qualifying under SAQ A. This shift could be particularly appealing now that the PCI adjusted the eligibility criteria for SAQ A wherein merchants could gain exemptions to requirements 6.4.3 and 11.6.1 if they “confirm their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).”
Eligibility Criteria for SAQ A
To qualify for SAQ A under PCI DSS v4.0, an organization must:
- Fully outsource all cardholder data (CHD) functions to PCI DSS-validate third-party service providers (TPSP).
- Ensure no electronic storage, processing, or transmission of CHD occurs on the merchant’s systems or premises.
- Only handle card-not-present transactions.
If SAQ A merchants want to mark requirements 6.4.3 and 11.6.1 as “Not Applicable”, they must confirm that their “site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).” This would require applying script monitoring solutions on the payment page(s).
How DataStealth’s Audit Scope Reduction Solution Helps
Transitioning from SAQ D (252 requirements) or SAQ A-EP (151 requirements) to SAQ A (31 requirements) can significantly streamline the PCI DSS compliance burden. DataStealth’s Audit Scope Reduction services can simplify the path to qualifying for SAQ A by:
1. Eliminating Cardholder Data from Merchant Systems
DataStealth tokenizes payment card data before it enters the merchant’s environment and then de-tokenizes the data when it’s on the way to external counterparties, such as a payment processor or credit bureau, ensuring no sensitive data resides in the merchant’s systems. This eliminates CHD from the audit scope, satisfying one of the eligibility criteria for SAQ A.
Moreover, DataStealth is a Service Provider Level 1 audited annually by a QSA, which allows us to provide you with an Attestation of Compliance (AoC) and responsibility matrix.
2. Prioritizing Security and Compliance by Preventing the Tampering of Scripts
DataStealth takes a proactive approach by actively preventing malicious scripts from reaching the consumer’s browser, rather than only detecting and relying on the consumer’s browser to block their execution. Our proactive blocking ensures the payment page's integrity, which keeps it secure from threats and maintains your compliance posture.
3. Implementing Tamper Detection
DataStealth continuously monitors security-impacting HTTP headers and payment page scripts in real-time, instantly detecting and alerting on unauthorized changes. It blocks tampered content before it reaches the consumer’s browser, ensuring compliance with tamper-detection mandates.
This proactive approach allows organizations to demonstrate that their site is secure against script-based attacks.
When You Could Leverage Both
Every merchant is different and functions using unique processes and workflows. The best way to find the right approach for your organization is to start a consultation process with a trusted data security partner like DataStealth.
However, one of DataStealth’s unique capabilities is that it addresses both short-term and long-term strategies, i.e., meet requirements 6.4.3 and 11.6.1 by the enforcement deadline, then simplify your long-term compliance obligations.
In other words, DataStealth is the only provider to deliver robust compliance and security while reducing your long-term regulatory burden. Implement our solution to secure your environment against current and future threats, and stay ahead of evolving compliance requirements.
Next Steps
Reach out to our team today to understand your next steps to secure your environment, meet your pressing compliance needs, and reduce your compliance burden.
.jpg)
