If your last PCI DSS assessment ran against version 3.2.1, the next one will look familiar in outline and different in detail. There are still 12 principal requirements. Underneath them, the wording, the testing and several expectations have moved.
The timeline is settled. The PCI Security Standards Council published version 4.0 in March 2022 and retired 3.2.1 at the end of March 2024. Version 4.0.1, a limited revision, followed in June 2024 and replaced 4.0 when 4.0 retired at the end of that year. The new requirements that 4.0 marked as best practices until March 31, 2025 have been mandatory since that date.
This article covers the structural changes, the new requirements that create the most work, what 4.0.1 adjusted, and the misreadings that cause trouble in a first assessment under the new version. Later posts in this series go deeper on individual topics.
The structural changes
Several changes affect how the whole standard reads, not one requirement.
Two ways to meet a requirement
Every requirement can now be met through the defined approach, which is the familiar model: the requirement as written, with testing procedures your assessor follows. Most requirements can also be met through the customized approach, where you design a control that meets the requirement's stated objective and your assessor derives testing for it. Requirements that allow it carry a "Customized Approach Objective" for that purpose. Most entities will stay on the defined approach for nearly everything, and that is the expected outcome.
Targeted risk analysis
Version 4.0 introduced the targeted risk analysis. Requirement 12.3.1 asks for one wherever a requirement lets you set the frequency of an activity, such as how often to review logs for lower-risk systems. Requirement 12.3.2 asks for one for each requirement you meet with the customized approach. These are narrow, per-requirement documents, not a restatement of your enterprise risk assessment.
Roles and responsibilities in every section
Requirements 1 through 11 each open with a requirement (1.1.2, 2.1.2 and so on) that roles and responsibilities for that section are documented, assigned and understood. An assessor will ask who owns the activities in each section, and "the security team" is a thin answer.
Terminology that follows modern infrastructure
Requirement 1 now speaks of network security controls rather than firewalls and routers. The change acknowledges that cloud security groups and other virtual controls do the same job. "Account data" is the umbrella term for cardholder data and sensitive authentication data, and the glossary entries for those terms are worth having to hand.
Scope you confirm on a schedule
Requirement 12.5.2 asks you to document and confirm your PCI DSS scope at least once every 12 months and on significant change. The requirement lists what the confirmation covers: data flows, every location of account data, the system components in and connected to the cardholder data environment (CDE), segmentation controls, and third-party connections. Service providers must do this at least once every six months under 12.5.2.1.
The new requirements that take the most work
Not every new requirement is hard. These are the ones that usually need a new tool, a new process or both.
| Area | Requirement | What it asks for |
|---|---|---|
| Payment page scripts | 6.4.3 | An inventory of every script on payment pages, with justification, authorization and an integrity check for each |
| Payment page tampering | 11.6.1 | A mechanism that alerts on unauthorized changes to payment page scripts and security-impacting HTTP headers |
| MFA | 8.4.2 | MFA for access into the CDE, not only for administrators |
| MFA system design | 8.5.1 | MFA that resists replay, cannot be bypassed without a documented exception, and requires every factor to succeed |
| Passwords | 8.3.6 | At least 12 characters (eight where a system cannot support 12), with letters and numbers |
| Web applications | 6.4.2 | An automated technical solution in front of public-facing web applications that detects and prevents web-based attacks |
| Internal scanning | 11.3.1.2 | Authenticated internal vulnerability scans |
| Log review | 10.4.1.1 | Automated mechanisms to perform audit log reviews |
| Control failures | 10.7.2 | Detection and alerting when critical security controls fail, extended from service providers to all entities |
| Access reviews | 7.2.4 | A review of all user accounts and access privileges at least once every six months |
A few others deserve a mention. Requirement 5.4.1 asks for mechanisms that detect and protect personnel against phishing attacks, and 12.6.3.1 adds phishing and social engineering to security awareness training. Requirement 3.5.1.1 requires hashes used to render PAN unreadable to be keyed cryptographic hashes. Requirement 3.5.1.2 limits disk-level encryption as the sole protection for stored PAN to removable media.
Service providers carry extra items, including support for customers' external penetration testing in multi-tenant environments (11.4.7) and providing customers with information about their PCI DSS compliance status and responsibilities (12.9.2).
What version 4.0.1 adjusted
Version 4.0.1 added no new requirements. It corrected errors, clarified wording and restored or added applicability notes. Two examples show the kind of change. Requirement 6.3.3 now asks for patches addressing critical vulnerabilities within one month of release, with other patches on a timeline you set. Requirement 8.4.2 gained a note that it does not apply to user accounts authenticated only with phishing-resistant factors.
The Council published a summary of changes from 4.0 to 4.0.1 alongside the revision. Read it rather than relying on a vendor's paraphrase, including this one, because small wording changes decide what your assessor tests.
What people get wrong about the transition
The other common misreadings:
Treating the customized approach as a shortcut. It needs a controls matrix, a targeted risk analysis and evidence that the control works. It is more documentation than the defined approach, not less.
Reading requirements without their applicability notes. The notes decide who a requirement applies to and what it excludes. Requirement 8.4.2 is a good example: the exemptions live in the notes.
Assuming self-assessment escapes the changes. The self-assessment questionnaires were reissued for the new version and include the new requirements relevant to each one's eligibility.
Writing one large risk assessment to satisfy 12.3.1. Each targeted risk analysis should name the requirement, the asset, the threat and the frequency it justifies. A general risk register entry rarely does.
Assuming segmentation was settled last time. The 12.5.2 confirmation is annual and documented, so last year's diagram is a starting point, not evidence.
Where to start
If you are preparing for a first assessment under 4.0.1, work in this order:
Confirm the version and the validation method. Ask your acquirer, or the customer requiring your compliance, what they expect: a report on compliance from an assessor or a self-assessment questionnaire. Card brands and acquirers set those rules, not the Council.
Confirm scope using the 12.5.2 list. Everything after this depends on it, and the new requirements apply only to what is in scope.
List every requirement with a frequency you set. Write a targeted risk analysis for each, and review it at least once every 12 months.
Gap-assess the new requirements in the table above. Payment page scripts and MFA tend to need the longest lead time.
Assign the x.1.2 roles. Name a person or team for each section, and make sure they know it.
The PCI DSS framework page summarizes the 12 principal requirements if you need the map before the detail.
How TrustLynce helps
TrustLynce maps PCI DSS 4.0.1 requirements to your controls and reuses evidence you already collect for other frameworks through compliance automation. The readiness dashboard shows gaps per requirement, so the new items are visible before your assessor finds them.