PCI DSS 4.0 became the only valid standard on April 1, 2024. The future-dated requirements activated on March 31, 2025. If you have not finished your 4.0 transition, you are out of compliance with every card brand. Here is what changed and what is still tripping people up.
The four major shifts
1. Customized approach
For the first time, PCI DSS allows organizations to design custom controls instead of meeting the defined approach. You define the objective, document your control, run a targeted risk analysis (TRA), and the QSA validates effectiveness. This is powerful for mature security programs but adds documentation burden.
2. Continuous compliance focus
4.0 explicitly moves away from “annual snapshot” thinking. Requirements like 6.4.3 (script management) and 11.6.1 (change detection on payment pages) require continuous mechanisms, not point-in-time checks. Spreadsheets and quarterly reviews no longer suffice.
3. Targeted risk analyses
Multiple new requirements demand a documented TRA to justify timing, frequency, or scope of activities. Examples: how often you rotate keys, how often you review user access, how often you scan. TRAs need annual review.
4. Stronger authentication
MFA is now required for all access into the cardholder data environment (CDE) – not just remote access. Passwords have stronger length and history requirements (12 character minimum if MFA is in place, 15 if not).
The future-dated requirements that hit in 2025
| Req | What it requires | Common gap |
|---|---|---|
| 6.4.3 | Inventory and approve all scripts loaded on payment pages | Tag managers loading third-party scripts uncontrolled |
| 11.6.1 | Detect tampering and unauthorized changes on payment pages | No tooling deployed; many vendors offer this as a service |
| 10.4.1.1 | Automated mechanisms for log review (not just retention) | Logs collected but not actively analyzed |
| 8.4.2 / 8.5.1 | MFA for all CDE access, including internal admins | Internal jump hosts excluded from MFA |
| 12.10.7 | Documented incident response procedures for stored account data discovery | No written playbook for finding PAN in the wrong place |
Scoping is still where companies lose
The single most expensive PCI DSS mistake is scope creep. Every system that stores, processes, or transmits cardholder data is in scope. So is every system that can connect to those systems. So is every system that manages those systems. Network segmentation properly enforced and tested is the lever that keeps scope manageable.
Segmentation testing
4.0 requires segmentation penetration testing every 6 months for service providers and annually for merchants. If your segmentation testing is a quarterly Nessus scan, it does not meet the requirement.
SAQ vs ROC: which do you need?
- Self-Assessment Questionnaire (SAQ): Used by merchants and many service providers for self-attestation. Multiple variants (A, A-EP, B, B-IP, C, C-VT, D, P2PE) based on processing method.
- Report on Compliance (ROC): Required for Level 1 merchants (over 6M transactions/year) and Level 1 service providers. Performed by a QSA.
The customized approach: when to use it
Reserve customized approach for mature programs with strong documentation hygiene. Good candidates: large enterprises with established TRA programs, cloud-native architectures where defined approach controls do not map cleanly. Bad candidates: anyone using customized approach to avoid implementing a hard control. QSAs are scrutinizing this heavily.
Bottom line
PCI DSS 4.0 is significantly more rigorous than 3.2.1. The customized approach offers flexibility but raises documentation requirements. The future-dated requirements are now table stakes. Build for continuous compliance, run TRAs annually, and segment ruthlessly.
Want to skip the spreadsheet years?
QAE automates evidence collection across 200+ integrations, maps controls across 20+ frameworks, and gets you audit-ready in 11 weeks.
Book a Free Demo →