PCI DSS 4.0: What Payment Processors Must Do Now

PCI DSS 4.0 is no longer a future concern — it is the current standard. As of March 31, 2025, all 64 new requirements in PCI DSS 4.0 are fully enforceable, including the 13 previously “future-dated” controls that many organizations had been deferring. For payment processors, money transfer operators, and fintechs handling card data, the window for gradual adoption has closed. This guide covers what changed, where organizations are falling short, and how to turn PCI DSS 4.0 compliance into a competitive advantage.

What Changed: PCI DSS 3.2.1 to 4.0

PCI DSS 4.0, published by the PCI Security Standards Council (PCI SSC) in March 2022, represents the most significant overhaul of the Payment Card Industry Data Security Standard since its inception. The previous version, PCI DSS 3.2.1, had been in effect since May 2018. After a two-year transition period, PCI DSS 3.2.1 was officially retired on March 31, 2024. One year later, on March 31, 2025, the remaining future-dated requirements in PCI DSS 4.0 became mandatory.

The fundamental shift is philosophical. PCI DSS 3.2.1 was largely prescriptive — it told organizations exactly what to do, step by step. PCI DSS 4.0 is outcome-based. It defines security objectives and allows organizations to meet them through either the traditional defined approach or a new customized approach that accepts alternative controls, provided the organization can demonstrate they achieve the same security outcome.

This flexibility comes with a trade-off: greater responsibility. Organizations using the customized approach must document a targeted risk analysis for each alternative control, maintain evidence that the control is effective, and have it validated by a Qualified Security Assessor (QSA). The standard now expects security to be a continuous process, not an annual checkbox exercise.

Key themes across PCI DSS 4.0 include:

• Continuous validation: Security controls must be monitored and tested on an ongoing basis, not just at assessment time
• Enhanced authentication: Multi-factor authentication (MFA) requirements expanded beyond remote access to cover all access to the cardholder data environment (CDE)
• Client-side security: New requirements address threats in the browser, including script integrity monitoring and content security policies
• Risk-based flexibility: Targeted risk analyses replace rigid frequency mandates for several controls, letting organizations calibrate effort to their actual threat landscape
• Accountability: Roles and responsibilities must be explicitly documented for every requirement — no more ambiguity about who owns what

The 13 Future-Dated Requirements Now in Effect

When PCI DSS 4.0 launched, 13 requirements were designated as “future-dated” — best practices until March 31, 2025, after which they became mandatory. That deadline has passed. Every organization subject to PCI DSS must now comply with all of these controls. Here are the most impactful:

Requirement 6.4.3: Client-Side Script Integrity Monitoring

This is widely regarded as the single most challenging new requirement. It mandates that all payment page scripts loaded in the consumer’s browser be inventoried, authorized, and monitored for integrity. The requirement directly targets Magecart-style attacks and digital skimming, where malicious JavaScript is injected into checkout pages to harvest card data in real time.

Meeting Requirement 6.4.3 means maintaining a complete inventory of every script executed on payment pages, implementing a mechanism to detect unauthorized changes or additions, and having a process to alert and respond when tampering is detected. For organizations with complex front-end architectures — single-page applications, third-party analytics, A/B testing tools — this is a substantial undertaking.

Requirement 6.4.2: Content Security Policy for Payment Pages

Closely related to 6.4.3, this requirement calls for a mechanism (typically HTTP Content-Security-Policy headers) to control which scripts can execute on payment pages. Together, 6.4.2 and 6.4.3 create a defense-in-depth approach against client-side attacks.

Requirement 11.3.1.1: Authenticated Internal Vulnerability Scans

Internal vulnerability scans must now be performed with credentials — authenticated scans that can detect vulnerabilities hidden behind login screens or access controls. Unauthenticated scans alone are no longer sufficient.

Requirement 12.3.2: Targeted Risk Analysis

Several PCI DSS 4.0 requirements allow organizations to determine the frequency of certain activities (such as log reviews, password changes, or vulnerability scans) based on a targeted risk analysis rather than a fixed schedule. Requirement 12.3.2 defines how that risk analysis must be performed and documented. Organizations that fail to complete these analyses cannot justify any deviation from default frequencies.

Other Key Future-Dated Requirements

• Req 3.5.1.2: Disk-level encryption is no longer acceptable for protecting stored account data on removable media; organizations must use data-level encryption
• Req 5.3.3 & 5.4.1: Anti-malware solutions must cover all system components, and phishing protections must be implemented through technical controls
• Req 8.4.2: MFA is required for all access into the cardholder data environment, not just remote access
• Req 8.6.3: Passwords and passphrases for application and system accounts must be managed securely, with protections against hard-coded credentials
• Req 10.4.1.1: Automated log review mechanisms must be in place to detect anomalies and trigger alerts
• Req 11.6.1: Change-detection mechanisms must alert on unauthorized modifications to HTTP headers and payment page content

Where Most Organizations Are Falling Short

With global card fraud losses projected to exceed $40 billion by 2027 according to the Nilson Report, the stakes for getting PCI DSS 4.0 compliance right have never been higher. Yet several areas consistently emerge as pain points during assessments:

Client-Side JavaScript Inventory

Requirement 6.4.3 is the number-one compliance gap across the industry. Most organizations have never catalogued the scripts running on their payment pages. Third-party tag managers, analytics libraries, social media pixels, and advertising scripts create a sprawling attack surface that few security teams have visibility into. Building and maintaining an accurate inventory — and implementing real-time monitoring for unauthorized changes — requires tooling and processes that simply did not exist in most organizations before PCI DSS 4.0.

Automated Log Review

Requirement 10.4.1.1 demands automated mechanisms to review audit logs and detect anomalies. Many organizations still rely on manual log reviews or have SIEM deployments that generate alerts without meaningful triage workflows. The requirement is not satisfied by simply collecting logs — there must be active, automated analysis with documented alerting and response procedures.

Risk-Based Approach Documentation

Organizations that opt to use targeted risk analyses to set control frequencies under Requirement 12.3.2 often underestimate the documentation burden. Each risk analysis must identify the assets being protected, the threats and vulnerabilities, the likelihood and impact of exploitation, and the resulting control frequency. QSAs are scrutinizing these documents closely, and vague or boilerplate risk analyses will not pass muster.

Sensitive Authentication Data (SAD) Encryption Before Authorization

PCI DSS 4.0 strengthens protections for sensitive authentication data — full track data, CAV2/CVC2/CVV2 values, and PINs — requiring that it be rendered unreadable through strong cryptography if stored prior to authorization completion. Organizations that temporarily cache SAD during the transaction flow must ensure encryption is applied immediately, not just at rest.

Why Your Processor’s PCI Level Matters

Not all PCI DSS validations are created equal. The card networks assign compliance levels to merchants and service providers based on transaction volume, and the validation requirements differ dramatically between levels.

PCI Level 1 Service Providers

A PCI Level 1 service provider — any entity that stores, processes, or transmits more than 300,000 card transactions annually on behalf of other businesses — faces the most rigorous validation requirements:

• Annual on-site assessment by a Qualified Security Assessor (QSA), resulting in a Report on Compliance (ROC)
• Quarterly network vulnerability scans by an Approved Scanning Vendor (ASV)
• Annual penetration testing of both external and internal environments
• Attestation of Compliance (AOC) signed by the QSA and a company officer

Level 2 through Level 4 service providers may self-assess using a Self-Assessment Questionnaire (SAQ), which involves less scrutiny and no independent on-site verification.

Downstream Risk Inheritance

When a fintech, money transfer operator, or merchant relies on a payment processor, the processor’s PCI compliance level directly affects the security posture of every entity in the chain. This is the shared responsibility model in practice: the processor is responsible for securing the infrastructure and services within its scope, while the client is responsible for how they integrate with and use those services.

If your processor holds only a Level 2 self-assessment, there is no independent verification that their controls are actually implemented and effective. A Level 1 processor with a QSA-validated ROC provides a substantially higher degree of assurance — and that assurance flows downstream to every client relying on that processor’s infrastructure.

Acquiring banks and card network sponsors increasingly require their partners to use Level 1 service providers. In the account funding transaction (AFT) space, where card-based money transfers are under heightened regulatory scrutiny, this requirement is becoming standard.

How MTOs and Fintechs Can Simplify PCI Scope

The best way to comply with PCI DSS 4.0 is to reduce the number of requirements that apply to your organization in the first place. Scope reduction strategies shift the burden of cardholder data protection to a PCI-compliant service provider, letting MTOs and fintechs focus on their core business.

Tokenization

Tokenization replaces card numbers with non-reversible tokens that have no exploitable value if stolen. When your payment processor handles tokenization, your systems never store, process, or transmit actual card data. This can reduce your applicable PCI DSS requirements from over 300 controls to a fraction of that.

For fintechs building on a payment orchestration platform, tokenization at the processor level means you can route transactions across multiple acquiring banks without ever handling raw card numbers.

Hosted Payment Pages

Hosted payment pages (also called hosted payment fields or iframes) are served directly from the processor’s PCI-certified environment. The cardholder enters their payment information on a page controlled by the processor, even though it appears to be part of your website or application. Since card data never touches your servers, your PCI scope shrinks to SAQ A or SAQ A-EP levels — eliminating the need to comply with the most demanding requirements around data storage, encryption, and network segmentation.

Hosted payment pages also eliminate your exposure to Requirement 6.4.3 (client-side script monitoring on payment pages), since the payment page is within the processor’s CDE, not yours.

P2PE Terminals

Point-to-Point Encryption (P2PE) terminals encrypt card data at the point of interaction — the moment a card is dipped, tapped, or swiped — and that data remains encrypted until it reaches the processor’s secure decryption environment. For money transfer agents using smart terminals in retail locations, P2PE devices dramatically reduce PCI scope because the merchant environment never has access to cleartext card data.

PCI-validated P2PE solutions come with their own compliance shortcut: merchants using a P2PE-listed device from a validated provider can qualify for SAQ P2PE, the shortest self-assessment questionnaire available.

The Sponsor Model

Fintechs operating under a sponsor bank or payment facilitator model can inherit significant PCI compliance coverage from their sponsor. The sponsor’s PCI-certified infrastructure handles card processing, while the fintech operates within defined integration boundaries. This model is particularly effective for startups and scaling companies that lack the resources to build and maintain a fully PCI-compliant infrastructure independently.

Compliance as Competitive Advantage

For payment processors and service providers, PCI DSS compliance is more than a regulatory obligation — it is a sales asset. In an industry where trust is currency, the ability to produce a current Attestation of Compliance can be the deciding factor in winning enterprise accounts.

SOC 2 Type II + PCI Level 1 = Enterprise Readiness

Enterprise clients, banks, and card network sponsors evaluate payment partners on the strength of their security posture. The combination of PCI DSS Level 1 certification and SOC 2 Type II attestation has become the baseline expectation for serious contenders. PCI DSS validates that cardholder data is protected according to industry standards. SOC 2 Type II validates that the organization’s broader operational controls — availability, processing integrity, confidentiality, and privacy — have been independently audited over a sustained period.

Together, these certifications signal to prospective clients and partners that a processor takes security seriously, has invested in the infrastructure and processes to back it up, and submits to independent verification on an ongoing basis.

Compliance as a Sales Tool

In competitive evaluations, compliance documentation often determines which processors make the shortlist. Banks and sponsors conduct due diligence on every service provider in their ecosystem, and the quality and currency of compliance artifacts — AOCs, ROCs, penetration test summaries, incident response plans — can accelerate or derail the onboarding process.

Processors that proactively share their compliance posture, maintain up-to-date documentation, and can articulate how their controls map to PCI DSS 4.0 requirements have a measurable advantage in shortening sales cycles and expanding partnerships.

Checklist: Questions to Ask Your Payment Processor

Whether you are evaluating a new payment processor or assessing your current provider’s PCI DSS 4.0 readiness, these questions will help you gauge their compliance posture:

Frequently Asked Questions

Related Articles