PCI-DSS v4.0: What Changed and What You Need to Do
The Payment Card Industry Data Security Standard (PCI-DSS) v4.0 represents the first major update in nearly a decade, and it reflects real-world threats and operational realities that v3.2.1 simply didn't address. If your organization processes, stores, or transmits cardholder data, you need to understand what's changed and how to prepare. This guidance walks you through the practical steps required to comply.
The Timeline: When Compliance Matters
PCI-DSS v4.0 was released in March 2022, but the compliance deadline is critical: you must be compliant by March 31, 2024, if you're subject to the standard. After that date, v3.2.1 support ends. If you haven't started the transition, treat this as urgent. Your assessor will evaluate you against v4.0, and non-compliance carries financial penalties—typically $5,000–$100,000 per month—plus potential card brand restrictions on your merchant account.
Key Changes You Must Address
1. Requirement 1: Firewalls and Network Segmentation
Requirement 1.1 now explicitly mandates that your organization document and implement a "network segmentation" strategy. This isn't new conceptually, but v4.0 demands evidence. You must produce a network diagram showing how you've isolated cardholder data environments (CDEs) from untrusted networks. This diagram must identify all network flows, including third-party connections. Action: conduct a network audit, map all systems that touch cardholder data, and document segmentation controls. If you're not currently segmented, this is your biggest lift.
2. Requirement 2: Default Credentials and Configuration
Requirement 2.1 strengthens the prohibition on default passwords across all system components. v4.0 expands this to include wireless access points, management interfaces, and hypervisors—areas often overlooked in v3.2.1 assessments. Action: inventory every networked device and verify that defaults have been changed. Document the process for provisioning new equipment to enforce this standard immediately.
3. Requirement 6: Secure Development and Vulnerability Management
Requirement 6.2 introduces a critical shift: you must now identify and remediate "security vulnerabilities" using a risk-based approach, not just threats. This distinction matters because you're now required to track vulnerabilities in custom code and third-party dependencies before they're exploited. Additionally, Requirement 6.3.2 mandates software development lifecycle (SDLC) governance—your developers must follow secure coding practices and use version control. Action: establish a vulnerability management program that includes static and dynamic application security testing (SAST/DAST), implement dependency scanning, and document your SDLC governance. If you're using open-source components, tools like OWASP Dependency-Check are now table stakes.
4. Requirement 7: Access Control Enforcement
Requirement 7.1 now requires that access to cardholder data be granted based on explicit business need—not assumed from job role. This shifts the burden to your organization to prove why each user needs each permission. Action: conduct an access review for all accounts with CDE access, document the business justification for each access grant, and implement quarterly reviews. If you lack a formal access governance process, build one now.
5. Requirement 8: User Identification and Multi-Factor Authentication
Requirement 8.3 extends multi-factor authentication (MFA) requirements significantly. In v3.2.1, MFA was required only for remote administrative access. v4.0 requires MFA for all user access to the CDE, plus all administrative access to security systems. This includes staff VPN connections, remote desktop gateways, and security appliances. Action: implement MFA across all CDE access points. If budget is tight, prioritize remote access first, but plan for all access methods within your compliance window.
6. Requirement 10: Logging and Monitoring
Requirement 10.2 now mandates automated alerting—not just log collection. You must detect and respond to suspicious activity in real time. Requirement 10.3 introduces stricter log retention (minimum one year, immediately available for one month). Action: evaluate your SIEM solution or implement one if you lack centralized logging. Configure alerting rules for high-risk events: failed authentication attempts, privilege escalation, configuration changes, and data access anomalies.
Practical Compliance Roadmap
Now (if you haven't started): Engage your PCI-DSS assessor early—they can clarify expectations specific to your environment and help prioritize controls. Conduct a gap assessment against v4.0 to identify which requirements pose the biggest challenge.
Next 3 months: Execute high-effort items: network segmentation, SDLC governance, and MFA implementation. These require planning and budget.
Final 3 months: Complete access reviews, finalize documentation, conduct internal testing, and prepare for your formal assessment.
The deadline is immovable. Start now.