How to comply with PCI DSS 4.0.1 - 6.4.3 and 11.6.1
cside allows you to manage and comply with both requirements.
Understanding PCI DSS 4.0.1
The Payment Card Industry Data Security Standard (PCI DSS) is a set of guidelines that ensures the safety of card transactions globally. Created by the PCI Security Standards Council, its goal is to protect against data theft and fraud in debit and credit card transactions.
PCI DSS 4.0.1 applies to all entities that store, process, or transmit cardholder data (CHD) and/or sensitive authentication data (SAD), or could impact the security of the cardholder data environment (CDE). This includes all payment card account processing entities such as merchants, processors, acquirers, issuers, and other service providers. A new addition to 4.0.1 is the monitoring and management of 3rd-party JavaScript, tackled by requirements 6.4.3 and 11.6.1.
January 30th, 2025 Update
On January 30th 2025, the PCI DSS announced an update to requirements 6.4.3 and 11.6.1. Self Assessment Questionnaire level A companies are exempt, although they must confirm their site is not susceptible to attacks from scripts that could affect the merchant's eCommerce system(s).
SAQ A, designed for the least vulnerable merchants, exempts them from certain PCI DSS requirements given they do not store Card Holder Data (CHD). However, continuous monitoring remains critical for security.
How cside ensures PCI DSS compliance
cside automates both requirements 6.4.3 and 11.6.1 with real-time script monitoring, script integrity verification, and full audit-ready reporting.
Understanding PCI-DSS requirements
Requirement 6.4.3
As part of the PCI DSS 4.0.1 additions that have been in effect since March 31, 2025, requirement 6.4.3 demands companies:
- Maintain an inventory of every script running on payment pages.
- Document why each script is needed (business justification).
- Verify script integrity for each script (ensuring it hasn't been altered).
- Detect and alert unauthorized script changes.
What this means in plain English:
On pages that handle sensitive user information (payment cards, health information, PII) you need to have a mechanism in place to monitor 3rd party scripts, what they are doing to your user's browsers, and alert security teams when scripts are behaving suspiciously.
Mandatory since March 31, 2025 for any website that takes digital payments
What is PCI DSS 11.6.1?
As part of the PCI DSS 4.0.1 additions that have been in effect since March 31, 2025, requirement 11.6.1 demands companies:
- Alert personnel to unauthorized changes to HTTP headers and payment page scripts
- Evaluate received HTTP headers and payment pages
- Operate at least weekly or as per the entity's risk analysis (Requirement 12.3.1)
What this means in plain English:
HTTP headers are rules that tell a user's browser how to handle content on a page. Altering those headers (e.g. by a malicious script) can weaken security protections. PCI DSS 11.6.1 requires businesses to have a mechanism that regularly checks (at least once every seven days) for unauthorized header changes and alerts the security team when they occur.
Requires technical monitoring and evaluation capabilities
*Definitions based on PCI DSS v4.0.1 - Jun. 2024. This is the most up to date version as of September 2025. To view official documents visit the PCI SSC library .
Real World Example
The Scenario
The only aim of many traditional solutions is just to check the compliance box, setting aside the highest level of security. Approaches like crawler-based solutions scan periodically and can be evaded. CSPs address source, not payload. Client-side agents can be detected and bypassed.
With cside
cside's solution is sitting between third-party scripts and the browsers. We have the capability to see every script request and payload, providing you with real-time alerts and blocking capabilities before compromising users.
The Result
We provide complete visibility into script behavior, historical tracking, and the ability to detect dynamic or user-specific threats that other solutions miss.
What are the 4 different approaches in the market today?
| Criteria | Why it Matters | What the Consequences Are | CSP | Crawler | JS-Based | Hybrid |
|---|---|---|---|---|---|---|
| Real-time Protection | Attacks can occur between scans or in the excluded data when sampled | Delayed detection = active data breaches | Partial support | No support | Full support | Full support |
| Full Payload Analysis | Ensures deep visibility into malicious behaviors within script code itself | Threats go unnoticed unless the source is known on a threat feed | No support | Partial support | Partial support | Full support |
| Dynamic Threat Detection | Needed for incident response, auditing, and compliance | Avoids trade-offs between performance and security | No support | No support | Partial support | Full support |
| 100% Historical Tracking & Forensics | Needed for incident response, auditing, and compliance | Avoids trade-offs between performance and security | No support | No support | No support | Full support |
| No Performance Impact | Avoids trade-offs between performance and security | Higher page load times can reduce conversions and hurt UX | Full support | Full support | Partial support | Full support |
| Bypass Protection | Stops attackers from circumventing controls via DOM obfuscation or evasion | Stealthy threats continue undetected | No support | No support | No support | Full support |
| Certainty the Script Seen by User is Monitored | Aligns analysis with what actually executes in the browser | Gaps between what's reviewed and what's actually executed | No support | No support | Partial support | Full support |
| AI-driven Script Analysis | Detects novel or evolving threats through behavior modeling | Reliance on manual updates, threat feeds or rules = slow and error-prone detection | No support | No support | No support | Full support |
| Implementation Complexity & Timeline | Impacts time-to-value and internal resource costs | Long deployment timelines reduce agility | high | medium | medium | low |
| Can meet 11.6.1 requirement | 11.6.1 relates to monitoring changes in the security headers as well as the script contents themself | Not monitoring security headers violates 11.6.1. Missing or altered headers signal potential attacks. | No support | No support | Full support | Full support |
Leading companies trust cside
Built for security teams who need visibility inside the browser, cside delivers proven defense against modern client-side attacks while supporting major compliance frameworks. Your trusted partner for regulatory compliance in the browser. We are your trusted partner for securing the last mile of the web.
Visit our Trust Center
GDPR 
SOC 2 
PCI DSS We're one message away
As your partner for web security, we want you to be able to reach us easily. Every customer gets 1:1 access to our team over Slack and Microsoft Teams. We respond in minutes, whether you have a feature request, questions, or ideas.
Get compliant with cside
Start monitoring and securing 3rd party scripts on your websites today. Comply with PCI DSS 4.0.1 requirements 6.4.3 and 11.6.1.
*This page describes product capabilities and how they may support your compliance program. It is not legal advice. Requirements vary by organization and jurisdiction.