How to comply with PCI 6.4.3 and 11.6.1 | Practical guide for security teams

In This Blog:

• Audit expectations for PCI 6.4.3 & 11.6.1
• Examples of attacks and fines
• Comparison of solutions
• Resources for your team (checklists, assessments)

PCI 6.4.3 & 11.6.1 is about one thing: control & visibility over what runs in your user's browser. Specifically on payment pages. These requirements force companies to finally understand what's happening on the client side: Which scripts are loading? Were they approved? Are they behaving suspiciously? Surprisingly, most teams don't have the answers to those questions. They never really had to. And now those teams are racing to comply with PCI DSS 4.0.1 audits. According to Verizon’s 2024 Payment Security Report, the percentage of organizations maintaining full compliance has steadily declined, down to 33% in 2023.

We've worked with a variety of security leaders across eCommerce, Retail, and FinTech to implement PCI compliant solutions for pages that handle sensitive user data (such as payment cards). After seeing the common mistakes and best practices, we compiled a guide from our learnings to make your compliance process easier.

“The technical steps to achieve PCI 6.4.3 & 11.6.1 is something I’m regularly asked to explain to compliance teams. The documents are clear on what is required, but how to implement the mechanisms remains a grey area for security teams to figure out”.

— Simon Wijckmans, Founder, C/Side

What is PCI DSS 6.4.3? 

As part of the PCI DSS 4.0.1 additions that became mandatory on 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 the integrity of 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.

*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.

What is PCI DSS 11.6.1?

As part of the PCI DSS 4.0.1 additions that became mandatory on 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.

PCI DSS 6.4.3 Breakdown and Compliance Steps

Who’s responsible for 6.4.3 & 11.6.1 compliance:

• Developers control which scripts are deployed and maintain the inventory.
• Security teams monitor for suspicious changes and investigate alerts.
• Compliance teams ensure documentation, approvals, and audit trails meet PCI standards.

Methods to achieve 6.4.3 & 11.6.1 compliance:

• Build an in-house solution: Create internal tooling to scrape payment pages, log scripts, analyze script payloads, and alert on changes. This approach requires ongoing engineering time from specialized personnel. 

Use a pre-built tool: A client-side intelligence platform will automatically maintain a live script inventory, provide justifications, and send alerts of unauthorized changes. Reporting features are often purpose built for PCI DSS audits.

What auditors look for in PCI 6.4.3 compliance

1. Maintain an inventory of every script running on payment pages

“I use so many third party scripts, analytic tools, support widgets, polyfills, animation libraries, CDNs. Any of these could go rogue and replace the legit content with a keylogger or worse.” - Edgardo C., Developer
(Quote taken from Cside Review)

Most websites have between 5 to 100+ scripts on their site. A client-side intelligence platform keeps an inventory on all pages (including payment pages on your domain), and shows you the payload of the script on each request. This allows you to see code changes, updates and potentially malicious action. These are organized neatly in a dashboard for stakeholders to gain visibility. While not required by PCI DSS 4.0.1, some platforms also block and alert you on (malicious) changes.

2. Document why each script is needed with a business justification (PCI 6.4.3)

Manually meeting this requirement typically follows this process: 

• 1. Export a list of scripts from a web crawler or browser tool, 2. Identify the owner for each script (internal, vendor), 3. Log everything in a central document (e.g. spreadsheet), 4. Add a text field with a justification of why the script is necessary, 5. Update the document whenever scripts are added, removed, or modified.

A client-side intelligence platform: 

• Stores each justification directly alongside the script in your inventory, ensuring the context is always up to date in a central location. 
• Generates AI-powered justifications for each script. This gives teams a pre-written starting point they can review, approve, or adjust.

3. Verify the integrity of each script to ensure it hasn’t been altered (PCI 6.4.3)

Bad actors can adjust scripts to behave in ways they were not originally intended to. For example: 

• Modifying payment forms to send data to an attacker controlled server (data exfiltration)
• Adding hidden input fields or key loggers to harvest cardholder credentials

This is why proxy-based solutions that analyze JavaScript payloads are crucial. They see each script exactly as it’s executed in the user’s browser. This makes it easy for engineers to understand what the script is doing. AI also filters out the changes and gives insight to what the added or changed functionality might do.

4. Detect and alert unauthorized script changes (PCI 6.4.3)

You need to show auditors how scripts have changed over time. A popular attack technique is to make small tweaks to existing scripts. These tweaks frequently go undetected because security teams don’t (and realistically can’t) manually review every script’s code changes on a continuous basis. An automated monitoring tool will track these changes and log timestamps to give you a clear historical record to reference.

PCI DSS 11.6.1 Breakdown and Compliance Steps

Requirement 11.6.1 is a bit more technical. It states that personnel need to be alerted when the HTTP headers and scripts on payment pages change. This is nearly impossible to do manually. Third-party JavaScript is not designed to sit still. It updates based on user location, browser type, and the time of day. Some scripts need to serve different versions for functionality reasons. So how can you see let alone understand these changes?

1. Alert personnel to unauthorized changes to HTTP headers and payment page scripts (PCI 11.6.1)

HTTP headers are rules that tell a user’s browser how to handle content on a page. If they are changed this poses a security risk. A proxy-based solution sits as a “man in the middle”. It exists between the user’s browser and every script request. This allows you to see execution details and any differences in behavior between separate sessions.

2. Evaluate received HTTP headers and payment pages (PCI 11.6.1)

Evaluating HTTP headers means keeping an eye on things like content security policies. Doing this manually page by page will inevitably lead to missed signals. A client side security tool does it automatically so every header is validated and makes the evaluation process less hands-on for your team.

3. Operate at least weekly or as per the entity's risk analysis (PCI 11.6.1 & 12.3.1)

PCI DSS gives you two options here. Run your checks at least once a week. Or run them more often if your own risk analysis says you should. When done manually you’d need someone to load the payment page, pull the HTTP headers, compare them to last week’s copy, and do the same for the page content. Then document it all every week or more often if your risk profile demands it.

Cside logs the headers every time your page loads so you’re not stuck doing manual comparisons. Reports are sent to your inbox regularly (e.g. weekly) and stored in the platform. This creates a complete paper trial for compliance.

Why PCI Compliance Matters (Examples of Attacks & Fines)

PCI DSS exists to shield internet users from having payment information stolen. More than 72,000 websites were compromised in Q2 2025 alone. If hackers get access to edit code that loads on a browser they can steal more than credit card information. They steal identities. They drain bank accounts. They leave people dealing with a mess that can take months to fix. Following PCI rules helps you avoid fines that range from $5,000 to $100,000. It also protects you from client-side data leaks that costs companies $20 million+ along with losing valuable consumer trust.

Comparison of Tools for PCI 6.4.3 & 11.6.1

Many PCI solutions aim to check the compliance box without delivering true protection to your users. Other solutions use outdated tech, leaving customers surprised when they don’t pass the PCI audits after a multi-month implementation. Make sure your vendor’s solution has been reviewed and approved by an accredited QSA (Qualified Security Assessor).

Different Technical Approaches for PCI 6.4.3 & 11.6.1

The following breakdown is taken from the Client-Side Security Technology Comparison:

Crawler-based approaches scan the page after the fact, and often only periodically. These fail to mimic real user behavior and attackers can easily evade detection by serving clean scripts to crawlers while targeting actual users with malicious payloads.

Content Security Policies (CSPs) are limited in scope. They address the script's source rather than its payload. When the source gets breached, it goes unnoticed. When a dynamic script is used, a Content Security Policy has no way of knowing what that script is actually serving.

Client-Side JS detection (also called Agents) inject monitoring scripts into browsers. They set up traps in order to try and detect malicious JavaScript. Only these traps are usually easily found and as a result avoidable.

All these approaches by alternative tools fail to detect dynamic or user-specific threats, leaving critical gaps in protection. 

Proxy based solutions sit in between the 3rd party script and the browser of the user. Ensuring that we have all the data to make the necessary alerts and even block the script before your user is compromised. This data is made available to you in the dashboard, so you can evaluate and make the necessary changes. 

Cside tackles all of the above mentioned issues by using a proxy solution. This allows us to see every script request and the payload of that code.

Popular Tools for PCI 6.4.3 and 11.6.1

“The detection capabilities we got with C/Side were unlike anything we saw in other products we tested in the past. We would definitely recommend the product for PCI and more.” - Mark D.,
(Quote from G2 Review of Cside)

Get Help from Our Team

Need clarity on PCI 6.4.3 or 11.6.1? Our team can assess blindspots in your current infrastructure and show you how Cside makes compliance easier.

Cside gives you everything you need to pass PCI 6.4.3 and 11.6.1. 

✓ Automatically inventory every script on your payment pages, and track changes in real time.

✓ Store justifications and save hours of time with AI-generated justifications for you to approve or edit. 

✓ Monitor HTTP headers and detects unauthorized modifications, alerting your team instantly.

FAQ’s About PCI 6.4.3 & 11.6.1

Are you exempt from complying with PCI 6.4.3 & 11.6.1? (Self Assessment)

PCI DSS’s January 2025 update to SAQ A introduced possible exemptions from 6.4.3 and 11.6.1, but the criteria are written in vague, high-level terms. In practice, you’d have to prove your payment pages contain no third-party scripts or other dynamic content. This scenario is rare for most merchants. Exemption is extremely difficult to achieve. For a detailed look at the criteria and a visual logic flow you can use to assess your own status, visit our dedicated article “What is an SAQ A and how to apply”.

Shorthand Checklist for PCI 6.4.3 & 11.6.1

For 6.4.3 and 11.6.1 this is the the shorthand checklist we go through on our first conversation with security teams: 

How to Comply with PCI 6.4.3 for free

There aren’t any vendor tools that make you fully PCI compliant for free. Some offer a free trial or a limited free tier but with any significant web traffic you’ll paying usage-based costs. The other option is building a DIY solution in-house. Even if you have the engineering talent available this ends up costing far more than buying an off-the-shelf solution. If you want the technical breakdown of what a DIY path involves see our article: Achieving PCI Compliance Without Buying a Solution.