PCI DSS Requirement 6.6: Code Reviews, WAFs, and Script Integrity

PCI DSS Requirement 6.6, as it existed under PCI DSS v3.2.1, required merchants to protect public-facing web applications either by conducting manual security reviews of application code or by deploying an automated technical solution such as a web application firewall. That version of the standard was retired on March 31, 2024, and the legacy numbering no longer applies. The protections it covered now sit under several expanded requirements in PCI DSS v4.0.1, which became fully mandatory on March 31, 2025, including all 51 previously future-dated requirements.¹ If you are looking at a checklist, policy document, or vendor pitch that still references Requirement 6.6 by that number, it is out of date.

What Requirement 6.6 Originally Required

Web applications were consistently the initial point of attack in cardholder data breaches, with SQL injection being one of the most common entry methods, which is why the requirement existed in the first place.² The old rule gave merchants a choice between two approaches, and they could use both:

A manual security review in which a qualified professional examines application code and architecture for vulnerabilities. The reviewer had to be organizationally separate from the development team that wrote the code, and change-control processes had to prevent developers from pushing software to production without completing the review.
An automated technical solution: a web application firewall placed in front of the public-facing application to inspect incoming traffic and block common attack patterns in real time.

The underlying goal has not changed under v4.0.1. The obligations around it, however, have grown.

Where Those Protections Live in PCI DSS v4.0.1

The either-or structure is gone. Code review and a firewall are no longer treated as interchangeable alternatives; v4.0.1 demands more layered protections and adds entirely new obligations around scripts running in the customer’s browser. The successor requirements are:

Requirement 6.2.4: software engineering techniques must prevent or mitigate common attacks in custom software, covering injection attacks (SQL, LDAP, XPath), attacks on data structures and buffers, cryptographic weaknesses, business logic abuse including cross-site scripting and cross-site request forgery, and access control bypass attempts.³
Requirement 6.3.2: organizations must maintain an up-to-date inventory of all custom software, including third-party components, and use it to identify and address vulnerabilities.
Requirement 6.4.1: every script loaded and executed in the consumer’s browser on payment pages must be inventoried, authorized with a documented business justification, and validated for integrity through methods like Subresource Integrity or Content Security Policy.
Requirement 11.6.1: a change-detection mechanism must monitor payment page scripts and trigger alerts when unauthorized modifications are detected.

v4.0.1 also introduces a “customized approach” that lets organizations meet the stated security objective of a requirement through alternative controls instead of following the prescriptive steps word for word. This is not the older compensating-controls process. The entity must document a targeted risk analysis, and a Qualified Security Assessor must independently validate that the alternative achieves the same security outcome.⁴

Which Systems Are in Scope

Any application accessible from the internet that touches cardholder data, or could affect the security of a payment transaction, falls in scope. That includes e-commerce storefronts, payment portals, customer login pages, and any system connected to the cardholder data environment. Even applications that never store a card number are in scope if they redirect users to a payment processor and control how that hand-off works.⁵

APIs are a common blind spot. PCI DSS v4.0 explicitly identifies them as requiring the same visibility and protection as traditional web interfaces. If your application uses APIs to transmit payment data, accept tokenized card information, or interact with third-party payment services, those endpoints need the same inventory, testing, and monitoring treatment as any browser-facing page.

Mapping these connections is the first compliance step. Identify every system component located within or connected to the cardholder data environment, including people, processes, and technology. Virtualization components, network devices, and authentication servers that could affect the cardholder data environment if compromised all count.⁵ Scope must also be confirmed annually under Requirement 12.5.2.¹

Code Reviews Under the New Numbering

Manual review remains a core compliance tool. The reviewer must have the skills to understand the source code, evaluate it for vulnerabilities, and interpret the findings. If you use internal reviewers, they must be organizationally separate from the team that wrote the software. A developer cannot sign off on their own code as secure.²

Reviews must happen before any change reaches production, and change-control processes must prevent developers from bypassing that step.² This is where many organizations slip during rapid development cycles. A hotfix pushed straight to production without review creates a compliance gap, even if the fix itself is harmless.

Under Requirement 6.2.4, your development team must use defined engineering techniques to prevent or mitigate the full list of attack categories named in the standard: injection attacks, attacks on data structures and buffers, cryptographic weaknesses, business logic abuse including cross-site scripting and CSRF, and access control bypass attempts.³ The review should test for each.

Web Application Firewalls Still Matter, But Not Alone

A WAF inspects traffic between users and your application, blocking requests that match known attack signatures. It must be configured to detect and prevent common attacks, and its threat intelligence must be kept current so it recognizes newer bypass techniques. Unlike periodic reviews, it provides persistent monitoring that adapts as new threats emerge.

Under the legacy standard, a WAF alone could satisfy Requirement 6.6. Under v4.0.1 it no longer substitutes for the code-level protections in Requirement 6.2.4 or the script-integrity controls in Requirement 6.4.1. Think of it as one layer in a defense that now expects several.

Costs vary widely. Cloud-based WAF services from major providers can start under $100 per month for basic configurations, while enterprise deployments with managed rulesets, bot protection, and DDoS mitigation run considerably higher. The right price depends on your transaction volume, application complexity, and whether you manage the rules yourself or pay for a managed service.

Script Integrity and Change Detection

This is entirely new ground compared to the old rule. Requirements 6.4.1 and 11.6.1 target a class of attacks that barely existed when 6.6 was written: supply-chain compromises in which attackers tamper with third-party JavaScript running on your payment pages. If a tag manager, analytics script, or CDN-hosted library gets modified by an attacker, card data can be skimmed directly from the customer’s browser without your server ever detecting it.

To comply, you need to:

Inventory every script that loads on payment pages, including first-party code, third-party libraries, inline scripts, and anything pulled in by a tag manager.
Document a business justification for each script explaining why it needs to be on the payment page.
Implement integrity validation using techniques like Subresource Integrity hashes, Content Security Policy headers, file checksums, or a client-side security platform that monitors for unauthorized changes.
Deploy change-detection tools that alert your team when any script is modified unexpectedly.

The standard does not mandate a specific technical method. SRI, CSP, and automated monitoring platforms all qualify as long as the approach effectively ensures scripts remain unaltered. The requirement is that you can prove, at any point during an audit, that only authorized and integrity-verified scripts were running on your payment pages.

Documentation You Need to Keep

Proving compliance demands organized evidence: reports from vulnerability scans, findings from code reviews, WAF configuration files, traffic logs, and records of your script inventory and integrity checks. Digital evidence must include timestamps and version-control information so auditors can verify that protections were active throughout the entire reporting period.

Audit logs must be retained for at least one year, with the most recent 90 days readily available for immediate analysis. E-commerce merchants completing SAQ A under v4.0.1 must also now perform quarterly vulnerability scans by an Approved Scanning Vendor, a requirement that did not exist under the previous version.¹

What Non-Compliance Costs

PCI DSS is not a law. It is a contractual obligation between merchants and the card brands, enforced through the acquiring banks. The financial consequences do not depend on that distinction. Card brands can impose fines ranging from $5,000 to $100,000 per month on non-compliant merchants, scaled by transaction volume and how long the non-compliance persists.

After a breach, the costs multiply. An organization can face liability of up to $90 per compromised card record, covering fraud losses, card reissuance, and monitoring. Acquirers can also revoke your merchant account entirely, which for most businesses is an existential problem.

Customers and financial institutions can pursue legal action as well. PCI DSS non-compliance does not automatically create legal liability, but it provides strong evidence of negligence in civil litigation, and class-action settlements following major breaches have run into the hundreds of millions of dollars.

1
PCI Security Standards Council. Now Is the Time for Organizations to Adopt the Future-Dated Requirements of PCI DSS v4.x
2
PCI Security Standards Council. Information Supplement: Requirement 6.6 Code Reviews and Application Firewalls Clarified
3
PCI Security Standards Council. PCI DSS v4.0.1
4
PCI Security Standards Council. PCI DSS v4.0 Compensating Controls vs Customized Approach
5
PCI Security Standards Council. PCI DSS Quick Reference Guide