To address stakeholder feedback and questions received since PCI DSS v4.0 was published, the PCI Security Standards Council (PCI SSC) has published a limited revision to the standard, PCI DSS v4.0.1. It includes corrections to formatting and typographical errors and clarifies the focus and intent of some of the requirements and guidance. There are no additional or deleted requirements in this revision.
TL;DR
- Requirement 6.4.3 mandates inventorying all payment page scripts. Teams must maintain a current, accurate inventory of every JavaScript file that loads on payment pages.
- Requirement 11.6.1 enforces change detection for payment page scripts. Organizations must detect and alert on any unauthorized modifications or additions to scripts.
- Manual methods like spreadsheets or CSP whitelists can’t keep up. They miss dynamic changes and third-party scripts that load post-initial render.
- Client-side visibility is now critical for PCI compliance. Compliance teams need real-time insight into what executes in the browser to meet these requirements.
- Feroot’s PaymentGuard AI automates both PCI 6.4.3 and 11.6.1. It continuously inventories scripts and detects unauthorized changes on payment pages—no code changes required.
Introduction
PCI DSS 4 Compliance requires a clear understanding of the latest requirements, particularly Requirement 6.4.3 and 11.6.1, which emphasize the importance of JavaScript monitoring for maintaining secure payment environments. For AppSec, Infosec, or ISA/QSA professionals, staying on top of PCI DSS 4.0.1 can feel overwhelming, but protecting payment card data leaves no room for errors. This guide breaks down what Requirements 6.4.3 and 11.6.1 entail, how to effectively address them, and strategies to keep your ROC airtight and audit-ready.
Understanding the Core PCI DSS 4 Requirements
Requirement 6.4.3: What It Means
PCI DSS 4.0.1 Requirement 6.4.3 zeroes in on maintaining a clear handle on any changes to your web environment—especially scripts running on payment pages. At a high level, it demands that all externally hosted JavaScript (or third-party scripts) are inventoried, monitored, and controlled to prevent malicious tampering.
Key Takeaways for 6.4.3
- You need a formal process for identifying all scripts and ensuring each one is authorized.
- Constantly verify the integrity of these scripts to avoid introducing vulnerabilities.
- Keep an eye on any script changes (like version updates or new script additions) so you can act quickly if something unexpected happens.
Requirement 11.6.1: Why It’s Critical
Requirement 11.6.1 builds on the idea of continuous monitoring by focusing on how you detect unauthorized changes to critical web pages and scripts in real time. It’s all about quickly catching (and blocking) suspicious activities.
Key Takeaways for 11.6.1
- Implement technical controls that monitor for tampered or unapproved scripts.
- Set up alerts or notifications so your security team knows right away if scripts behave oddly.
- Document how you investigate and respond to these alerts to prove compliance.
Key Compliance Checkpoints and Deadlines
When it comes to staying compliant, timing is everything. Make sure you’re up to date on PCI DSS 4.0’s official deadlines. That typically means:
- Updating your policies and procedures now to align with the new requirements.
- Completing any system or tool upgrades as soon as possible (or by any mandated deadlines).
- Training your teams on new processes to ensure they know exactly what to do when a script is changed or flagged.
Essential Components for Full Compliance
JavaScript Inventory Management
Having a solid JavaScript inventory management system is the cornerstone of meeting 6.4.3. If you can’t see all the scripts you’re running, you can’t properly secure them. My approach is to create a central repository (or use a trusted third-party tool) that automatically tracks:
- Script names and versions
- Script source/host
- Pages on which these scripts run
This way, whenever a script gets updated or replaced, it gets logged and tracked in real time.
Script Behavior Monitoring
For Requirement 11.6.1, monitoring goes beyond just cataloging your scripts—it’s about ensuring they’re behaving the way you expect. A dedicated script monitoring solution can help you:
- Set baseline behavior metrics (like network calls, DOM changes, or data capture).
- Alert on deviations from this baseline.
- Integrate with your SIEM (Security Information and Event Management) system for centralized visibility.
Documentation and Audit Trails
No matter how much I automate, I always make sure there’s a human-readable paper trail. Well-organized documentation is often your best friend during audits. Make sure you:
- Keep records of all authorized scripts and any changes.
- Document your incident response process for suspicious script activity.
- Regularly review (and update) your documentation as your environment evolves.
Compliance Validation and Reporting
Required Report Types and Frequencies
To prove compliance, you’ll need to generate certain reports on a scheduled basis—often quarterly or annually, depending on the nature of your business. These might include:
- Change Management Reports: Showcasing when and why scripts were updated or replaced.
- Incident Response Logs: Summaries of any alerts, investigations, and resolutions.
- Inventory Reports: Listing of all active and inactive scripts across your sites.
Documentation Requirements for Audits
Auditors often ask for evidence that you’re consistently following your documented processes. Personally, I find it helpful to store all relevant artifacts—like policy docs, inventory spreadsheets, and monitoring logs—centrally. That makes it easier to produce evidence quickly when the auditors come knocking.
Evidence Collection and Retention Strategies
Compliance is never a one-and-done exercise. You’ll need to retain records for a set period (often up to a year or more), so plan ahead. Think about:
- Cloud Storage: Ensuring backup and redundancy.
- Tagging/Labeling: Making it easier to retrieve logs during an audit.
- Automated Retention Policies: Automatically archiving older records to keep storage manageable.
Wrapping Up
Meeting PCI DSS 4.0 Requirements 6.4.3 and 11.6.1 is all about visibility and control. With a solid JavaScript inventory, robust script behavior monitoring, and thorough documentation, you’ll be well-positioned to fend off threats—and prove that you’re doing so. As with anything in the compliance world, the best time to start is now. So take it step by step, lock down those scripts, and show auditors you’re serious about protecting cardholder data.
FAQ
What does PCI DSS 4.0 Requirement 6.4.3 actually require?
It requires organizations to maintain a complete inventory of all scripts that load on payment pages—whether first-party or third-party—and justify their business purpose.
How does Requirement 11.6.1 differ from 6.4.3?
While 6.4.3 focuses on script inventory, 11.6.1 requires organizations to detect and alert on unauthorized script changes in real time to prevent malicious tampering.
Why are these requirements difficult to meet with traditional tools?
Legacy CSPs, SRI, or manual audits often fail to detect dynamically injected scripts or shadow code. They also don’t provide continuous monitoring or alerting.
How does Feroot help automate compliance with 6.4.3 and 11.6.1?
Feroot PaymentGuard AI provides real-time inventory and change detection for every script on your payment pages. It maps each script to PCI controls and generates audit-ready reports.
Can Feroot be deployed without changing our code or infrastructure?
Yes. Feroot is a no-code browser-side security solution that can be deployed quickly without changes to your application stack.
