PCI DSS 4.0 requirements became the only active version of the Payment Card Industry Data Security Standard in March 2024, when version 3.2.1 was officially retired. For SaaS companies that handle payment card data, the transition is not optional — and several of the most significant changes in version 4.0 require meaningful implementation work that many organizations have not yet completed.
This post covers the most impactful PCI DSS 4.0 requirements changes, what they require in practice, and how SaaS companies should prioritize their compliance response. For an overview of foundational security policies that support PCI DSS compliance, see our post on the 7 security policies every SaaS company needs.
What PCI DSS 4.0 Changed and Why It Matters
PCI DSS 4.0 represents the most substantial revision to the standard since version 3.0 was released in 2013. The PCI Security Standards Council developed version 4.0 in response to the evolving threat landscape — particularly the growth in e-commerce fraud, web skimming attacks, and sophisticated credential compromise techniques that were not adequately addressed by the previous standard.
The revision also introduced a significant structural change: the Customized Approach. Previous versions of PCI DSS required prescriptive implementation of specific controls. PCI DSS 4.0 allows organizations to meet the intent of each requirement through alternative means — provided they can document how their customized implementation meets the stated security objective. However, this flexibility is primarily relevant for large, sophisticated organizations with mature security programs. For most SaaS companies, the Defined Approach — implementing the standard controls as specified — remains the practical path.
The Most Significant Changes in PCI DSS 4.0
Several changes in PCI DSS 4.0 requirements have direct and material implications for SaaS companies. Specifically, four areas require the most immediate implementation attention.
Multi-factor authentication requirements are substantially expanded. PCI DSS 4.0 requires MFA for all access into the cardholder data environment — not just remote access as under version 3.2.1. This means MFA is now required for all administrative access to CDE systems, regardless of whether the access originates from inside or outside the network perimeter. For SaaS companies with internal access to payment-related infrastructure, this is a significant control change.
Web application security requirements are strengthened. Requirement 6.4 now mandates automated technical solutions for detecting and preventing web-based attacks against payment pages. For SaaS companies with web-based payment flows, this means deploying and maintaining a web application firewall or equivalent technology — and documenting its configuration and monitoring.
Password and authentication requirements are updated. PCI DSS 4.0 requires a minimum password length of 12 characters rather than the previous 7-character minimum. All application and system accounts — not just user accounts — must meet the new requirements. Additionally, targeted risk analysis is now required for several previously prescriptive requirements. Organizations must document a targeted risk analysis to justify the frequency of activities like log reviews, vulnerability scans, and access reviews where the standard now provides flexibility in timing.
PCI DSS 4.0 Requirements: The New E-Commerce Skimming Controls
One of the most practically significant additions in PCI DSS 4.0 is the set of controls designed to address e-commerce skimming — attacks that inject malicious scripts into payment pages to capture cardholder data in real time.
Requirement 6.4.3 now requires that all payment page scripts loaded and executed in the consumer’s browser are authorized, have their integrity managed, and are inventoried. This means SaaS companies with web-based payment forms must maintain a complete inventory of all scripts loaded by payment pages, implement integrity checks — such as subresource integrity attributes — for those scripts, and establish a process for reviewing and reauthorizing scripts when they change.
For SaaS companies using third-party payment iframes or hosted payment pages, the scope of this requirement may be limited. For companies rendering payment forms within their own application, this requirement demands meaningful implementation work that many have not yet begun.
How to Prioritize Your PCI DSS 4.0 Compliance Response
The most effective way to prioritize your PCI DSS 4.0 compliance response is to start with a gap assessment that compares your current controls against the version 4.0 requirements specifically — not version 3.2.1, which your program may already satisfy.
The highest-priority changes for most SaaS companies are MFA for all CDE access, the web application security requirements for payment pages, and the updated password length requirements. These three areas represent the most common gaps in organizations transitioning from version 3.2.1 and the changes most likely to be cited in validation assessments. For SaaS companies that also need to address vCISO services to lead this work, see our post on vCISO services for SaaS companies.
The targeted risk analysis requirement, while less technically demanding, requires documentation work that should be completed for each affected requirement before your next compliance validation. Engaging your Qualified Security Assessor early in the compliance cycle allows you to confirm which requirements trigger the targeted risk analysis documentation and what format will satisfy the validation.
What Happens If You Have Not Addressed PCI DSS 4.0
Organizations that have not yet addressed the changes required by PCI DSS 4.0 are operating out of compliance with the current standard. The practical consequence depends on your relationship with your acquiring bank and payment processor — non-compliance can result in increased transaction fees, requirements to complete remediation on a defined timeline, or in severe cases, loss of the ability to accept card payments.
For SaaS companies that provide payment functionality to other merchants, non-compliance creates downstream liability as well. If your platform is used by merchants who are themselves required to maintain PCI DSS compliance, your failure to meet the current standard may affect their compliance status. The path forward is a current-state gap assessment against PCI DSS 4.0 requirements, a prioritized remediation roadmap, and a realistic timeline for completing the required changes before your next compliance validation.
Has your SaaS company assessed its PCI DSS 4.0 compliance posture? A gap assessment gives you the clarity to act before your next validation. Book a free strategy call at giovelasco.com/contact.
— Giovanni Velasco · CISSP · Security Growth Partner · giovelasco.com