PCI DSS 4.0: What It Requires and Who It Applies To

What is PCI DSS 4.0?

PCI DSS 4.0 (Payment Card Industry Data Security Standard, version 4.0) is a global security framework published by the PCI Security Standards Council (PCI-SSC) in March 2022, which governs how organizations must protect payment card data. The standard became the sole active version on March 31, 2024, when PCI DSS 3.2.1 was retired. All "best practice" requirements introduced in 4.0 became fully mandatory on March 31, 2025.

The PCI-SSC was founded in 2006 by American Express, Discover, JCB International, Mastercard, and Visa. It doesn't levy fines directly. Compliance is enforced through contracts between card brands and acquiring banks, which flow down to merchants and service providers through merchant agreements.

Version 4.0 introduced two compliance paths. The traditional "defined approach" uses prescriptive controls: organizations implement each requirement exactly as written. The new "customized approach" lets organizations demonstrate equivalent security through alternative controls, supported by a documented Targeted Risk Analysis (TRA) for each requirement. That's the most significant structural change since the standard was first published.

Three pressures drove the update. Magecart-style e-commerce skimming attacks had caused hundreds of breaches by injecting malicious scripts into payment pages, and existing controls offered no defense against that vector. Cloud infrastructure had become standard but wasn't well-addressed by v3.2.1 controls. And point-in-time compliance assessments were failing: the Verizon Payment Security Report found that only 27.9% of organizations maintained full compliance between assessments in 2019, down from 52.5% in 2017.

PCI DSS 4.0.1, a minor editorial revision published in June 2024, added no new requirements.

Who does PCI DSS 4.0 apply to?

PCI DSS 4.0 applies to any organization that stores, processes, or transmits cardholder data (CHD) or sensitive authentication data (SAD). The scope is broader than most compliance teams initially assume.

Covered entity types include:

• Merchants accepting card payments in any channel: in-store, online, mail order, and telephone order. A small e-commerce startup accepting payments via a third-party processor is still a merchant under PCI DSS.
• Payment processors handling authorization, clearing, or settlement of card transactions
• Acquiring banks and issuing banks when they handle CHD directly
• Payment gateways and payment facilitators
• Service providers that store, process, or transmit CHD on behalf of merchants, including hosting providers, managed security services, and tokenization vendors
• Third-party agents with system access to cardholder data environments (CDEs)

The standard assigns compliance assessment levels based on annual transaction volume:

Jurisdictional scope is global. Any organization processing Visa, Mastercard, Amex, Discover, or JCB cards must comply, regardless of incorporation country or customer location. There's no revenue threshold.

Service provider scope is frequently missed. If your platform touches CHD at any point during processing, you're a service provider subject to more demanding requirements than standard merchant controls.

What does PCI DSS 4.0 require?

PCI DSS 4.0 contains 12 requirements, organized across six security goals. All requirements were mandatory no later than March 31, 2025.

1. Install and maintain network security controls. Formal firewall and router rules, no default vendor credentials, network segmentation between the CDE and all other networks.

2. Apply secure configurations to all system components. Document approved software and configurations. Wireless networks transmitting CHD must use current industry-standard encryption.

3. Protect stored account data. Primary Account Numbers (PANs) must be unreadable via hashing, truncation, tokenization, or encryption. Sensitive authentication data cannot be stored after authorization, even if encrypted.

4. Protect cardholder data during transmission. TLS 1.2 minimum on all transmissions; TLS 1.3 is preferred. SSL and early TLS versions are prohibited outright.

5. Protect against malicious software. Anti-malware required on all commonly attacked systems. New in v4.0: phishing protection mechanisms required. Systems evaluated as not at risk from malware must be reviewed and documented at least every 12 months.

6. Develop and maintain secure systems and software. Critical vulnerability patching within one month. New Requirement 6.4.3 (mandatory March 31, 2025): An authorized inventory of all payment page scripts, with integrity checks and documented business justifications for each. New Requirement 11.6.1: Automated alerting for unauthorized changes to payment page scripts and HTTP headers.

7. Restrict access by business need. Access control lists documented and reviewed at least every six months.

8. Identify and authenticate users. MFA required for all access to the CDE, not just remote access. Minimum password length increased to 12 characters, effective March 31, 2025, up from 7 in v3.2.1.

9. Restrict physical access to cardholder data. Physical security controls on all CDE locations. Point-of-interaction (POI) device inventories maintained, with periodic inspection for tampering.

10. Log and monitor all access. Logs retained for 12 months, with the three most recent months immediately available. Automated log review mechanisms are required under v4.0.

11. Test security regularly. Quarterly internal and external vulnerability scans. Annual penetration testing. New in v4.0 under Requirement 11.3.1.1: internal scans must be authenticated (credentialed).

12. Support information security with policies. Formal information security policy reviewed annually. For each customized approach requirement, a Targeted Risk Analysis must be documented and maintained.

What evidence do regulators expect?

PCI DSS compliance is validated through assessments conducted by Qualified Security Assessors (QSAs) for Level 1 entities, or through Self-Assessment Questionnaires for lower-volume merchants. Here's what an examiner expects to see on assessment day:

• Network diagrams and data flow diagrams showing all cardholder data flows, updated within the past 12 months and signed off by responsible personnel
• System component inventory covering all in-scope assets: servers, cloud instances, containers, and all third-party service providers
• Firewall and router configuration reviews with documented change control procedures and evidence of quarterly reviews
• Cryptographic key management procedures covering generation, distribution, storage, rotation, and destruction of encryption keys
• Penetration test reports from an independent, qualified tester within the past 12 months, with all critical and high findings documented as remediated
• Vulnerability scan results from an Approved Scanning Vendor (ASV) for external scans, and authenticated internal scan results, for the four most recent quarters
• Access control reviews showing CDE user access lists reviewed at least every six months, with immediate revocation procedures documented and evidenced
• Security awareness training records with completion dates for all personnel with CHD access, completed within the past 12 months
• Incident response plan tested within the past 12 months, with current contact lists
• Payment page script inventory (Requirement 6.4.3): a documented, authorized list of all scripts on payment pages with a business justification and integrity validation method for each
• Change management tickets demonstrating that all software changes go through formal change management with a security impact analysis

For customized approach implementations, examiners also review the Targeted Risk Analysis for each relevant requirement, plus independent evidence that the alternative controls were tested against their stated objective.

Common failure modes

The most cited PCI DSS failures aren't technically complex. They're process gaps.

• Scope creep, untracked. Organizations define a CDE, pass an assessment, then add a cloud service or third-party integration that handles CHD without re-scoping. The assessment cycle passes cleanly; the breach happens in the unassessed environment. This was the pattern in the 2014 Home Depot breach, where attackers entered through a third-party vendor's credentials and reached point-of-sale systems that weren't included in the most recent assessment scope.

• Default credentials left in place. Requirement 2 prohibits vendor-supplied defaults on all system components. Many organizations pass assessments while management interfaces on network switches and IoT payment terminals still run factory passwords.

• Payment page script management gaps. Requirement 6.4.3 caught many e-commerce teams unprepared. Marketing and analytics teams routinely deploy dozens of third-party scripts on payment pages (tag managers, A/B testing tools, chat widgets) without security review. Inventorying and integrity-checking all of them was the most operationally disruptive requirement in the v4.0 update.

• Logs collected but never reviewed. The Verizon DBIR consistently documents attacker dwell times in payment card breaches measured in months. That figure only makes sense when log review is inadequate.

• MFA gaps on privileged accounts. Many organizations implemented MFA for remote access only, without extending it to all administrative CDE access, which Requirement 8.4.2 now requires explicitly.

• Third-party service provider validation stopped at the attestation letter. Requirement 12.8.4 requires annual monitoring of each service provider's compliance status. Most organizations collect an attestation and stop, without verifying the scope of the service provider's own assessment.

Penalties for non-compliance

PCI-SSC itself doesn't issue fines. The enforcement mechanism runs through card brand networks and acquiring banks, and the financial exposure is real.

Card brand fines to acquirers: Visa and Mastercard can impose fines on acquiring banks of $5,000 to $100,000 per month for non-compliant merchants. Acquirers pass those costs directly to the merchant, often with added service fees.

Post-breach liability: If a merchant is breached while non-compliant, card brands can charge back fraud losses and assess card replacement costs. Heartland Payment Systems, breached in 2008 with approximately 130 million card records exposed, paid over $140 million in settlements to card brands and financial institutions. The FTC's data security guidance consistently observes that post-breach costs exceed the cost of preventive controls by orders of magnitude.

State attorney general actions: Target Corporation's 2013 breach (40 million card records) resulted in an $18.5 million settlement with 47 state attorneys general in 2017, the largest multi-state data breach settlement at the time. Target's total estimated breach cost exceeded $300 million, including litigation, forensic investigation, and card replacement fees.

Increased assessment requirements: After a confirmed breach, card brands require a forensic investigation by a PCI Forensic Investigator (PFI) at the merchant's cost. Card brands may also require re-assessment at Level 1 ROC standard regardless of the merchant's transaction volume.

There's no grace period once a mandatory effective date passes. All v4.0 requirements have been enforceable since March 31, 2025.

Related regulations and frameworks

PCI DSS 4.0 sits alongside several complementary data protection and payment security frameworks that many covered entities must satisfy simultaneously.

GDPR (EU) and national data protection laws: Cardholder data is personal data under GDPR. A payment card breach triggers GDPR notification obligations (72 hours to supervisory authorities) in parallel with PCI DSS breach response procedures. The two frameworks don't conflict, but they run to different timelines and different audiences. Your legal and compliance teams need to coordinate both.

PSD2 (EU) and the forthcoming PSD3: PSD2 requires Strong Customer Authentication (SCA) for online card payments within the EU, which maps closely to PCI DSS 4.0's expanded MFA requirements. PSD2 governs the authentication method at the point of payment; PCI DSS governs the security of the underlying card data environment. Organizations processing EU card payments need to satisfy both.

DORA (EU): The Digital Operational Resilience Act applies to EU financial entities and covers ICT risk management, incident reporting, and third-party technology risk. Payment processors operating in the EU face both DORA and PCI DSS. DORA addresses organizational ICT resilience; PCI DSS addresses specific controls in the cardholder data environment. The third-party risk provisions in both frameworks overlap and can be assessed together.

ISO 27001 and NIST CSF: Neither is mandatory for PCI DSS compliance, but a certified ISO 27001 Information Security Management System provides a strong control foundation that maps to many PCI DSS requirements. PCI-SSC publishes official crosswalk documents between PCI DSS 4.0 and the NIST CSF for organizations rationalizing their compliance programs.

How FluxForce supports PCI DSS 4.0 compliance

FluxForce's AI agents continuously monitor payment environments for anomalous access patterns, unauthorized script changes, and suspicious transaction behavior, directly addressing PCI DSS 4.0 requirements for real-time monitoring and payment page integrity. The payment gateway security capabilities and AI-powered fraud detection features provide full, auditable decision trails that support the evidence requirements examiners look for in a Report on Compliance. Nova Sentinel and Aiden Flux log every access event and generate the automated alerts Requirement 11.6.1 demands. To see how FluxForce maps to your specific PCI DSS obligations, request a demo.