PCI DSS v4.0.1 Requirements: A Practical Guide
All 12 PCI DSS v4.0.1 requirements explained in plain English, with the control inventory, the evidence assessors ask for, and where each one commonly fails.
The Payment Card Industry Data Security Standard applies to every organisation that stores, processes or transmits cardholder data. Version 4.0.1 was published in June 2024 and is the only version now in force. V3.2.1 was retired on 31 March 2024.
The standard contains 12 requirements, broken into 63 sections and 249 individual controls. Each requirement below has its own page explaining what it asks for, who it applies to, the evidence an assessor expects, and the mistakes that most often produce a finding.
Dates that matter
- 31 March 2024. V3.2.1 retired. Assessments are against v4.x only.
- 31 March 2025. The controls that were future-dated in v4.0 became mandatory. This includes 6.4.3 and 11.6.1, the two payment-page script controls, and 8.4.2 multi-factor authentication for all CDE access.
The twelve requirements
Build and Maintain a Secure Network and Systems
| Requirement | Controls | |
|---|---|---|
| Requirement 1 | Install and Maintain Network Security Controls | 19 |
| Requirement 2 | Apply Secure Configurations to All System Components | 11 |
Protect Account Data
| Requirement | Controls | |
|---|---|---|
| Requirement 3 | Protect Stored Account Data | 29 |
| Requirement 4 | Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks | 6 |
Maintain a Vulnerability Management Program
| Requirement | Controls | |
|---|---|---|
| Requirement 5 | Protect All Systems and Networks from Malicious Software | 13 |
| Requirement 6 | Develop and Maintain Secure Systems and Software | 19 |
Implement Strong Access Control Measures
| Requirement | Controls | |
|---|---|---|
| Requirement 7 | Restrict Access to System Components and Cardholder Data by Business Need to Know | 12 |
| Requirement 8 | Identify Users and Authenticate Access to System Components | 29 |
| Requirement 9 | Restrict Physical Access to Cardholder Data | 26 |
Regularly Monitor and Test Networks
| Requirement | Controls | |
|---|---|---|
| Requirement 10 | Log and Monitor All Access to System Components and Cardholder Data | 27 |
| Requirement 11 | Test Security of Systems and Networks Regularly | 21 |
Maintain an Information Security Policy
| Requirement | Controls | |
|---|---|---|
| Requirement 12 | Support Information Security with Organizational Policies and Programs | 37 |
The two approaches to validation
v4.0.1 lets you meet most controls in one of two ways. The defined approach follows the requirement as written and is what the testing procedures assume. The customized approach lets you meet the stated objective by another means, but it obliges you to document the objective, design your own controls, perform a targeted risk analysis, and have your assessor derive bespoke testing procedures. It is not a shortcut. It moves the burden of proof onto you, and it is generally worth it only where a prescriptive control genuinely does not fit your architecture.
How this guide is written
These pages cite requirement identifiers and official requirement titles, and explain them in our own words. They do not reproduce the text of the standard. For authoritative wording. Including every testing procedure, applicability note and customized approach objective. Download the standard itself from the PCI Security Standards Council document library.
PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.