PCI DSS 4.0.1 Is Now Mandatory: What Changes for You in 2026

The Deadline Has Passed — What Happens Now

March 31, 2025 marked the end of the transition period for PCI DSS 4.0.1. Every future-dated requirement is now mandatory. If your organization has been treating these controls as optional best practices, that window has closed. Assessors are now evaluating compliance against the full standard, and any gaps that were previously flagged as informational are now findings. For CISOs managing payment environments, this changes the risk calculus significantly. The previous version allowed organizations to maintain compliance with 3.2.1 controls while gradually adopting the new framework. That flexibility no longer exists. What matters now is whether your security controls actually meet the new requirements, not whether your documentation says they do. The most common gap we observe in assessments is the disconnect between documented policies and operational reality. Organizations updated their policies months ago but never implemented the technical controls those policies describe. This is the gap that will surface in your next assessment cycle.

Key Requirements That Are Now Enforceable

Several requirements that were future-dated now demand immediate attention. Requirement 6.4.3 mandates that all payment page scripts are managed through an inventory, authorized, and monitored for integrity. This means organizations must have a mechanism to detect unauthorized script changes on pages that handle payment data. Requirement 3.5.1.2 introduces disk-level encryption restrictions. If your organization relied on full-disk encryption as the sole mechanism for protecting stored cardholder data, that approach no longer satisfies the standard for removable media and non-SAN environments. Requirement 8.3.6 requires minimum password lengths of 12 characters where the system supports it, up from the previous 7-character minimum. This sounds simple but has cascading effects on legacy systems, service accounts, and integrated third-party platforms. Requirement 5.3.3 requires anti-malware scans on removable electronic media, and 5.4.1 mandates mechanisms to detect and protect against phishing attacks. These are operational controls that need process and tooling, not just policy updates.

Where Most Organizations Are Falling Short

Based on our assessment experience across 100 clients in 42 countries, three areas consistently create compliance gaps. The first is targeted risk analysis. Requirements 12.3.1 and 12.3.2 now mandate that organizations perform targeted risk analyses for any requirement where the standard allows flexibility in implementation frequency. This is not a one-time exercise — it must be documented, repeatable, and reviewed. Many organizations confuse this with their annual risk assessment. They are fundamentally different. The second is cryptographic inventory. Requirement 12.3.3 requires a complete inventory of all cryptographic cipher suites and protocols in use, along with their planned migration timelines. If your organization handles payment data across multiple systems, building this inventory is a substantial undertaking. The third is security awareness training. Requirement 6.3.2 requires that development teams receive training on secure coding practices relevant to their specific technology stack and role. Generic annual security awareness training does not satisfy this requirement.

Practical Steps to Close Compliance Gaps

If your next assessment is approaching, prioritize a gap analysis against the full 4.0.1 control set. Focus on the future-dated requirements first since these are the areas where compliance gaps are most likely. For payment page script management under 6.4.3, implement a content security policy combined with script integrity monitoring. Solutions range from commercial tools to well-configured CSP headers paired with subresource integrity attributes. For targeted risk analyses, create a template that your teams can use consistently. The standard does not prescribe a specific methodology, but it does require that each analysis covers the identified threats, the likelihood and impact of exploitation, and the justification for the chosen implementation frequency. For the cryptographic inventory, start with an automated scan of your environment to identify all TLS configurations, cipher suites, and certificate details. Then map each finding to the system it belongs to and its planned migration path. Document everything. In PCI DSS 4.0.1, the emphasis on documentation and evidence has increased substantially. If you cannot demonstrate a control through evidence, it does not exist from an assessment perspective.

How This Affects Your Assessment Timeline

Organizations approaching their first full assessment under 4.0.1 should expect the process to take longer than previous cycles. The expanded scope of requirements, the emphasis on targeted risk analysis, and the new evidence expectations mean assessors will need more documentation and more access. Plan for at least 15-20% more assessment time compared to your last 3.2.1 cycle. If your organization uses a compensating control worksheet for any requirement, review those controls against the 4.0.1 customized approach option. The customized approach allows more flexibility but requires a more rigorous validation process, including an independent assessment of the control objective. For organizations with complex payment environments spanning multiple geographies, the requirement for consistency across all entities included in the assessment scope becomes more critical. Each location, application, and network segment must demonstrate the same level of compliance.

Q: What is the deadline for PCI DSS 4.0.1 compliance?
A: March 31, 2025 was the final deadline. All future-dated requirements in PCI DSS 4.0.1 are now mandatory and will be assessed during your next compliance cycle.