PCI DSS v3.2.1 was officially retired on March 31, 2025. If you process, store, or transmit cardholder data, you are now being assessed against PCI DSS v4.0, whether you are ready or not. The future-dated requirements that organizations had been putting off are now mandatory. The grace period is over.
We have been conducting PCI DSS penetration tests for years, and the number of organizations that reached the deadline without full v4.0 compliance was staggering. If you are one of them, this guide covers what changed, what is now mandatory, and how to get into compliance before your next assessment.
What Actually Changed in v4.0
PCI DSS v4.0 is not a minor revision. It is a fundamental restructuring of how the standard approaches payment security. The PCI Security Standards Council introduced 64 new requirements, reorganized existing ones, and introduced an entirely new compliance approach. Here are the changes that matter most.
The customized approach
v4.0 introduces two paths to compliance: the defined approach (traditional prescriptive controls) and the customized approach. The customized approach lets organizations implement alternative controls that meet the same security objective as the defined requirement. This is powerful for mature organizations but comes with a catch: you must document a targeted risk analysis for every customized control, and your QSA must validate that the alternative control meets the stated objective. In practice, most organizations, especially those pursuing compliance for the first time, should stick with the defined approach.
Enhanced authentication requirements
Requirement 8 now mandates multi-factor authentication for all access to the cardholder data environment (CDE), not just remote access. This means internal administrators, developers with CDE access, and anyone else who touches systems in the CDE must use MFA. Password requirements also changed: minimum 12 characters (up from 7), and the standard now explicitly requires protection against phishing attacks on authentication credentials.
Targeted risk analysis
v3.2.1 had blanket requirements: scan quarterly, test annually, review logs daily. v4.0 replaces many of these fixed frequencies with "as determined by the entity's targeted risk analysis." This sounds more flexible, and it is, but it also means you must document a formal risk analysis justifying your chosen frequency for each requirement that references it. Your QSA will review these risk analyses during assessment.
The Requirements That Are Now Mandatory
Several v4.0 requirements were originally "best practice" until March 31, 2025. They are now fully enforceable. Here are the ones that catch organizations off guard.
| Requirement | What It Mandates | Common Gap |
|---|---|---|
| 3.5.1.2 | Disk-level encryption no longer acceptable for removable media | Organizations still using BitLocker as their only cardholder data encryption |
| 5.3.3 | Anti-malware for removable media must scan automatically on insertion | Many endpoint solutions do not auto-scan removable media by default |
| 5.4.1 | Anti-phishing mechanisms for personnel susceptible to phishing | No email filtering, no DMARC, no user awareness training documented |
| 6.3.2 | Software inventory with vulnerability identification for bespoke/custom software | No SBOM or dependency tracking for custom applications |
| 6.4.2 | WAF for public-facing web apps must detect and prevent web-based attacks | WAF deployed in monitoring-only mode or misconfigured rulesets |
| 8.4.2 | MFA for all access to the CDE, not just remote | Internal admin access to CDE systems without MFA |
| 8.6.3 | Passwords for application and system accounts managed and changed periodically | Service accounts with static passwords that have never been rotated |
| 10.4.1.1 | Automated log review mechanisms | Manual log review processes that cannot scale |
| 11.3.1.1 | Internal vulnerability scans must manage all non-critical and non-high vulnerabilities | Organizations only tracking critical and high findings, ignoring medium |
| 11.6.1 | Change and tamper detection for payment page scripts | No mechanism to detect unauthorized changes to payment page JavaScript |
| 12.3.1 | Targeted risk analysis documented for each requirement that allows flexible frequency | No formal risk analyses written, relying on ad-hoc justifications |
The most disruptive requirement: 11.6.1 (payment page script monitoring) is catching the most organizations unprepared. If you accept payments through a web page, you must have a mechanism that detects unauthorized changes to HTTP headers and payment page scripts. This is a direct response to Magecart-style attacks and requires either a Content Security Policy with violation reporting, a subresource integrity checking mechanism, or a dedicated payment page monitoring solution.
What Companies Are Still Getting Wrong
Based on our assessment work since the deadline, these are the areas where organizations are most consistently failing to meet v4.0 requirements.
Scope underestimation
v4.0 expanded the definition of the CDE and connected systems. Cloud environments, containerized workloads, and API integrations that touch cardholder data are explicitly in scope. Organizations that assessed only their traditional on-premises CDE are finding their v4.0 scope is significantly larger than their v3.2.1 scope. If your payment processing involves AWS Lambda functions, Kubernetes pods, or third-party API integrations, those are in scope for assessment and segmentation testing.
Insufficient targeted risk analyses
The targeted risk analysis requirement (12.3.1) is a paradigm shift from v3.2.1's prescriptive frequencies. Organizations must now justify their chosen frequencies for scanning, testing, log review, and other periodic activities through documented risk analyses. Many companies are treating this as a formality and producing one-paragraph justifications. QSAs are rejecting these. A proper targeted risk analysis identifies the assets, threats, and vulnerabilities relevant to the specific requirement and documents why the chosen frequency adequately addresses the risk.
Payment page security
Requirements 6.4.3 and 11.6.1 together create a new obligation for organizations that accept web-based payments. You must maintain an inventory of all scripts on your payment pages, justify the presence of each script, implement integrity checking, and have a mechanism to detect unauthorized changes. Most e-commerce platforms had nothing in place for this when the deadline hit. If you use a third-party payment processor with an embedded iframe, you may have reduced scope here, but you still need to demonstrate that the surrounding page is protected.
Penetration testing gaps
v4.0's Requirement 11.4 refines penetration testing expectations. Testing must cover the entire CDE including cloud components, and segmentation validation must verify that controls effectively isolate the CDE from out-of-scope networks. We are finding that organizations whose previous pentests only covered on-premises systems now need expanded scope to include cloud infrastructure, APIs, and containerized workloads. See our PCI DSS penetration testing guide for the full scope requirements.
The Penalties for Non-Compliance
PCI DSS is not a law. It is a contractual obligation enforced by the payment card brands through your acquiring bank. But the penalties are very real.
Monthly fines: Payment card brands (Visa, Mastercard, American Express, Discover) can assess fines ranging from $5,000 to $100,000 per month against acquiring banks, who pass those fines through to merchants. The fine amount depends on the merchant level, the duration of non-compliance, and whether a breach has occurred.
Increased transaction fees: Non-compliant merchants may face higher per-transaction processing fees, which compounds quickly for high-volume businesses.
Loss of card processing privileges: In extreme cases, payment card brands can revoke an organization's ability to process card payments entirely. For an e-commerce business, this is existential.
Breach liability: If a data breach occurs and the organization is non-compliant, they bear liability for fraudulent transactions, card replacement costs, and forensic investigation expenses. Post-breach forensic investigations alone typically cost $50,000 to $200,000.
The hidden penalty: Beyond direct fines, non-compliance triggers mandatory forensic investigation after any suspected breach. The forensic investigator (a PCI Forensic Investigator or PFI) has broad access to your systems and processes. The investigation is expensive, disruptive, and the findings become part of your compliance record. Organizations that were already compliant before a breach face significantly less scrutiny and lower penalties.
How to Get Into Compliance Now
If you are not yet fully compliant with PCI DSS v4.0, here is the prioritized path forward.
Step 1: Reassess your scope
Map your cardholder data flows completely, including cloud environments, APIs, and third-party integrations. v4.0's expanded scope definition means your CDE may be larger than you think. Document every system that stores, processes, or transmits cardholder data, and every system connected to those systems.
Step 2: Address the formerly future-dated requirements
The table above lists the requirements that became mandatory in March 2025. Prioritize these because they are the most likely gap areas and the first things your QSA will check during your next assessment. MFA for CDE access (8.4.2), payment page security (11.6.1), and automated log review (10.4.1.1) are typically the most effort-intensive to implement.
Step 3: Write your targeted risk analyses
Every requirement that references a targeted risk analysis needs a documented analysis. Use a consistent template across all analyses so your QSA can review them efficiently. Each analysis should identify the requirement, the relevant assets, the threats, the current controls, the residual risk, and the justification for the chosen frequency or approach.
Step 4: Schedule your penetration test
Your v4.0 pentest needs to cover the expanded CDE scope, validate network segmentation, and test both network and application layers. If your last pentest was conducted against v3.2.1 scope, you likely need a new engagement with broader coverage. Budget for this now rather than discovering scope gaps during your QSA assessment.
Step 5: Engage your QSA early
If you have a QSA relationship, engage them for a gap assessment against v4.0 before your formal assessment. Most QSA firms offer gap assessments that identify non-compliance areas without the formal consequences of a failed assessment. This gives you a remediation roadmap and a clear picture of the work remaining.
v4.0 Impact by Merchant Level
The impact of v4.0 varies significantly depending on your merchant level and how you process payments.
| Merchant Level | Transaction Volume | v4.0 Impact | Assessment Type |
|---|---|---|---|
| Level 1 | 6M+ transactions/year | Full v4.0 assessment required. Most affected by expanded requirements | Annual ROC by QSA + quarterly ASV scans |
| Level 2 | 1M-6M transactions/year | Significant impact. May need to upgrade from SAQ to ROC depending on acquirer | Annual SAQ or ROC + quarterly ASV scans |
| Level 3 | 20K-1M e-commerce transactions/year | Moderate impact. Payment page security requirements most relevant | Annual SAQ + quarterly ASV scans |
| Level 4 | Under 20K e-commerce or up to 1M other transactions/year | Lower impact but still must meet v4.0 requirements applicable to their SAQ type | Annual SAQ + quarterly ASV scans (recommended) |
If you are unsure which SAQ type applies to your organization under v4.0, your acquiring bank or QSA can help determine the correct assessment type based on your payment processing methods.
What v4.0 Gets Right
For all the compliance burden, v4.0 genuinely improves payment security in several important ways.
The customized approach encourages security thinking. Instead of blindly checking boxes, organizations using the customized approach must understand the security objective behind each requirement and demonstrate that their implementation meets it. This produces better security outcomes than prescriptive compliance alone.
Payment page security addresses real threats. Magecart and JavaScript-based card skimming attacks have caused billions in fraud losses. Requirements 6.4.3 and 11.6.1 directly address the attack vector that made these breaches possible. This is the standard responding to actual threat intelligence rather than theoretical risks.
MFA everywhere reduces credential compromise risk. The expansion of MFA to all CDE access, not just remote access, closes a significant gap that attackers have exploited through credential theft and lateral movement within internal networks.
Targeted risk analysis enables proportional security. One-size-fits-all frequencies never made sense for organizations with wildly different risk profiles. A startup processing 50,000 transactions a year should not have identical scanning frequencies to a global payment processor handling billions. The targeted risk analysis approach lets organizations calibrate their security activities to their actual risk.
Looking Ahead: What to Expect Next
The PCI SSC has indicated that v4.0 will continue to evolve through minor revisions and guidance documents. Several areas to watch:
- Cloud-specific guidance: The council is developing more detailed guidance for cloud-native payment environments, including serverless architectures and container-based CDE deployments
- AI and machine learning: As AI tools become more prevalent in fraud detection and security monitoring, expect guidance on how AI-based controls satisfy PCI DSS requirements
- Post-quantum cryptography: The standard will eventually need to address the transition to quantum-resistant encryption algorithms, particularly for cardholder data at rest
- Enforcement escalation: Payment card brands are expected to increase enforcement activity through 2026 as the transition period excuse expires. Organizations that have been delaying compliance will face increasing pressure from their acquiring banks
The organizations that treat v4.0 as an opportunity to genuinely improve their payment security, rather than a compliance checkbox to satisfy at minimum effort, will be best positioned for whatever comes next. The standard's shift toward risk-based, objective-driven security is the right direction. The question is whether your organization embraces that direction or fights it.
Need a PCI DSS v4.0 penetration test?
Our PCI DSS penetration tests cover the full v4.0 scope including cloud environments, segmentation validation, and application-layer testing. Reports are structured for QSA review.
