PCI DSS 4.0 Guide: What's New and How to Comply

PCI DSS 4.0 became the only active version of the standard on March 31, 2024, when version 3.2.1 was officially retired. If your organization processes, stores, or transmits cardholder data, you are now required to comply with v4.0. The changes are substantial — not a minor refresh — and some organizations are still scrambling to close gaps introduced by entirely new requirements.

This guide covers the most important changes, the new compliance approach options, and a practical path to getting compliant.

What Changed from PCI DSS 3.2.1 to 4.0

The Payment Card Industry Security Standards Council overhauled the standard with several goals: address emerging threats, add flexibility for modern architectures, and promote security as a continuous process rather than a point-in-time checkbox.

The Customized Approach

The single biggest structural change in v4.0 is the introduction of the Customized Approach. Under the previous standard, every organization had to implement the exact controls as written. Under v4.0, you can now propose an alternative control that meets the stated security objective of a requirement, as long as you document your reasoning and have it validated by a Qualified Security Assessor (QSA).

This is not a loophole — it requires more documentation and rigor than the standard Defined Approach. But it gives large, mature organizations flexibility to use compensating controls that actually fit their infrastructure rather than bolting on legacy-compatible controls.

New Requirements Introduced in v4.0

Over 60 new requirements were added. The most impactful include:

Multi-Factor Authentication (Requirements 8.4.2 and 8.6.3) MFA is now required for all access to the cardholder data environment (CDE), not just administrator accounts. This closes a gap that allowed non-admin users to authenticate with a single factor.

Password/Passphrase Requirements (Requirement 8.3.6) Minimum password length increases to 12 characters (up from 7). Organizations using passphrases instead of passwords must ensure minimum length is met.

Targeted Risk Analysis (Requirements 12.3.1 and 12.3.2) Organizations must now perform a formal targeted risk analysis for any requirement that allows frequency to be determined by the entity. This means documenting why you chose annual vs. quarterly reviews, what risks informed that decision, and reviewing the analysis periodically.

Phishing-Resistant Authentication (Requirement 8.6.3) Passwords for interactive logins to system components must not be hard-coded or default. More broadly, the standard now pushes toward phishing-resistant MFA like FIDO2/WebAuthn for privileged access.

E-commerce and Phishing Protections (Requirements 6.4.3 and 11.6.1) Payment pages served inline (not iframed) must now implement a mechanism to detect unauthorized script changes. All scripts loaded by the payment page must be inventoried, with a justification for each, and integrity verified. Organizations also need a change and tamper detection mechanism for HTTP headers and page content on payment pages.

Penetration Testing Scope (Requirement 11.4.7) Multi-tenant service providers must provide their customers with penetration testing guidance and evidence that segmentation is effective.

Requirements That Became Best Practices

Some requirements from 3.2.1 became "best practices" under 4.0, meaning they are not yet mandatory. However, these best practices become mandatory requirements on March 31, 2025. Treat them as requirements now — you have no runway.

Key items in this category include the e-commerce script controls (6.4.3, 11.6.1), the enhanced authentication requirements, and several logging requirements.

SAQ vs. ROC: Which Do You Need?

Your validation type depends on how you handle cardholder data and your merchant level.

Self-Assessment Questionnaire (SAQ)

SAQs are available to Level 2, 3, and 4 merchants (and some service providers) who are not required to undergo an on-site assessment. There are multiple SAQ types:

SAQ A: Card-not-present merchants who have fully outsourced all payment processing to PCI-compliant third parties. No electronic storage, processing, or transmission of cardholder data on your systems or premises. This is the most common type for SaaS companies using Stripe or similar processors with hosted payment pages.
SAQ A-EP: E-commerce merchants with partially outsourced payment pages where the merchant's website controls how cardholder data is redirected. Significantly more controls required.
SAQ D: For merchants who do not fit any other SAQ type, or service providers. Covers all requirements — the full standard.

With v4.0, SAQ A now includes the new e-commerce script and tamper detection requirements (6.4.3 and 11.6.1) if your payment page loads any scripts. If you use Stripe.js or similar, you need to ensure your Content Security Policy and subresource integrity configurations are in order.

Report on Compliance (ROC)

Level 1 merchants (processing over 6 million transactions per year) and Level 1 service providers must undergo an on-site assessment by a QSA, resulting in a formal Report on Compliance. A ROC is far more extensive than an SAQ — expect the assessment to take weeks and require significant documentation preparation.

Practical Compliance Timeline

Immediate (now)

Inventory all payment page scripts and document justification for each
Enforce MFA for all CDE access, not just admins
Update password policies to require 12-character minimum
Conduct a gap assessment against all new v4.0 requirements

Within 90 days

Implement change detection for payment page HTTP headers and content
Complete targeted risk analyses for requirements with flexible frequencies
Update your network diagrams and data flow diagrams — v4.0 requires these to be accurate and reviewed at least annually

Before your next assessment

Train your QSA or internal assessor on the Customized Approach if relevant
Update policies and procedures to reference v4.0 requirement numbers
Review third-party service provider agreements for v4.0 compliance attestations

Scoping: The Most Common Gap

Many organizations underestimate their CDE scope. Under v4.0, the Scope section (Requirement 12.5) now explicitly requires an annual scoping exercise and documentation of why specific systems were included or excluded. Connected-to and security-impacting systems are in scope even if they do not directly touch cardholder data.

If you have not performed a formal scoping exercise since upgrading to v4.0, do this first. Everything else builds on scope accuracy.

Continuous Compliance vs. Point-in-Time

A major theme of PCI DSS 4.0 is that compliance should be ongoing, not a once-a-year scramble before your QSA visit. The standard now requires:

Quarterly user access reviews for the CDE
Periodic reviews of security policies and configurations
Continuous monitoring for unauthorized changes to payment pages

Automated tooling that continuously monitors for misconfigurations, exposed credentials, and unauthorized changes will satisfy many of these requirements more reliably than manual processes.

Key Takeaway

PCI DSS 4.0 is not a cosmetic update. The MFA expansion, e-commerce script controls, and targeted risk analysis requirements represent real work for most organizations. Start by identifying your SAQ type, running a formal gap assessment against v4.0, and prioritizing the requirements that became mandatory in March 2025.