PCI DSS 4.0 requirements are now fully enforceable for every business that accepts credit cards. The Payment Card Industry Data Security Standard version 4.0 replaced version 3.2.1 on March 31, 2024, and the final batch of future-dated requirements became mandatory on March 31, 2025. Whether you process payments through a hosted checkout page or handle card data directly, these changes affect how you protect that data and how your compliance is validated. The update is the most significant revision to PCI standards in over a decade, touching authentication, payment page security, risk analysis practices, and the fundamental philosophy of how compliance works. The Transition from PCI DSS 3.2.1 to 4.0 The PCI Security Standards Council published PCI DSS 4.0 in March 2022. For two years, both versions ran in parallel, and businesses could assess against either standard during that window. On March 31, 2024, version 3.2.1 officially retired, and all new assessments had to use version 4.0. But the council recognized that certain new requirements needed more lead time. These were labeled "future-dated" in the standard and given an extended deadline of March 31, 2025. During the transition period, they were treated as best practices only. After that date, they became mandatory. No further extensions were granted. Then came version 4.0.1 in June 2024. This wasn't a new major release. It corrected errata, clarified testing procedures, and refined guidance language without adding new requirements or changing deadlines. If you're already compliant with 4.0, the 4.0.1 amendments don't change your obligations. They just make the standard easier to interpret. The PCI SSC accepts assessments against either version, though it encourages organizations to adopt 4.0.1 going forward since it reflects the most current language. What Changed in PCI DSS 4.0 The PCI 4.0 changes span structural shifts in how compliance works and specific technical controls aimed at modern threats. Several areas stand out. Expanded Multi-Factor Authentication Version 3.2.1 required multi-factor authentication for remote access to the cardholder data environment and for non-console administrative access. Version 4.0 expands that scope considerably. MFA is now required for all access to the cardholder data environment, not just remote or administrative connections. That's a real shift for businesses that previously relied on single-factor credentials for employees accessing payment systems from inside the corporate network. The implementation rules also got more specific: authentication factors must be independent, meaning that compromising one factor can't compromise another, and systems can't allow users to bypass MFA without a formally defined and documented exception process. These aren't abstract principles. They're testable requirements that assessors will verify during your next evaluation. Payment Page Script Management Under Requirement 6.4.3 Requirement 6.4.3 is one of the most discussed new PCI DSS 4.0 requirements, and the attention is warranted. It mandates that all scripts loaded and executed in a consumer's browser on payment pages must be managed, authorized, and monitored. Every script running on your checkout page needs to be explicitly inventoried, justified for its presence, and have its integrity verified. This targets a specific and growing threat category: digital skimming attacks, where malicious JavaScript is injected into payment pages to capture card numbers, expiration dates, and CVVs as customers type them. The Magecart-style attacks that hit major retailers over the past several years exploited exactly this gap in earlier standards. PCI DSS 3.2.1 didn't address client-side script security in any meaningful way, and attackers took advantage. The scale of these attacks is what drove the PCI SSC to make this one of the most operationally significant additions in version 4.0. For businesses that host their own payment forms, compliance now means implementing content security policies, script integrity monitoring, subresource integrity checks, or some combination of these controls. The standard doesn't prescribe the exact technical method, which gives flexibility but puts the burden on each organization to choose and defend its approach during assessment. This requirement was future-dated and is now fully mandatory as of March 31, 2025. The Customized Approach to Compliance Prior versions of PCI DSS offered one compliance path: meet each requirement as written, following the prescribed testing procedures. Version 4.0 introduces an alternative called the customized approach. Under this option, an organization can meet the security objective of a requirement using a different control, as long as a targeted risk analysis demonstrates that the alternative achieves the same outcome. This matters most for larger organizations with mature security programs. A company might have a security architecture that doesn't map neatly to a specific PCI requirement but delivers equivalent protection through different means. The customized approach lets them document and validate that method rather than forcing a retrofit that adds cost without adding security. Small merchants won't typically use this path. It requires more rigorous documentation, demands a detailed risk analysis for each customized control, and assessors evaluate it with extra scrutiny. But it reflects an important philosophical shift: PCI DSS is moving from a prescriptive checklist toward outcome-based security. That direction will likely accelerate in future versions of the standard. Targeted Risk Analyses Replace Generic Assessments PCI DSS 4.0 introduces a formal targeted risk analysis framework that replaces the broader risk assessment language in 3.2.1. Several requirements now mandate that organizations perform a targeted risk analysis to determine the frequency of specific activities, including log reviews, vulnerability scans, password rotations, and access reviews. Under 3.2.1, many of these frequencies were fixed. Logs had to be reviewed daily. Scans ran quarterly. Version 4.0 still defines minimum baselines for some activities, but organizations can use a targeted risk analysis to justify different frequencies where their risk profile supports the adjustment. The catch is documentation. Each targeted risk analysis must be formally documented, approved by management, and reviewed at least annually. Organizations that don't maintain this paperwork will fail the requirement even if their actual security practices are sound. The standard rewards risk-based thinking, but it demands proof that the thinking actually happened. Roles, Responsibilities, and Authentication Updates Every requirement section in version 4.0 now opens with an explicit mandate to define and document roles and responsibilities for carrying out that section's controls. This was implicit in 3.2.1. It's explicit now. For organizations that rely on tribal knowledge or informal task ownership, this change alone can require significant effort to address properly. Password standards also changed in ways that affect daily operations. Minimum password length increased from seven characters to twelve, or eight if the system can't support twelve. Complexity requirements were updated, and service accounts and application passwords carry additional management controls. These updates align PCI DSS with current NIST authentication guidance, which has shifted away from forced periodic rotation toward longer, more complex credentials with breach-based change triggers. For businesses still enforcing 90-day password expiration policies, the new standard represents a fundamentally different approach to credential security. The March 2025 Deadline Is Behind Us The March 31, 2025 deadline has passed. Every PCI DSS 4.0 requirement, including those previously marked as future-dated, is now mandatory. There's no further grace period. For businesses undergoing their next assessment, whether through a Self-Assessment Questionnaire or a full Report on Compliance conducted by a Qualified Security Assessor, all requirements apply. If your organization hasn't implemented the previously future-dated controls, you're out of compliance today. The PCI SSC doesn't directly enforce compliance, though. Enforcement flows through the card networks and acquiring banks, and the practical timeline for enforcement action varies by acquirer and merchant risk level. Some acquiring banks are already requiring attestation of 4.0 compliance, while others may take a risk-based approach for lower-volume merchants. But the standard itself is clear: compliance is expected now. Do Small Merchants Need PCI DSS 4.0 Compliance? Yes. PCI DSS applies to every organization that stores, processes, or transmits cardholder data, regardless of size. A sole proprietor running an online store is subject to the same standard as a multinational retailer. The difference is how compliance gets validated, not whether it applies. Most small merchants qualify as Level 4 under the card brand classification systems, which typically means completing a Self-Assessment Questionnaire rather than a full on-site assessment. The SAQ you complete depends on how your business accepts payments, and that distinction became more consequential under PCI DSS 4.0. The version change didn't just add requirements. It changed which SAQ categories ask which questions, particularly around payment page security. Hosted Payment Pages vs. Direct Integration If your checkout redirects customers to a payment form hosted entirely by your processor, where your servers never touch card data, you likely qualify for SAQ A. This is the shortest questionnaire and remains the most accessible compliance path for small merchants under the new standard. That said, SAQ A now includes questions related to Requirement 6.4.3, the payment page script requirement discussed earlier. Even with a hosted payment page, if your site loads scripts that could affect the payment process, you may need to demonstrate those scripts are managed and monitored. The PCI SSC clarified in the 4.0.1 amendments that merchants using fully hosted, redirect-based payment forms where no merchant-side scripts can affect the payment transaction may qualify for simplified compliance with this requirement. The eligibility hinges on the specific technical implementation, not just the general payment approach your business uses. If your business uses an embedded payment form, where payment fields render inside your website even though the data flows directly to the processor, the requirements are different. These implementations typically fall under SAQ A-EP, which carries significantly more requirements than SAQ A. Under 4.0, the script management and page security controls apply more directly to this configuration. Merchants who process payments through their own servers or terminal environments fall under SAQ D, which covers the full scope of PCI DSS and is the most demanding path. Practical Steps for Meeting PCI DSS 4.0 Requirements If you're a small business owner working through what these changes mean for your operation, five areas deserve your attention. Confirm which SAQ applies to your business. Your payment processor or acquiring bank should be able to tell you based on how you accept cards. The answer determines which subset of PCI DSS 4.0 requirements you're responsible for. Review how your payment page works. If you use a hosted redirect, verify that no scripts on your site interact with or could influence the payment flow. If you embed payment fields, understand that you're subject to broader requirements under 4.0, particularly around script management and page integrity monitoring. Check your authentication controls. If anyone at your business accesses systems that handle cardholder data, MFA should be in place. That includes virtual terminals, payment dashboards, and processor-provided admin panels. The expanded MFA requirements under 4.0 don't distinguish between remote and on-site access, so internal-only systems aren't exempt. Talk to your processor about their compliance posture. Processors that handle PCI compliance on your behalf should explain exactly what they cover and what remains your responsibility. Get that documentation in writing before your next assessment cycle. Treat compliance as ongoing, not annual. The targeted risk analysis requirements reflect an expectation that security decisions are documented, reviewed regularly, and updated when conditions change. A one-time checklist won't satisfy the standard going forward. Where This Standard Goes Next The PCI SSC has signaled that future updates will continue the shift toward outcome-based security. The customized approach in 4.0 laid the groundwork, and the council's public communications suggest that future versions will expand on risk-driven compliance models. The trend is clear: the standard is moving away from rigid checklists and toward demonstrable security outcomes. For business owners evaluating credit card processing providers, a processor's approach to PCI compliance support should factor into your decision. Some handle nearly all compliance obligations on the merchant's behalf, while others leave more responsibility with the business. Understanding where that line falls before you sign a contract matters more than fixing gaps after an assessment surfaces them.
PCI DSS 4.0: What Changed and the New Deadlines
