PCI DSS v4.0.1: what changed and what your next assessment tests

The PCI DSS version dates, in order

If your last assessment was under v3.2.1, or under v4.0 before the future-dated requirements applied, your next one faces a larger requirement set. The dates below come from the PCI Security Standards Council's own announcements.

What v4.0 changed: six themes an assessor now tests

The new requirements are spread across all twelve principal requirements but cluster around six ideas, and planning evidence by idea is easier than by sub-requirement.

Targeted risk analysis

Where the standard lets you decide how often a control runs, you now have to justify the frequency with a documented targeted risk analysis under Requirement 12. The Council's own guidance, for example, ties the frequency of payment page tamper checks under 11.6.1 to a targeted risk analysis under 12.3.1. The analysis is reviewed at least once a year, and the assessor reads it to decide whether your chosen interval is defensible.

The customised approach

v4.0 added a second way to meet a requirement: instead of the defined approach, an entity can design its own control against the requirement's stated objective, backed by a risk analysis and a controls matrix, which the assessor then designs tests for. It suits mature organisations with unusual technology, not a first assessment. It is covered in depth, alongside compensating controls, in PCI DSS compensating controls and the customised approach.

Authentication and MFA

Requirement 8 was strengthened in several places. Multi-factor authentication now applies to all non-console access into the cardholder data environment, not only to remote access and administrators, and passwords must be twelve characters where the system supports it.

E-commerce payment page scripts

Requirements 6.4.3 and 11.6.1 address the attacks that skim card data from checkout pages. The first asks for an inventory of every script on the payment page, with a written justification and a method of confirming each one is authorised and unaltered. The second asks for a mechanism that detects unauthorised changes to the page and its security-relevant headers as the customer's browser receives them.

Phishing and malware

Requirement 5 now expects technical measures against phishing, not only awareness posters, and a more deliberate approach to anti-malware coverage, including a justified view of systems that are not commonly affected by malware and how often that judgement is revisited.

Roles, responsibilities and ongoing operation

Each principal requirement now expects documented, assigned and understood roles for the activities it covers, and Requirement 12 adds an annual confirmation of scope. Log review is part of the same shift, with automated mechanisms now expected to perform the daily review.

What v4.0.1 clarified, and what it did not

v4.0.1 is often described as a new version with new obligations. It is not. The Council's announcement describes corrections to formatting and typographical errors and clarifications of the focus and intent of some requirements and guidance. The points that matter most in practice are these.

• Patching. In Requirement 6, the obligation to install patches within 30 days was returned to the v3.2.1 position: it applies to critical vulnerabilities.
• MFA and phishing-resistant factors. Requirement 8 gained an applicability note on when phishing-resistant authentication can satisfy the MFA expectation, and the glossary now defines phishing-resistant authentication.
• Issuers and stored data. Requirement 3 received clarified applicability notes for issuers and guidance on using keyed cryptographic hashes to render PAN unreadable.
• Service provider relationships. Requirement 12 applicability notes were updated on how responsibilities are shared between customers and third-party service providers.
• Appendices. The customised approach templates were removed from Appendix E, and the glossary in Appendix G gained definitions including "legal exception" and "visitor".

It did not move the 31 March 2025 effective date or relax any future-dated requirement.

Area by area: what changed and the evidence your assessor will ask for

The table maps each theme to the kind of testing a QSA, or your own ISA for an internal assessment, now performs. Requirement references appear only where the Council's published material confirms them; the full list is explained in PCI DSS requirements explained, requirement by requirement.

Preparing for your next assessment under v4.0.1

MFA can be enabled in a day; months of script integrity checks and handled log alerts cannot, and an assessor sampling across the period will notice records that begin the week before fieldwork.

A practical order is: confirm the scope, because every new control applies to the whole cardholder data environment; write the targeted risk analyses, because they set the frequencies everything else follows; then close the technical gaps on authentication, payment pages, phishing and logging; and finally assign and record the roles for each requirement so that interviews confirm what the documents say. If you validate by self-assessment questionnaire, check your SAQ's current eligibility criteria as well, because the Council revised SAQ A in January 2025 in respect of the payment page requirements; the detail sits in Which SAQ applies to you: eligibility explained.

PCI DSS v4.0.1 changes: questions buyers ask