PCI DSS 4.0 March 2025 Deadline: What Changed, SAQ vs ROC and New Requirements for E-Commerce

Compliance

The PCI DSS 4.0 transition deadline was March 31 2025. The future-dated requirements that were optional under v4.0 are now mandatory under v4.0.1. This post covers what actually changed from v3.2.1, which assessment path applies to your environment, and the new requirements that caught e-commerce teams off guard.

By Arjun Raghavan, Security & Systems Lead, BIPI · September 19, 2025 · 12 min read

March 31, 2025 was the hard deadline for PCI DSS v4.0 compliance. PCI DSS v3.2.1 is retired. Every entity in the payment card ecosystem — merchants, service providers, payment processors — must now comply with v4.0.1, including the requirements that were marked as future-dated under the original v4.0 publication. For many organizations, especially those that delayed the transition, the deadline arrived with a set of new requirements they had not fully implemented.

PCI DSS 4.0 represents the most significant revision since v3.0. It introduced the customized approach for the first time, reorganized requirements significantly, added entirely new controls around e-commerce security and multi-factor authentication, and shifted the assessment framework toward outcomes-based thinking. Understanding what changed — and what it means for your specific merchant tier and assessment path — is the starting point for any compliance remediation.

Requirement 6.4 — managing scripts on payment pages — is the single requirement that affected the most e-commerce teams and generated the most compliance remediation work in the 2024-2025 transition period.

What changed from v3.2.1 — key additions

• Requirement 6.4: All scripts on payment pages must be authorized, have a documented business justification, and their integrity must be verified using SRI or equivalent mechanisms.
• Requirement 8.3.6: MFA required for all access to the cardholder data environment — not just remote access, all access including local console.
• Requirement 8.4.2: MFA required for all non-consumer users accessing any system component — broadened scope from v3.2.1.
• Requirement 10.7.2: Failures of critical security controls must be detected, alerted, and remediated within defined timeframes.
• Requirement 11.6.1: A change and tamper detection mechanism must be deployed to detect unauthorized modification of payment pages.
• Requirement 12.3.2: Targeted risk analysis must be performed for requirements that allow organizational flexibility.

SAQ vs ROC — which assessment applies

Self-Assessment Questionnaires are for merchants who have met the eligibility criteria to self-assess. Report on Compliance is required for Level 1 merchants (over 6 million Visa or Mastercard transactions annually) and for service providers, assessed by a Qualified Security Assessor. The SAQ type depends on how your environment accepts and processes payment data.

SAQ A applies to e-commerce merchants that have fully outsourced all card processing to a PCI-compliant third party and whose payment page is entirely hosted by that third party. SAQ A-EP applies when the merchant hosts their own payment page but outsources payment processing — this is the most common path for mid-size e-commerce and has the broadest scope. SAQ D is the comprehensive questionnaire for merchants that do not qualify for the other SAQ types.

• SAQ A — fully outsourced payment page: 22 requirements, eligible only if zero payment page elements are on your domain.
• SAQ A-EP — hosted payment page, outsourced processing: 191 requirements, includes Requirement 6.4 on script security.
• SAQ B-IP — IP-connected payment terminals, no e-commerce: 75 requirements.
• SAQ D merchant — all others: 281 requirements, equivalent to full ROC scope.

Requirement 6.4 in detail — script security for e-commerce

Requirement 6.4 is the one that caught most e-commerce teams by surprise. It requires that all scripts loaded on payment pages have: a documented inventory with business justification, integrity verification using Subresource Integrity hashes or an equivalent mechanism, and authorization from management. For a typical merchant with 15-20 third-party scripts on the payment page, this requires an inventory exercise, a security review of each script, and implementation of SRI hashes for every external script.

The requirement is a direct response to Magecart-style attacks, where attackers inject malicious JavaScript into payment pages to skim card data. SRI ensures that if the external script is modified to include skimmer code, the browser will refuse to execute it. Requirement 11.6.1 complements this by requiring automated monitoring for changes to payment page scripts.

MFA expansion — what v4.0 added

Under v3.2.1, MFA was required for remote access to the cardholder data environment. Under v4.0, it is required for all access to the CDE — including local console access on servers in scope. This is a significant change for organizations where local server access was not MFA-protected. Jump servers, bastion hosts, and privileged access workstations must now enforce MFA even for direct console access.

The customized approach — opportunity and risk

PCI DSS 4.0 introduced the Customized Approach, which allows a merchant or service provider to implement a control that achieves the stated Customized Approach Objective using a method different from the defined approach. This is a significant flexibility, but it requires a Targeted Risk Analysis and QSA validation. Organizations that chose the Customized Approach without QSA guidance during the transition period may find their controls do not meet the documented objective in an assessment.

Closing

The March 2025 deadline has passed. PCI DSS 4.0.1 is the current standard and all future-dated requirements are mandatory. Organizations that are not compliant face increased scrutiny at their next QSA assessment and risk standing in their merchant agreement with acquiring banks. Prioritize Requirement 6.4 script security, MFA expansion to all CDE access, and the new change-detection monitoring requirements. The compliance debt from delaying the transition is now an urgent remediation program.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.