PCI DSS 4.0 compliance timeline: key dates and what to do now

PCI DSS 4.0 had the longest transition period in the standard's history. Released in March 2022, it gave organizations three full years to transition before version 3.2.1 was retired and then an additional year before the "future-dated" requirements became mandatory. The transition is now complete. Everything is mandatory.

This post covers the full timeline, what changed, which requirements specifically affect ecommerce and what enforcement actually looks like.

The full PCI DSS 4.0 timeline

• March 2022: PCI DSS 4.0 published. PCI SSC begins the formal transition period. Organizations can begin assessments against 4.0 but 3.2.1 remains valid.
• March 31, 2024: PCI DSS version 3.2.1 officially retired. All assessments from this date must be against PCI DSS 4.0. If your QSA assessment was in-progress under 3.2.1 and not completed by this date, it needed to restart under 4.0.
• March 31, 2025: All future-dated requirements in PCI DSS 4.0 become mandatory. These were requirements marked as "best practice until 31 March 2025" in the standard. After this date, they are assessed requirements. Non-compliance puts your assessment at risk.

As of October 2026, the transition is fully complete. Every requirement in PCI DSS 4.0, including the 64 new requirements that were future-dated, is now a mandatory assessment item.

What "best practice until required" meant

PCI DSS 4.0 introduced 64 new requirements (across new requirements and updates to existing ones) that were labeled "best practice until 31 March 2025." This designation meant:

• Organizations were encouraged to implement them but would not fail an assessment for not meeting them.
• QSAs could document them as "in progress" without marking the assessment as non-compliant.
• The transition gave organizations 3 years to plan and implement before these became mandatory.

For ecommerce teams, the most impactful of these future-dated requirements were in requirements 6, 10 and 11, covering payment page script management, logging and detection.

New requirements that matter most for ecommerce

PCI DSS 4.0 introduced over 50 new or significantly updated requirements. For ecommerce merchants, these are the most operationally significant:

• Requirement 6.4.3 (Payment page script management): all scripts executed on payment pages must be managed: maintained in an inventory, authorized and protected from unauthorized modification. SRI hashes and CSP are the technical controls. This was future-dated and became mandatory March 2025.
• Requirement 11.6.1 (Change and tamper detection): a mechanism must be in place to detect unauthorized changes to HTTP headers and payment page content. Requires periodic verification that headers and scripts match authorized versions. Also became mandatory March 2025.
• Requirement 8.3.6 (Password complexity increase): passwords for user accounts must be at least 12 characters (up from 7), with both letters and numbers. This applies to all accounts in the cardholder data environment, including administrative access to your ecommerce platform.
• Requirement 8.4.2 (Multi-factor authentication for all CDE access): MFA is now required for all access to the cardholder data environment, not just remote access. This is a significant expansion from 3.2.1 which required MFA only for remote access.
• Requirement 12.3.2 (Targeted risk analysis): new requirement for a documented risk analysis when selecting the frequency of activities that do not have a specific mandate in the standard. Adds process overhead but enables some flexibility in control implementation frequency.
• Requirement 3.3.2 (SAD protection after authorization): clearer rules on sensitive authentication data storage. SAD (full magnetic stripe, CVV, PIN) must not be stored after authorization even if encrypted. This was in previous versions but 4.0 adds clearer testing procedures.

What changed in requirements 6 and 11 specifically

Requirements 6 and 11 saw the most changes relevant to ecommerce web security.

Requirement 6 (Develop and maintain secure systems and software) was significantly restructured. Sub-requirement 6.4.3 is entirely new. It directly addresses the gap that allowed Magecart attacks to succeed: no specific requirement to manage and verify scripts on payment pages.

In PCI DSS 3.2.1, Requirement 6.3.2 required a list of bespoke and custom software, but this was interpreted as server-side code, not client-side JavaScript. The gap allowed organizations to have dozens of unmanaged third-party scripts on their checkout pages and still pass assessments.

PCI DSS 4.0 explicitly closes this gap. The testing procedures for 6.4.3 require the assessor to examine the list of payment page scripts, verify that each is authorized, and verify that a method exists to protect scripts from unauthorized modification. The wave of Magecart attacks on ecommerce stores was a direct driver of this change.

Requirement 11.6.1 is entirely new. In PCI DSS 3.2.1, there was no requirement to monitor payment page content for changes. You could run the same checkout page for years with no validation that the scripts had not been modified. 11.6.1 requires at minimum a weekly automated comparison of payment page headers and scripts against a known-good baseline.

SAQ implications for ecommerce merchants

Most small to mid-market ecommerce merchants do not undergo a full QSA assessment. They self-assess using a Self-Assessment Questionnaire (SAQ). The appropriate SAQ depends on how you process payments.

The most common SAQ types for ecommerce:

• SAQ A: for merchants who fully outsource all payment processing to a third-party service provider (e.g., using Shopify Payments' hosted checkout with no customization). All cardholder data functions are handled by PCI DSS compliant third parties. The merchant's website does not directly receive, process, transmit or store any cardholder data. SAQ A is the simplest: 22 requirements, focused on third-party management and access controls.
• SAQ A-EP: for e-commerce merchants who outsource payment processing but whose website directly affects the security of the payment transaction. This includes merchants using payment iframes (Stripe Elements, Braintree hosted fields) embedded in their own checkout pages, or merchants who redirect to a third-party checkout but whose pages are in the payment flow. SAQ A-EP includes Requirements 6.4.3 and 11.6.1. This is the most significant change for ecommerce in PCI DSS 4.0: merchants who were previously comfortable with SAQ A-EP now have mandatory script management and change detection requirements.
• SAQ D (Merchant): for merchants who do not fit SAQ A or SAQ A-EP, typically those with more complex environments. Includes all requirements.

The key determination: if your checkout page loads any third-party scripts (analytics, chat, pixels) AND your checkout is not on a fully separate subdomain that is completely isolated from your storefront, you likely fall under SAQ A-EP, not SAQ A. Many merchants incorrectly classify themselves as SAQ A and miss the 6.4.3 and 11.6.1 requirements. Our breakdown of the PCI DSS 4.0 SAQ-A changes covers the eligibility criteria in detail.

QSA assessment cycle and timing

PCI DSS compliance is assessed annually. For merchants at higher volume levels (Level 1: over 6 million Visa transactions per year), a QSA conducts the assessment and produces a Report on Compliance (ROC). For most ecommerce merchants at lower volume levels, the annual self-assessment produces the SAQ and Attestation of Compliance (AOC).

The assessment is a point-in-time certification. It confirms compliance as of the assessment date. Continuous compliance is maintained through your ongoing processes and controls, not through the annual assessment itself.

If your QSA assessment is in October 2026, you are being assessed against PCI DSS 4.0 with all future-dated requirements mandatory. There is no grace period remaining. Requirements 6.4.3 and 11.6.1 are assessed items in your current cycle.

What happens if you miss compliance deadlines

PCI DSS enforcement is not directly by the PCI SSC. It is enforced through your contractual relationships with payment card brands (Visa, Mastercard) and your acquiring bank.

Consequences of non-compliance:

• Fines from payment brands: Visa and Mastercard levy monthly fines on acquirers for merchant non-compliance. These fines are typically passed to the merchant. The amounts range from $5,000 to $100,000 per month depending on the merchant's compliance level and violation history.
• Liability shift in case of breach: if a data breach occurs and you were non-compliant at the time, your liability is significantly higher. PCI DSS compliance does not prevent all breaches, but non-compliant merchants bear more of the cost of breach remediation, card replacement and fraud liability.
• Card acceptance termination: in severe or repeat non-compliance cases, payment brands can prohibit a merchant from accepting their cards. This is the nuclear option and is rare, but it has been used.
• Increased assessment scrutiny: merchants with past compliance failures undergo more frequent and rigorous assessment cycles.

The practical enforcement reality: for smaller merchants assessed via SAQ, enforcement is primarily contractual and occurs when there is a breach. A merchant who self-certifies incorrectly (claims SAQ A when they should be SAQ A-EP) faces significant liability if they are subsequently breached, because the self-certification was fraudulent.

What to prioritize now

For ecommerce merchants doing their first PCI DSS 4.0 assessment or gap review in 2026:

• Determine your correct SAQ type. Do not assume SAQ A. If any part of your checkout flow is on your domain and loads third-party scripts, you are likely SAQ A-EP.
• Build your payment page script inventory. List every script tag on your checkout page, what it is, who owns it and why it is there. This is the foundation of 6.4.3 compliance.
• Implement CSP on payment pages. Start with Report-Only mode to understand your script landscape without breaking functionality. Move to enforce mode once you have a complete allowlist.
• Add SRI hashes to third-party scripts. Prioritize payment processor scripts first, then analytics and marketing scripts.
• Set up change detection for payment pages. Automated weekly comparison of payment page script hashes satisfies 11.6.1's minimum requirement. Real-time CSP violation reporting is better. For SAQ A-EP and SAQ D merchants, ensure your annual penetration testing covers the updated PCI DSS 4.0 scope.
• Review admin account security. Ensure all administrative access to your platform meets the 12-character password requirement and that MFA is enabled on all admin accounts.

Frequently asked questions

When did PCI DSS 4.0 become mandatory?

PCI DSS 4.0 was published in March 2022. Version 3.2.1 was retired on March 31, 2024. All future-dated requirements (including 6.4.3 and 11.6.1) became mandatory on March 31, 2025. Every requirement is now fully enforced.

What are the key PCI DSS 4.0 dates for ecommerce?

March 2022: standard published. March 31, 2024: v3.2.1 retired. March 31, 2025: all 64 future-dated requirements mandatory. Requirements 6.4.3 (script management) and 11.6.1 (tamper detection) are the most impactful for ecommerce.

What happens if I miss PCI DSS 4.0 compliance deadlines?

Non-compliance fines range from $5,000 to $100,000 per month from payment brands. A breach while non-compliant increases liability for investigation costs, card replacement and fraudulent transactions. In severe cases, card acceptance can be terminated.

How do I determine my correct SAQ type under PCI DSS 4.0?

If your checkout page loads third-party scripts alongside a payment iframe, you likely need SAQ-A-EP (193 requirements), not SAQ-A (22 requirements). Only full redirect integrations where customers leave your site for payment qualify for the simplest SAQ-A.

What should I prioritize for PCI DSS 4.0 compliance now?

Build your payment page script inventory (Requirement 6.4.3), implement Content Security Policy, add SRI hashes to third-party scripts, set up automated weekly change detection (Requirement 11.6.1) and enable MFA on all admin accounts.