The 12 Requirements of PCI DSS v4.0.1, Explained

PCI DSS v4.0.1 has twelve requirements, grouped under six goals, and 250 controls beneath them. This article reads each requirement in a few paragraphs: what it protects, the controls that carry most of its weight, and the numbers it sets. Each section links the requirement's own page, where every control is set out with the testing procedures an assessor uses.

Which of these apply to you, and how many, depends on how you take payments. A merchant that completes a short SAQ faces a fraction of them.

Goal 1: Build and maintain a secure network and systems

Requirement 1: Install and maintain network security controls

Network security controls (NSCs) are whatever enforces network policy: firewalls, cloud security groups, router access lists. v4.x replaced the older "firewalls and routers" wording so the requirement follows the function, not the device. NSCs sit between trusted and untrusted networks (1.4.1), traffic into and out of the cardholder data environment is limited to what is necessary with everything else denied (1.3.1, 1.3.2), and NSC configurations are reviewed at least every six months (1.2.7). Accurate network and data-flow diagrams are required too (1.2.3, 1.2.4). Requirement 1: 19 controls.

Requirement 2: Apply secure configurations to all system components

Configuration standards cover every system component and follow industry hardening standards or vendor guidance (2.2.1). Vendor default accounts are removed, disabled or given new passwords (2.2.2), only necessary services are enabled (2.2.4), and non-console administrative access is encrypted with strong cryptography (2.2.7). For wireless environments connected to the CDE, vendor defaults such as encryption keys and SNMP settings are changed at installation (2.3.1). The standard names no particular wireless protocol. Requirement 2: 11 controls.

Goal 2: Protect account data

Requirement 3: Protect stored account data

The first rule is to store less: retention and disposal policies must cover every place account data is kept (3.2.1). Sensitive authentication data is not stored after authorisation, even encrypted (3.3.1). The PAN is masked when displayed, showing at most the BIN and last four digits (3.4.1), and rendered unreadable wherever it is stored, by a keyed hash, truncation, index tokens or strong cryptography (3.5.1). Where encryption is used, 3.6 and 3.7 govern the keys: who can reach them, where they live, and how they are generated, changed and retired. Requirement 3: 29 controls.

Requirement 4: Protect cardholder data with strong cryptography during transmission

PAN sent over open, public networks is protected with strong cryptography and secure protocols, with only trusted keys and valid certificates accepted and no fallback to insecure versions (4.2.1). The entity keeps an inventory of those keys and certificates (4.2.1.1), and PAN sent by email, chat or other end-user messaging is also protected with strong cryptography (4.2.2). Requirement 4: 6 controls.

Goal 3: Maintain a vulnerability management programme

Requirement 5: Protect all systems and networks from malicious software

Anti-malware is deployed on every system component except those a periodic evaluation finds not at risk (5.2.1), kept up to date automatically (5.3.1), and protected from being switched off by users (5.3.5). Since 31 March 2025, processes and automated mechanisms must also detect and protect personnel against phishing (5.4.1). Requirement 5: 13 controls.

Requirement 6: Develop and maintain secure systems and software

Two halves. For software the entity writes or has written for it, 6.2 requires secure development, developer training at least every 12 months, and code review before release. For everything, vulnerabilities are identified and risk-ranked (6.3.1) and patches for critical ones installed within one month of release (6.3.3); v4.0.1 returned 6.3.3 to that wording after v4.0 had extended it to high-risk patches. Public-facing web applications need an automated solution that detects and prevents web attacks (6.4.2), and every script on a payment page must be authorised, integrity-checked and inventoried (6.4.3). Changes follow a documented change control process (6.5.1). Requirement 6: 19 controls.

Goal 4: Implement strong access control measures

Requirement 7: Restrict access by business need to know

Access is granted through a defined model based on job function and least privilege (7.2.1, 7.2.2), user accounts and privileges are reviewed at least every six months (7.2.4), and access control systems are set to deny everything not explicitly allowed (7.3.3). Requirement 7: 12 controls.

Requirement 8: Identify users and authenticate access

Every user gets a unique ID (8.2.1), and shared accounts are allowed only by documented exception (8.2.2). Passwords are at least 12 characters with letters and numbers (8.3.6), accounts lock after at most 10 failed attempts (8.3.4), and idle sessions time out after 15 minutes (8.2.8). Multi-factor authentication is required for all non-console access into the CDE (8.4.2) and for remote access from outside the network (8.4.3); v4.0.1 clarified both wordings. Requirement 8: 29 controls.

Requirement 9: Restrict physical access to cardholder data

Facility entry controls restrict physical access to systems in the CDE (9.2.1), personnel and visitor access is authorised and managed (9.3.1), and media with cardholder data is protected and destroyed when no longer needed: paper cross-cut shredded, incinerated or pulped (9.4.6), electronic media destroyed or made unrecoverable (9.4.7). Card-reading terminals are listed, inspected for tampering and handled by trained staff (9.5.1). Requirement 9: 27 controls.

Goal 5: Regularly monitor and test networks

Requirement 10: Log and monitor all access

Audit logs are enabled on all system components (10.2.1) and capture, among other things, all individual access to cardholder data and all administrative actions (10.2.1.1, 10.2.1.2). Security-relevant logs are reviewed at least daily (10.4.1), by automated mechanisms since 31 March 2025 (10.4.1.1), and kept for 12 months with the latest three immediately available (10.5.1). Clocks are synchronised (10.6.1), and the failure of a critical security control is detected and dealt with promptly (10.7.2). Requirement 10: 27 controls.

Requirement 11: Test security of systems and networks regularly

Wireless access points are detected and identified at least every three months (11.2.1). Internal and external vulnerability scans run at least every three months, the external ones by an Approved Scanning Vendor (11.3.1, 11.3.2), and penetration tests at least every 12 months (11.4.2, 11.4.3). Intrusion detection or prevention monitors traffic at the CDE perimeter and critical points (11.5.1), and a change- and tamper-detection mechanism watches payment pages as the customer's browser receives them (11.6.1). Understanding PCI DSS 11.6.1 covers the last one in depth. Requirement 11: 21 controls.

Goal 6: Maintain an information security policy

Requirement 12: Support information security with organisational policies and programmes

An information security policy is published, disseminated and reviewed at least every 12 months (12.1.1, 12.1.2). Targeted risk analyses justify every frequency the entity sets itself (12.3.1), scope is confirmed at least every 12 months (12.5.2), and personnel receive security awareness training (12.6.1). Third-party service providers are listed, contracted, checked and their responsibilities recorded (12.8), and an incident response plan is ready to use (12.10.1). Service providers carry extra duties, such as executive responsibility for the compliance programme (12.4.1). Requirement 12: 37 controls.

Beyond the twelve

Four appendices sit alongside the requirements. Appendix A1 adds requirements for multi-tenant service providers, A2 covers entities still using SSL or early TLS on card-present terminals, and A3 is a set of additional validation steps an acquirer or brand can require. Appendix B and C cover compensating controls, and Appendix D the customised approach, the alternative to meeting a requirement exactly as written. PCI Compliance 101 covers how the versions and dates fit together, and the PCI DSS v4.0.1 overview links everything above.