PCI DSS 4.0 Requirements: What Changed in 2025

PCI DSS 4.0 is the biggest update to payment security standards in over a decade. The PCI Security Standards Council released it in March 2022. As of March 31, 2025, all requirements are mandatory.

If you process, store, or transmit credit card data, you must comply. This guide covers every major change across all 12 PCI DSS requirements and shows you how to implement them.

What Changed and Why

PCI DSS 3.2.1 served the industry well for years, but the threat landscape evolved faster than the standard. PCI DSS 4.0 addresses three fundamental shifts:

Evolving threats. Magecart-style skimming attacks compromised over 2 million cards in 2024 alone, according to Recorded Future. PCI DSS 4.0 adds controls for client-side script management and anti-phishing to address these threats directly.

Cloud and modern architectures. PCI DSS 3.2.1 was written primarily for on-premises environments. Version 4.0 uses technology-agnostic language that applies equally to cloud, hybrid, and containerized environments.

Customized approach. Previously, organizations followed prescriptive controls exactly or documented compensating controls. PCI DSS 4.0 introduces a "customized approach." This lets organizations meet security objectives using alternative methods. The only requirement: you must demonstrate the controls achieve the intended result.

The 12 Requirements: What Stayed and What Changed

PCI DSS 4.0 retains the same 12 high-level requirements but significantly updates the sub-requirements. Here are the most impactful changes in each area.

Requirement 1: Install and Maintain Network Security Controls

Previously: "Install and maintain a firewall configuration." Now: Broadened to "network security controls" (NSCs) to include firewalls, cloud security groups, SDN policies, and other technologies.

Key new sub-requirements:

• Roles and responsibilities for NSC management must be formally documented and assigned
• NSC rulesets must be reviewed at least every six months (previously annually)
• Inbound traffic restrictions must apply at the individual system level, not just the network perimeter

Requirement 2: Apply Secure Configurations to All System Components

Previously: "Do not use vendor-supplied defaults." Now: Broader focus on secure configuration management across all system components.

Key changes:

• Vendor default accounts must be removed, disabled, or have passwords changed before systems go into production
• Primary functions requiring different security levels cannot coexist on the same server (separation requirements strengthened)

Requirement 3: Protect Stored Account Data

Key new sub-requirements:

• SAD (Sensitive Authentication Data) must be encrypted if stored before authorization completion
• Disk-level encryption is only acceptable for removable media. For all other storage, data must be rendered unreadable via cryptographic mechanisms at the data level
• Encryption key management requirements updated to reflect modern cryptographic practices
• Hashing of PAN must use keyed cryptographic hashes (plain hashing no longer acceptable)

Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission

Key changes:

• Certificates used for PAN transmission must be confirmed valid and not expired
• Inventory of trusted keys and certificates required
• Stronger focus on preventing fallback to insecure protocols

Requirement 5: Protect All Systems and Networks from Malicious Software

Previously: "Protect all systems against malware." Now: Expanded scope with specific anti-phishing requirements.

Key new sub-requirements:

• Anti-phishing mechanisms required (email filters, link rewriting, DMARC, user training)
• Removable media scanning requirements updated
• Anti-malware solutions must detect and address "behavioral-based" threats, not just signature-based detection
• Periodic malware scans required for systems not commonly affected by malware (if an organization has not deployed continuous anti-malware)

Requirement 6: Develop and Maintain Secure Systems and Software

Key new sub-requirements:

• Bespoke and custom software must be reviewed prior to release via manual or automated code review, or application security testing
• Web application firewalls (WAFs) are now mandatory for public-facing web applications (previously, code review was an alternative)
• Software inventory of bespoke and custom software required
• A method to manage all payment page scripts (to prevent Magecart-style attacks)

Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know

Key changes:

• Access control model must cover all system components, not just cardholder data environments
• Access reviews required every six months (previously implied but not explicit)
• All application and system accounts must have access defined and managed, including service accounts and API keys

Requirement 8: Identify Users and Authenticate Access to System Components

Major changes:

• MFA is required for all access to the CDE, not just remote and administrative access
• Minimum password length increased from 7 to 12 characters (or 8 characters if the system cannot support 12)
• Password complexity requirements: must contain both numeric and alphabetic characters
• Authentication factors must be independent (knowledge + possession + inherence must use separate channels)
• If passwords are the only authentication factor, they must be changed every 90 days OR the organization must implement dynamic security analysis of accounts

Requirement 9: Restrict Physical Access to Cardholder Data

Key changes:

• Point-of-interaction (POI) device inspection frequency must be risk-based
• Visitor log retention reduced from 3 months to a risk-based determination
• Physical access controls for sensitive areas must be reviewed at least every six months

Requirement 10: Log and Monitor All Access to System Components and Cardholder Data

Key new sub-requirements:

• Automated log review mechanisms required (manual review of all logs is no longer sufficient alone)
• Time synchronization technology failures must trigger alerts
• Audit log reviews must be automated for all system components, with manual review limited to follow-up on automated alerts

Requirement 11: Test Security of Systems and Networks Regularly

Key new sub-requirements:

• Internal vulnerability scans must use authenticated scanning
• Multi-tenant service providers must support external penetration testing by customers, or provide evidence of their own testing
• Intrusion detection/prevention required at the network perimeter AND critical points within the CDE
• Change and tamper detection mechanisms for payment pages (complementing Requirement 6.4.3)

Requirement 12: Support Information Security with Organizational Policies and Programs

Key new sub-requirements:

• Targeted risk analysis required for each PCI DSS requirement where the organization has flexibility in how to implement
• Security awareness training must include specific threats relevant to the organization (phishing, social engineering)
• Incident response plan must include response procedures for detection of unauthorized payment page modifications
• PCI DSS scope must be documented and confirmed at least annually (and upon significant changes)

The Customized Approach: Flexibility with Rigor

PCI DSS 4.0 introduces two compliance approaches:

Defined Approach: Follow the prescriptive requirements exactly as written. This is the traditional method and is recommended for most organizations.

Customized Approach: Meet the security objective of a requirement using an alternative control. This is available for organizations with mature security programs and experienced assessors.

| Aspect | Defined Approach | Customized Approach | |--------|-----------------|-------------------| | How to comply | Follow specified testing procedures | Design your own controls | | Documentation | Standard testing procedures | Customized validation plan, controls matrix | | Assessor skill needed | Standard QSA | Experienced QSA with customized approach training | | Best for | Most organizations | Mature security programs, innovative environments | | Risk | Lower (prescriptive guidance) | Higher (requires robust risk analysis) |

Implementation Timeline

Here is the critical timeline:

| Date | Milestone | |------|-----------| | March 2022 | PCI DSS 4.0 published | | March 2024 | PCI DSS 3.2.1 retired. All assessments must use v4.0 | | March 31, 2025 | All requirements effective (including future-dated requirements) |

As of the publication of this guide, all PCI DSS 4.0 requirements are now mandatory. Organizations that have not completed their transition need to act immediately.

Practical Implementation Priorities

If you are still working on full PCI DSS 4.0 compliance, prioritize these areas:

Priority 1: MFA for CDE Access (Requirement 8.4.2)

Deploy MFA for every account with CDE access. This includes service accounts where feasible, application access, and database administration. Choose an MFA solution that supports your environment (hardware tokens for air-gapped systems, app-based authenticators for standard users).

Priority 2: Payment Page Script Management (Requirement 6.4.3)

Implement Content Security Policy (CSP) headers on all payment pages. Maintain an inventory of all authorized scripts. Set up integrity monitoring (Subresource Integrity hashes) and alerting for unauthorized changes. This directly prevents the Magecart-style attacks that have compromised millions of cards.

Priority 3: Targeted Risk Analysis (Requirement 12.3.1)

For every requirement where PCI DSS 4.0 gives you flexibility (e.g., scanning frequency, password change intervals), document a targeted risk analysis that justifies your chosen approach. This is required documentation that assessors will request.

Priority 4: Automated Log Review (Requirement 10.4.1.1)

Deploy or configure a SIEM or log aggregation platform that automates log analysis. Manual-only log review no longer meets the standard. The system must be capable of detecting anomalies and generating alerts.

Priority 5: Authenticated Internal Vulnerability Scanning (Requirement 11.3.1.2)

Update your vulnerability scanning program to use authenticated scans internally. Unauthenticated scans miss up to 60% of vulnerabilities according to Qualys research. Authenticated scans catch software versioning and configuration issues that surface scans cannot detect.

How PCI DSS 4.0 Relates to Other Frameworks

If you are already compliant with other frameworks, many PCI DSS 4.0 controls overlap:

• SOC 2: Access controls, change management, monitoring, and incident response have significant overlap
• NIST CSF: The NIST CSF Protect and Detect functions map closely to PCI DSS requirements 1-8 and 10-11
• ISO 27001: Annex A controls cover most of the same domains, though PCI DSS is more prescriptive for cardholder data
• HIPAA: Technical safeguard requirements (encryption, access controls, audit logging) are similar in spirit

Organizations pursuing multi-framework compliance should leverage a GRC platform that maps controls across standards automatically.

Frequently Asked Questions

Who needs to comply with PCI DSS 4.0?

Any organization that stores, processes, or transmits cardholder data from major card brands: Visa, Mastercard, American Express, Discover, and JCB. This includes merchants, payment processors, acquirers, issuers, and service providers. The scope applies regardless of transaction volume. However, validation requirements differ by merchant level.

What happens if we are not compliant by the deadline?

Non-compliance can result in fines from $5,000 to $100,000 per month from card brands. You may also face increased transaction fees and mandatory forensic investigations after a breach. In severe cases, you lose the ability to process card payments entirely. The acquiring bank typically passes these penalties to the merchant.

Can we use the customized approach for all requirements?

No. About 20% of requirements are not eligible for the customized approach. These are flagged in the standard with the note "this requirement is not eligible for the customized approach." They tend to be foundational requirements. Your QSA can confirm which specific ones qualify.

How does PCI DSS 4.0 affect cloud environments?

PCI DSS 4.0 is intentionally technology-agnostic. Cloud environments must meet the same security objectives, but the implementation can use cloud-native controls. For example, AWS Security Groups can serve as network security controls under Requirement 1. The key is documenting the shared responsibility model between your organization and the cloud provider.

What is the difference between PCI DSS 4.0 and 4.0.1?

PCI DSS 4.0.1 (released June 2024) is a minor revision that corrected errata, clarified applicability notes, and fixed formatting issues. It does not introduce new requirements. If you are implementing PCI DSS 4.0, the 4.0.1 corrections are incorporated automatically.

How often do we need to revalidate PCI DSS compliance?

Merchants must revalidate annually via either a Report on Compliance (ROC) performed by a Qualified Security Assessor (QSA) or a Self-Assessment Questionnaire (SAQ), depending on merchant level. Service providers at the highest level must complete an annual ROC. Quarterly network vulnerability scans by an Approved Scanning Vendor (ASV) are also required throughout the year.