PCI DSS v4.0: The Requirements That Catch People Out

Key takeaways

PCI DSS v3.2.1 was retired in March 2024; v4.0.1 is the current version.
Requirements that were future-dated became mandatory on 31 March 2025.
Payment page script controls, MFA into the CDE and targeted risk analyses cause the most findings.
Scope confirmation is now a formal, recurring requirement.

Where things stand

PCI DSS v4.0 was published in March 2022. Version 3.2.1 was retired on 31 March 2024, and a limited revision, v4.0.1, was published in June 2024 to clarify wording without adding requirements. Most importantly, the requirements that v4.0 introduced as “future-dated” became mandatory on 31 March 2025.

In our experience, organisations that passed their first v4.0 assessment by leaning on the grace period are now finding the future-dated requirements harder than expected. The following are the ones that most often produce findings.

1. Payment page scripts (6.4.3 and 11.6.1)

These requirements target e-skimming attacks, where malicious JavaScript on a checkout page steals card data. Requirement 6.4.3 expects you to maintain an inventory of every script on payment pages, justify why each is needed, authorise it and confirm its integrity. Requirement 11.6.1 expects a mechanism that detects unauthorised changes to those pages and their HTTP headers, and alerts you.

Marketing tags, analytics, chat widgets and A/B testing tools are the usual surprise. The PCI Security Standards Council has since clarified how these requirements apply to merchants that fully outsource their payment page to a validated provider — confirm your eligibility with your assessor rather than assuming.

2. Multi-factor authentication into the CDE (8.4.2)

MFA is now required for all access into the cardholder data environment, not only administrative or remote access. Service accounts and automated processes need a documented approach, and “the VPN has MFA” is not sufficient if users can then reach CDE systems without a second factor.

3. Stronger passwords and account management (8.3.6, 8.6)

Passwords must be at least 12 characters (or eight where a system genuinely cannot support more) and include letters and numbers.
Application and system accounts that can be used interactively must be managed: passwords protected, changed periodically based on risk, and not hard-coded in scripts or configuration files.

4. Targeted risk analysis (12.3.1)

Several requirements now let you set your own frequency for an activity — for example, how often to review certain logs or change certain credentials — provided you document a targeted risk analysis justifying it. Assessors increasingly ask to see these analyses. A single paragraph with no reasoning will not satisfy them; a short, structured analysis per requirement will.

5. Phishing protection and awareness (5.4.1, 12.6.3.1)

You must have processes and automated mechanisms to detect and protect personnel against phishing attacks, and awareness training must cover phishing and social engineering. Email filtering with anti-spoofing controls — DMARC, SPF and DKIM — is the usual technical foundation.

6. Automated log review (10.4.1.1)

Manual daily review of audit logs is no longer adequate. Automated mechanisms must perform the reviews and raise alerts. A SIEM or managed detection service is the typical answer; the evidence assessors want is proof that alerts are generated and acted on.

7. Scope confirmation (12.5.2)

Scope must be documented and confirmed at least every 12 months and after significant change, and service providers must do so every six months. This means a real exercise — data-flow diagrams, discovery of where card data actually lives, and confirmation that segmentation still works — not a copy of last year's document.

8. Disk encryption alone is no longer enough (3.5.1.2)

Disk-level or partition-level encryption is no longer acceptable on its own for rendering stored card numbers unreadable on non-removable media. If you rely on it, you will need file-, column- or field-level protection, or tokenisation.

Reducing scope is still the best control

The most effective PCI programme is the smallest one. Tokenisation, hosted payment pages, point-to-point encryption at the terminal and strict network segmentation all reduce the number of systems in scope — and with them the number of requirements you must evidence. Before investing in controls, ask whether the system needs to touch card data at all.

Preparing for your next assessment

Refresh data-flow diagrams and confirm scope before the assessor arrives.
Complete a targeted risk analysis for every requirement where you have chosen your own frequency.
Produce a current inventory of payment page scripts, with justification and authorisation for each.
Test that MFA is enforced for every route into the cardholder data environment.
Gather evidence that automated log reviews generate alerts and that alerts are acted on.
Review service provider responsibilities and obtain their current attestations of compliance.
Run an internal pre-assessment so there are no surprises during fieldwork.

Frequently asked questions

Which version of PCI DSS applies today?

PCI DSS v4.0.1 is the current version. It clarifies v4.0 without adding new requirements, and v4.0 itself was retired at the end of 2024.

Are the future-dated requirements still optional?

No. They became mandatory on 31 March 2025 and are assessed in full.

Does using a payment service provider remove our PCI obligations?

It reduces them, sometimes substantially, but rarely removes them entirely. Your validation type and the requirements that apply depend on how card data flows through your environment.

NAZZTEC Editorial TeamWritten and reviewed by NAZZTEC practitioners. This briefing is general guidance, not legal advice.