PCI DSS v4.0: What Changed and How to Comply

In January 2025, a mid-market e-commerce platform discovered that a JavaScript skimmer had been injecting itself into their payment page for eleven weeks — harvesting card numbers from 340,000 transactions. The attack exploited a supply-chain weakness in a third-party analytics script loaded on the checkout page. Under PCI DSS v3.2.1, there was no explicit requirement to monitor payment page scripts. Under v4.0 Requirement 6.4.3, which became mandatory March 31, 2025, that gap is closed: organizations must maintain an inventory of all scripts on payment pages and implement change-detection mechanisms.

The attack was not sophisticated. The detection gap was structural — a missing control that v4.0 specifically addresses. That is the story of this revision: not abstract risk, but concrete exploits that the previous standard failed to prevent.

Why Now: The March 2025 Deadline Changed Everything

PCI DSS v4.0 enforcement has two critical dates:

March 31, 2024: v3.2.1 retired. All assessments must use v4 (the PCI SSC published a limited revision, v4.0.1, in June 2024, which supersedes v4.0).
March 31, 2025: "Future-dated" requirements became mandatory. These are the net-new controls that had an extra year for implementation.

If you are reading this after March 2025, every v4.0 requirement — including the 60+ new ones — is now enforceable. There is no grace period remaining. Assessors will cite gaps, and acquirers will hold you accountable.

The future-dated requirements that caught organizations off guard:

Requirement 6.4.3: Payment page script inventory and change-detection (the skimmer defense)
Requirement 8.3.6: Minimum 12-character passwords (up from 7)
Requirement 5.4.1: Anti-phishing technical controls
Requirement 10.4.1.1: Automated log review mechanisms
Requirement 12.6.3.1: Security awareness training that addresses current threats

The Structural Shift: Customized Approach

Here is the contrarian take that most PCI consultants undersell: the Customized Approach is the most important change in v4.0, and most organizations should use it for at least some requirements.

Under the Defined Approach (the traditional path), you meet each requirement exactly as specified. Under the Customized Approach, you design your own controls that meet the stated security objective of each requirement. The Customized Approach requires documented risk analysis, evidence that your alternative meets the objective, independent assessor validation, and ongoing monitoring — it is more work upfront, but it eliminates the compliance theater of implementing controls that technically satisfy the letter of a requirement while missing the spirit.

For organizations managing PCI DSS alongside CMMC, SOC 2, or ISO 27001, the Customized Approach lets you use your existing control implementations from those frameworks to satisfy PCI objectives without redundant, PCI-specific mechanisms that add complexity without adding security.

The 12 Requirements: What Changed

#	Requirement	Key v4.0 Changes
1	Network security controls	Expanded beyond firewalls to cloud security groups, SDN, microsegmentation
2	Secure configurations	Application defaults explicitly included; hardening standards required for all component types
3	Protect stored account data	Disk-level encryption alone insufficient; keyed cryptographic hashing for PAN
4	Protect data in transit	TLS 1.2 minimum enforced universally; certificate inventory required
5	Malicious software protection	Anti-phishing mechanisms now mandatory (5.4.1)
6	Secure systems and software	Payment page script management (6.4.3); broader WAF requirements
7	Restrict access by need to know	Role-based access reviews every 6 months; application account privilege review
8	Identify and authenticate	MFA for all CDE access (not just remote); 12-character minimum; service account rotation
9	Physical access	Updated for cloud and hybrid; media destruction verification
10	Log and monitor	Automated log review required (10.4.1.1); time sync with authoritative source
11	Test security regularly	Authenticated internal vulnerability scanning; multi-tenant service provider penetration testing
12	Policies and governance	Targeted risk analysis for customized approach; annual scope validation

Deep Dive: The Requirements That Break Organizations

MFA for All CDE Access (Requirement 8.4.2)

v3.2.1 required MFA only for remote access to the CDE. v4.0 extends this to all access — local administrators walking up to a console, developers accessing production databases, operations staff on the data center floor. This catches organizations that implemented "MFA for VPN" and called it done.

The implementation challenge: legacy payment terminals and batch processing systems that predate MFA support. Compensating controls exist but require documented risk analysis under the Customized Approach.

12-Character Passwords (Requirement 8.3.6)

The minimum jumped from 7 to 12 characters. This sounds trivial but breaks legacy systems with hard-coded 8-character limits — mainframe interfaces, terminal emulators, older payment applications. You cannot simply change a Group Policy setting if the downstream application truncates at 8.

Payment Page Script Management (Requirement 6.4.3)

Every script executed on payment pages must be inventoried, authorized, and monitored for changes. This means:

Maintaining a complete list of all JavaScript loaded on checkout pages
Implementing integrity monitoring (Subresource Integrity hashes or Content Security Policy)
Detecting unauthorized modifications to scripts or HTTP headers
Alerting on new or modified scripts within a defined timeframe

This is the Magecart defense. It requires continuous monitoring, not periodic assessment.

Automated Log Review (Requirement 10.4.1.1)

Manual daily log review was accepted under v3.2.1. v4.0 requires automated mechanisms — SIEM correlation rules, behavioral analytics, or equivalent automated alerting. "An analyst reads the logs every morning" no longer satisfies the requirement. The automated system must generate alerts for suspicious activity, and those alerts must be investigated within defined timeframes.

Anti-Phishing Controls (Requirement 5.4.1)

New to v4.0: organizations must implement technical controls to detect and block phishing attacks targeting personnel. This goes beyond awareness training (which is also required) into technical mechanisms — email filtering, link analysis, attachment sandboxing, DMARC enforcement.

Self-Assessment Questionnaires

For merchants not requiring an on-site QSA assessment, v4.0 updated the SAQ structure:

SAQ	Who Uses It	Scope
SAQ A	E-commerce using iframe/redirect (no card data touches your systems)	Minimal — confirm third-party security, script controls
SAQ A-EP	E-commerce where your systems affect transaction security	Moderate — web server hardening, script management
SAQ B	Standalone terminals (imprint machines, dial-out)	Limited — physical and personnel controls
SAQ C	Internet-connected payment terminals	Moderate — network security, terminal hardening
SAQ D	Everyone else (merchants and service providers)	Full — all applicable requirements

Note that SAQ A now includes Requirement 6.4.3 (script management) — even merchants who never touch card data must monitor scripts on their redirect pages. This caught many SAQ A merchants off guard in 2025.

Compliance Path

Step 1: Validate Your Scope

Identify every system, network, person, and process that stores, processes, or transmits cardholder data, or that could affect the security of cardholder data. This is your Cardholder Data Environment (CDE). v4.0 requires annual scope validation (Requirement 12.5.2) — not a one-time exercise.

Step 2: Choose Defined vs. Customized

For each requirement, decide whether to meet it exactly as specified (Defined) or design an alternative control meeting the objective (Customized). Most organizations use Defined for the majority, with Customized for requirements where existing controls from other frameworks already satisfy the objective.

Step 3: Address the Net-New Requirements

Focus remediation on the 60+ new requirements, particularly the future-dated ones that became mandatory in March 2025:

MFA for all CDE access (not just remote)
12-character passwords across all CDE systems
Payment page script inventory and monitoring
Automated log review mechanisms
Anti-phishing technical controls
Targeted risk analysis documentation

Step 4: Implement Continuous Monitoring

v4.0 shifts PCI from a point-in-time assessment toward continuous compliance. Multiple requirements now specify ongoing monitoring rather than periodic checks. Build the automation before assessment, not after — assessors will look for evidence of continuous operation, not just a clean snapshot.

Step 5: Validate

Complete your SAQ or engage a Qualified Security Assessor (QSA) for a Report on Compliance (ROC). Under v4.0, the assessor evaluates not just current state but evidence of sustained operation over the assessment period.

PCI DSS and Multi-Framework Programs

Organizations managing PCI DSS alongside federal or enterprise frameworks benefit from significant control overlap:

SOC 2: ~65% overlap in access control, logging, change management, and vulnerability management
ISO 27001: ~55% overlap across information security controls
NIST 800-53: Substantial overlap in AC, AU, CM, IA, and SC families
CMMC: ~50% overlap in access control, encryption, audit, and incident response

The Customized Approach explicitly supports using controls implemented for other frameworks to satisfy PCI objectives — making multi-framework compliance more achievable than under v3.2.1.

Key Takeaways

All v4.0 requirements including future-dated ones are mandatory as of March 31, 2025 — no grace period remains

The Customized Approach lets existing controls from other frameworks satisfy PCI objectives without redundant implementation

Payment page script management (6.4.3) is the Magecart defense — inventory, authorize, and monitor every script on checkout

MFA extends to all CDE access (local and remote), 12-character passwords replace the old 7-character minimum

Automated log review is now required; manual daily review alone does not satisfy 10.4.1.1

SAQ A merchants are no longer exempt from script monitoring — scope expanded in v4.0

Frequently Asked Questions

Is PCI DSS v3.2.1 still valid for any purpose?

No. v3.2.1 was fully retired on March 31, 2024. All assessments, SAQs, and compliance validations must use the v4 standard -- v4.0.1, the limited revision published in June 2024, is the current version. Historical ROCs under v3.2.1 remain valid for their stated period but cannot be renewed or extended under the old version.

What is the difference between Defined Approach and Customized Approach?

The Defined Approach requires meeting each requirement exactly as written — the traditional compliance path. The Customized Approach allows you to implement alternative controls that meet the stated security objective of each requirement, with documented risk analysis and assessor validation. Customized is more flexible but requires more evidence and ongoing monitoring. Most organizations blend both, using Defined for straightforward requirements and Customized where existing controls from other frameworks already satisfy the objective.

Do the new requirements apply to SAQ A merchants?

Yes, partially. SAQ A now includes Requirement 6.4.3 (payment page script management) even though SAQ A merchants do not directly handle card data. If your checkout page loads any third-party scripts — analytics, chat widgets, marketing pixels — you must inventory and monitor them. This was the most surprising scope expansion in v4.0 for small merchants.

How does targeted risk analysis work?

Several v4.0 requirements allow organizations to determine appropriate frequency or scope through documented risk analysis rather than mandated intervals. For example, the frequency of log reviews, the scope of penetration testing, and the cycle for awareness training updates can all be risk-justified. The risk analysis must be documented, reviewed annually, and available to your assessor.

Can compensating controls still be used under v4.0?

Compensating controls exist under the Defined Approach when a requirement cannot be met as written due to legitimate technical or business constraints. They require documentation explaining why the requirement cannot be met, what compensating control is in place, and how it provides equivalent security. The Customized Approach is often a better fit for situations that previously required compensating controls, as it was designed specifically for alternative implementations.

How Advisedly Helps

Advisedly maps all PCI DSS v4.0 requirements with implementation guidance for both the Defined and Customized Approaches, tracks compliance status across all 12 requirements in real time, and identifies gaps from v3.2.1 that require remediation. For organizations managing PCI alongside SOC 2, ISO 27001, or federal standards, Advisedly cross-maps controls across 500+ frameworks so that security work done for one standard automatically satisfies applicable PCI objectives — eliminating the duplicate evidence collection and redundant documentation that plagues siloed compliance programs. Contact begin@advisedly.ai