PCI DSS 4.0 Requirements: All 12 Explained in Detail
Quick Answer
PCI DSS 4.0 has 12 core requirements organized under 6 goals: build secure networks, protect account data, manage vulnerabilities, control access, monitor and test networks, and maintain security policies. Together they contain approximately 400 individual test procedures.
Overview of PCI DSS 4.0 Requirements
PCI DSS 4.0 contains 12 requirements grouped into 6 goals. While the high-level structure remains familiar from earlier versions, v4.0 introduces significant changes including the customized approach, enhanced authentication requirements, and expanded scope for encryption and monitoring.
Key Takeaways
- PCI DSS 4.0 has 12 requirements with ~400 test procedures — up from ~250 in v3.2.1
- Requirements 3, 6, 8, and 12 saw the most significant changes in v4.0
- The customized approach lets organizations meet objectives through alternative controls
- Multi-factor authentication (MFA) is now required for all access to the CDE, not just remote access
- Targeted risk analysis replaces many prescriptive frequency requirements
Requirement 1: Network Security Controls
Requirement 1 (formerly "Install and maintain a firewall configuration") was renamed in v4.0 to reflect that network security extends beyond traditional firewalls. It covers all network security controls — firewalls, cloud security groups, WAFs, micro-segmentation, and software-defined networking.
- Define and document all network connections into and out of the CDE
- Restrict inbound and outbound traffic to only what is necessary
- Implement network security controls between all wireless networks and the CDE
- Maintain a current network diagram that shows all cardholder data flows
- Review firewall and router rule sets at least every 6 months
Requirement 2: Secure Configurations
This requirement mandates that all system components use secure configurations rather than vendor-supplied defaults. Default passwords, unnecessary services, and insecure protocols must be eliminated before any system enters the cardholder data environment.
⚠️ Common Failure Point
Default credentials and unnecessary services are among the top audit failures. This includes default SNMP community strings, database admin passwords, and wireless access point keys. Automated configuration scanners can catch these before your QSA does.
Requirement 3: Protect Stored Account Data
Requirement 3 governs how cardholder data is stored (or ideally, not stored). The core principle is: do not store cardholder data unless there is a legitimate business need. When storage is necessary, data must be rendered unreadable using encryption, truncation, tokenization, or hashing.
- Never store sensitive authentication data (full track data, CVV/CVC, PIN) after authorization
- Mask the PAN when displayed (show only first 6 and last 4 digits)
- Render stored PAN unreadable using strong cryptography with associated key management
- Define and enforce data retention policies — delete cardholder data when no longer needed
- New in v4.0: disk-level encryption is no longer acceptable as the sole protection for stored PAN
Requirement 4: Encrypt Data in Transit
Cardholder data must be encrypted with strong cryptography whenever it is transmitted over open, public networks. This includes internet transmissions, wireless networks, cellular technologies, and satellite communications.
✅ Minimum encryption standards
PCI DSS 4.0 requires TLS 1.2 or higher for all cardholder data transmissions. TLS 1.0 and 1.1 are explicitly prohibited. Internal network transmissions should also use encryption where feasible, as many breaches involve lateral movement within trusted networks.
Requirement 5: Malware Protection
All systems commonly affected by malicious software must have anti-malware solutions deployed. In v4.0, this requirement was updated to address modern threats beyond traditional viruses, including fileless malware, ransomware, and phishing attacks.
Requirement 6: Secure Development
Requirement 6 addresses the security of both custom software and third-party components. It requires secure development practices, code review processes, and protection of public-facing web applications. Key v4.0 additions include:
- Maintain an inventory of all custom and third-party software components
- Track and evaluate vulnerabilities in all software components
- Establish and follow a secure software development lifecycle (SDLC)
- Train developers annually on secure coding techniques
- Deploy a web application firewall (WAF) for public-facing web applications — automated technical solutions are now required rather than manual code review alone
Requirement 7: Restrict Access
Access to cardholder data and system components must be limited to individuals whose jobs require it. This follows the principle of least privilege — grant the minimum access necessary and deny everything else by default.
Requirement 8: Identify and Authenticate Users
Every individual accessing system components must be assigned a unique identification. Requirement 8 saw major changes in v4.0, particularly around multi-factor authentication and password requirements.
| Area | PCI DSS 3.2.1 | PCI DSS 4.0 |
|---|---|---|
| MFA scope | Required for remote access only | Required for ALL access to the CDE |
| Password length | Minimum 7 characters | Minimum 12 characters (or 8 if system doesn't support 12) |
| Password complexity | Numeric and alphabetic | Numeric and alphabetic (unchanged, but longer) |
| Service accounts | General guidance | Specific controls for application and system accounts |
| Authentication factors | Basic MFA requirements | Detailed requirements for each authentication factor |
Requirement 9: Physical Security
Physical access to cardholder data or systems must be restricted and monitored. This includes securing server rooms, workstations, paper records, and point-of-sale devices. Visitor logs, badge systems, and camera surveillance are typical controls.
Requirement 10: Logging and Monitoring
All access to system components and cardholder data must be logged, and those logs must be reviewed. PCI DSS 4.0 introduces automated log review mechanisms as a requirement, rather than relying solely on manual daily review.
✅ SIEM solutions
A Security Information and Event Management (SIEM) system is the most practical way to meet Requirement 10. It automates log collection, correlation, alerting, and retention. Look for solutions with built-in PCI DSS compliance dashboards.
Requirement 11: Security Testing
Organizations must regularly test their security systems and processes. This includes quarterly vulnerability scans by an ASV, annual penetration testing, and wireless access point detection. V4.0 adds requirements for internal vulnerability scanning after significant changes.
Requirement 12: Security Policies
The final requirement covers the organizational framework for security — policies, procedures, awareness training, and incident response. V4.0 significantly expands this requirement to include targeted risk analysis for determining frequencies of periodic activities.
PCI DSS 4.0 Requirements Architecture
The 12 PCI DSS requirements organized by their 6 security goals
Secure Network
Req 1-2: Network controls and secure configs
Protect Data
Req 3-4: Stored data protection and encryption in transit
Vulnerability Mgmt
Req 5-6: Malware protection and secure development
Access Control
Req 7-9: Least privilege, authentication, physical security
Monitor & Test
Req 10-11: Logging, monitoring, and security testing
Security Policy
Req 12: Policies, training, incident response
How many total controls are in PCI DSS 4.0?
PCI DSS 4.0 contains approximately 400 individual test procedures across its 12 requirements. The exact number depends on which SAQ applies to your environment. The full standard has 64 more requirements than version 3.2.1.
Which PCI DSS requirements changed the most in version 4.0?
Requirements 3 (stored data), 6 (secure development), 8 (authentication), and 12 (policies) saw the most significant changes. Requirement 8 notably expanded MFA to all CDE access, and Requirement 6 now mandates a WAF for public-facing web apps.
Do I need to implement all 12 requirements?
The specific requirements that apply depend on your SAQ type. For example, SAQ A merchants (fully outsourced e-commerce) only need to address a subset. However, if you undergo a full ROC assessment, all applicable requirements are evaluated.
What is the customized approach in PCI DSS 4.0?
The customized approach is new in v4.0 and allows organizations to meet the security objective of a requirement using alternative methods, rather than following the prescriptive defined approach. It requires a targeted risk analysis to demonstrate that the alternative control meets the stated objective.
Compare PCI DSS Compliance Tools
Find QSA firms, vulnerability scanners, and GRC platforms that simplify PCI DSS 4.0 compliance.
Browse PCI DSS Tools