PCI DSS v4.0 Compliance Guide for Security Teams
PCI DSS v4.0 became mandatory in March 2025. The version 3.2.1 transition period ended, and all organizations handling cardholder data are now subject to the full v4.0 requirement set — including the 64 new requirements that were optional during the transition period.
The new requirements are not cosmetic updates. They address threat patterns — web skimming, phishing, credential abuse — that dominated payment fraud over the past five years. This guide covers the changes that matter most for security teams, what the customized approach option means, and how to scope your cardholder data environment to minimize compliance burden.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts — distilled for practitioners. 50,000+ subscribers. No noise.
CDE Scoping: The Highest-Leverage Compliance Decision
Cardholder data environment (CDE) scoping determines which systems, networks, and people fall within PCI DSS scope. Every system in scope must implement all applicable PCI DSS requirements. Minimizing CDE scope is the highest-leverage compliance cost reduction available.
Three scoping categories: in-scope systems directly store, process, or transmit cardholder data. Connected systems are not in the CDE but connect to CDE systems. Out-of-scope systems have no connectivity to CDE systems and no ability to affect CDE security.
The most effective scope reduction technique is network segmentation. Systems that are segmented from the CDE with validated controls (firewall rules with explicit deny-all default, no direct connectivity paths) can be classified as out of scope. PCI DSS v4.0 Requirement 12.5.2 now explicitly requires annual documentation of how scope was determined and validation that segmentation controls are effective — a change from v3.2.1 that adds rigor to segmentation claims.
For e-commerce organizations, tokenization and third-party payment processing (redirect to a payment provider's hosted payment page rather than accepting card data directly) can reduce CDE scope to zero or near-zero for the merchant's own infrastructure. If your infrastructure never touches full card data, the bulk of PCI DSS requirements do not apply to your systems. The payment provider handles compliance for the payment processing components.
What Actually Changed in v4.0: The Requirements That Matter
The 64 new requirements range from clarifications of existing controls to entirely new control categories. The ones with real implementation implications for security teams fall into five areas.
Requirement 6.4 — Web Application and API Protection now requires that all payment pages in e-commerce environments be protected against web skimming attacks. Specifically, Requirement 6.4.3 requires that all scripts loaded and executed in the consumer's browser for payment pages be authorized (inventory, integrity hash, justification), and Requirement 11.6.1 requires a mechanism to detect unauthorized changes to payment page content, including scripts. This is a direct response to Magecart and similar skimming attack patterns.
Requirement 8.4 — Multi-Factor Authentication: v4.0 requires MFA for all access to the CDE, not just for remote access. This closes a significant gap from v3.2.1, where console and local access to CDE systems was often exempt from MFA. Additionally, phishing-resistant MFA (FIDO2/passkeys) is now specified as the required method for high-risk access scenarios.
Requirement 10.7 — Automated Log Review: v4.0 requires automated mechanisms for detecting and addressing failures of critical security controls. Manual log review processes that were acceptable under v3.2.1 are no longer sufficient for critical controls.
Requirement 12.3 — Targeted Risk Analysis: v4.0 introduces a structured Targeted Risk Analysis requirement for controls where the organization determines review frequency based on risk. Previously, frequencies were prescribed by PCI DSS. Now, organizations must document a risk-based justification for review frequencies that differ from PCI defaults.
The Customized Approach Option
PCI DSS v4.0 introduces a Customized Approach as an alternative to the Defined Approach (implementing controls exactly as specified). Under the Customized Approach, organizations can implement alternative controls that achieve the same security objective as the PCI DSS requirement, provided the alternative is documented, tested, and validated by a QSA.
The Customized Approach is designed for organizations with mature security programs that have implemented controls that exceed PCI DSS requirements in some areas but differ in implementation from the prescribed method. It is not a waiver mechanism — alternative controls must demonstrably meet or exceed the security objective of the original requirement.
For most organizations, the Defined Approach remains the correct path. The Customized Approach requires significantly more documentation, risk analysis, and QSA validation work than simply implementing the prescribed control. It is most appropriate for organizations with specific technical constraints (legacy systems that cannot support the prescribed control implementation) or innovative security architectures that achieve the same objective through different means.
If you are considering the Customized Approach for any requirement, engage your QSA early. QSAs must validate that alternative controls achieve the required objective — their pre-agreement before you build the alternative control is essential. Discovering that your QSA will not accept an alternative approach after you have built it is expensive.
Assessment Levels and Self-Assessment Qualification
PCI DSS applies to all entities that store, process, or transmit cardholder data. Assessment requirements depend on transaction volume.
Level 1 merchants (over 6 million Visa/Mastercard transactions annually) require an annual Report on Compliance (ROC) conducted by a Qualified Security Assessor (QSA) and quarterly network scans by an Approved Scanning Vendor (ASV). Level 2 merchants (1 to 6 million transactions) require an annual Self-Assessment Questionnaire (SAQ) and quarterly ASV scans. Levels 3 and 4 (below 1 million transactions) typically require only SAQ completion and quarterly scans.
For Level 2 through 4 merchants, SAQ type selection determines the requirements applicable to your environment. SAQ A applies to merchants who have fully outsourced payment processing to a third party and have no electronic storage of cardholder data — it covers only 22 requirements. SAQ D covers all 250+ requirements and applies to merchants who store, process, or transmit cardholder data directly. Using the wrong SAQ type is a compliance risk: if you select SAQ A but your implementation does not qualify, you are asserting compliance with controls you have not implemented.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, remediation steps, and every daily briefing.
The bottom line
PCI DSS v4.0's new requirements are operationally significant, not cosmetic. Script authorization for payment pages, phishing-resistant MFA for CDE access, and automated log review represent real engineering work for most organizations. The customized approach option provides flexibility but demands more documentation and QSA coordination than most organizations should take on for their first v4.0 assessment. Scope reduction through tokenization and segmentation remains the highest-leverage compliance strategy.
Frequently asked questions
When did PCI DSS v4.0 become mandatory?
All organizations subject to PCI DSS were required to complete their first v4.0 assessment by March 31, 2025, when the v3.2.1 sunset period ended. Some of the new requirements introduced in v4.0 had a deferred implementation date of March 31, 2025 — those are all now active. There is no longer any valid basis for conducting a v3.2.1 assessment.
What is the difference between a QSA and an ASV?
A Qualified Security Assessor (QSA) is a company certified by the PCI Security Standards Council to perform PCI DSS compliance assessments and produce Reports on Compliance. An Approved Scanning Vendor (ASV) is a company certified to perform external vulnerability scans as required by PCI DSS Requirement 11.3.2. Level 1 merchants require both a QSA for the annual assessment and an ASV for quarterly external scans. Lower-level merchants need an ASV for quarterly scans and complete a Self-Assessment Questionnaire rather than a QSA-conducted ROC.
Does PCI DSS apply to SaaS companies?
PCI DSS applies to any organization that stores, processes, or transmits cardholder data, including SaaS companies whose platforms facilitate payment processing, store payment credentials, or provide infrastructure used in payment flows. SaaS companies that process payments must comply with PCI DSS for their own environments. SaaS companies that provide infrastructure used by payment processors may be in scope as third-party service providers, requiring a Service Provider ROC or SAQ rather than a merchant-level assessment.
What is a PCI DSS targeted risk analysis?
Targeted risk analysis (TRA) is a new v4.0 concept in Requirements 12.3.1 and 12.3.2 that requires organizations to formally document a risk-based justification for the frequency of controls and activities that do not have a fixed frequency specified in PCI DSS. For example, if PCI DSS allows review frequency to be determined by the entity's risk analysis, you must document how you assessed the risk and why your chosen frequency is appropriate. TRA documentation must be reviewed by executive management and retained as audit evidence.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, weekly, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals weekly.