PCI DSS 4.0 Compliance: What You Need to Know

PCI Compliance

PCI DSS 4.0 Compliance: What You Need to Know

On March 31, 2024, PCI DSS version 3.2.1 was officially retired. If your business accepts, processes, transmits, or stores cardholder data, you are now required to comply with PCI DSS version 4.0 — the most significant overhaul of the Payment Card Industry Data Security Standard in over a decade. Missing this transition is not simply a paperwork issue; non-compliance can result in fines from card brands, increased transaction fees, and in serious cases, loss of the ability to process card payments altogether.

This guide breaks down everything merchants, payment facilitators, SaaS platforms, and financial institutions need to understand about PCI DSS 4.0 — from what changed to how to reduce your compliance burden significantly.

What Changed in PCI DSS 4.0

PCI DSS 4.0 was published in March 2022, giving organizations a two-year runway to transition. The revision was driven by the evolving threat landscape, the proliferation of cloud environments, and the need for more flexibility in how organizations demonstrate security. Here are the headline changes:

• Customized Approach: For the first time, organizations can use a "Customized Approach" to meet the intent of a requirement using alternative controls, rather than following prescriptive defined approaches. This provides flexibility for mature security programs but requires significantly more documentation and assessment.
• Targeted Risk Analysis (TRA): Many requirements that previously had fixed frequencies (e.g., "review logs every X days") now require organizations to perform a Targeted Risk Analysis to determine an appropriate frequency based on their specific risk profile.
• Authentication Overhaul: Multi-factor authentication (MFA) is now required for all access into the cardholder data environment (CDE), not just remote access. Passwords must be at least 12 characters (up from 8) and complexity rules have been tightened.
• E-commerce and Phishing Focus: New requirements address the security of payment page scripts, protecting against web skimming attacks (Magecart-style), and enhanced anti-phishing controls.
• Roles and Responsibilities: Every requirement now explicitly demands that organizations document who is responsible for fulfilling that requirement — a significant documentation lift for many businesses.

Compliance Timeline

Understanding the PCI DSS 4.0 timeline is critical because the standard introduced a phased approach to some of its new requirements:

• March 31, 2022: PCI DSS v4.0 published and available for use.
• March 31, 2024: PCI DSS v3.2.1 retired. All assessments must now be against v4.0.
• March 31, 2025: All "future-dated" requirements in v4.0 become mandatory. These were requirements flagged as best practices in the initial 4.0 release to give organizations time to prepare.

The March 2025 deadline is the critical one. Approximately 64 requirements were designated as "best practice until March 31, 2025." If your organization completed a 4.0 assessment before that date, you may have passed even without implementing these. From April 1, 2025 onward, all 64 requirements are fully mandatory and will be tested during assessments.

The 12 Core Requirements

PCI DSS is organized around 12 high-level requirements, which remain in v4.0 but with significant sub-requirement changes:

Key New Requirements in PCI DSS 4.0

Beyond the structural changes, these are the specific new requirements that will affect most organizations:

Web Skimming Protection (Requirement 6.4.3 and 11.6.1)

For e-commerce merchants that use payment pages, PCI DSS 4.0 introduces two new requirements addressing JavaScript skimming attacks — malicious scripts injected into checkout pages to steal card data. Organizations must now maintain an inventory of all scripts loaded on payment pages, justify why each is necessary, and detect unauthorized modifications to HTTP headers and payment page content. This is a significant change for any business using third-party scripts, tag managers, or CDNs on checkout pages.

MFA for All CDE Access (Requirement 8.4.2)

Multi-factor authentication is now required for all non-console administrative access and all user access to the cardholder data environment. Previously, MFA was only mandated for remote access. This means even internal users accessing CDE systems from within the corporate network must use MFA.

Stronger Password Requirements (Requirement 8.3.6)

Passwords must now be a minimum of 12 characters (previously 8), or at least 8 characters if the system doesn't support 12. This seemingly simple change requires updates to identity management systems, user training, and potentially password manager deployments.

Targeted Risk Analysis (Multiple Requirements)

Many previously prescriptive requirements now include a "perform a targeted risk analysis" option, allowing organizations to set their own frequencies for activities like log reviews, vulnerability scans, and access reviews — provided they document their risk-based rationale. This increases flexibility but also documentation burden.

Self-Assessment Questionnaires in PCI DSS 4.0

Not every organization needs a Qualified Security Assessor (QSA) to perform a full audit. Most small and mid-size merchants can use a Self-Assessment Questionnaire (SAQ). PCI DSS 4.0 updated all SAQ forms to align with the new requirements. The key SAQ types are:

• SAQ A: For e-commerce or mail/telephone-order merchants that have fully outsourced all cardholder data functions. Card data is handled entirely by a PCI-compliant third party. This is the simplest SAQ with the fewest requirements.
• SAQ A-EP: For e-commerce merchants that outsource payment processing but whose website affects the security of the transaction (e.g., redirects to payment page). Now includes web skimming requirements.
• SAQ B: For merchants using imprint machines or standalone dial-out terminals only, with no electronic cardholder data storage.
• SAQ B-IP: For merchants using standalone IP-connected PTS-approved payment terminals.
• SAQ C: For merchants with payment application systems connected to the internet but no electronic cardholder data storage.
• SAQ D: For all other merchants and all service providers. The most comprehensive SAQ.

Choosing the right SAQ depends entirely on your payment acceptance environment. Using an integrated payment solution that keeps cardholder data out of your systems entirely can allow you to qualify for SAQ A — the most straightforward path to compliance.

How TIB Finance Reduces Your PCI Scope

The most effective strategy for PCI DSS compliance is not to become expert in all 300+ requirements — it is to reduce the scope of your cardholder data environment as much as possible. Scope reduction means fewer systems, fewer requirements, and less risk.

TIB Finance is designed with PCI scope reduction as a core architectural principle:

• Hosted Payment Fields: TIB Finance's JavaScript payment fields capture card data directly within TIB Finance's PCI-compliant infrastructure. Raw card numbers never touch your servers, which means your web application and database servers are out of scope for most PCI requirements.
• Tokenization: After a card is processed, TIB Finance returns a reusable payment token. You can store this token safely to charge customers again later — without ever storing actual card data. Learn more about tokenization vs encryption.
• P2PE-Ready Processing: For card-present environments, TIB Finance supports Point-to-Point Encryption (P2PE) solutions that encrypt card data at the device before it enters your network, dramatically reducing your POS environment's PCI scope.
• SAQ A Eligibility: By integrating with TIB Finance's hosted payment page or hosted fields, most e-commerce merchants become eligible for SAQ A — the simplest and smallest self-assessment questionnaire.
• Built-in Security Controls: TIB Finance's infrastructure is assessed annually by a QSA and maintains a current Attestation of Compliance (AOC). When your cardholder data is in our environment, you benefit from our compliance program.

Your Action Plan

If you are unsure of your current compliance status, here is a practical starting point:

1. Define your cardholder data environment. Where does card data flow? Map every system that touches, stores, processes, or transmits cardholder data.
2. Identify your merchant level. Your transaction volume determines whether you need a QSA assessment or can use an SAQ. See the PCI compliance guide for business owners for an overview of merchant levels.
3. Choose the right SAQ. Based on how you accept payments, select the SAQ that applies to your environment.
4. Address the 4.0 gap requirements. Review PCI SSC's summary of changes document and identify which new requirements apply to your environment, especially the web skimming and MFA requirements.
5. Implement scope reduction. If you are using a payment integration that brings card data into your environment, evaluate whether a tokenized or hosted solution from a processor like TIB Finance could move those systems out of scope.
6. Complete your assessment. Work through your SAQ or engage a QSA, document your controls, and submit your Attestation of Compliance to your acquiring bank.

PCI DSS 4.0 is a meaningful upgrade to payment security standards — and while the compliance effort is real, the underlying goal is protecting your customers and your business from the very real cost of a data breach. The average cost of a payment card data breach runs into millions of dollars in fines, remediation, and reputational damage.

For a broader overview of payment security practices, see our guide to Payment Security Best Practices for 2025. If you are integrating payments into a software platform, our Payment API Integration Guide covers the technical details of building a secure, compliant integration.