PCI DSS Compliance v4.0: What You Must Implement

Introduction

In 2023, data breaches involving payment card information cost the global economy over USD 33 billion in fraud losses. PCI DSS exists specifically because the card brands — Visa, Mastercard, American Express, Discover, and JCB — determined that merchants and service providers could not be trusted to secure cardholder data without contractual mandates backed by financial penalties.

PCI DSS compliance is not optional if you want to accept card payments. It is a contractual requirement embedded in your merchant agreement. Failure to comply does not result in regulatory fines from a government agency — it results in fines from your acquiring bank (USD 5,000 to USD 100,000 per month), liability for fraud losses from compromised cards, and ultimately the termination of your ability to process payments. Visa and Mastercard can remove your ability to accept their cards entirely.

PCI DSS v3.2.1 was retired on March 31, 2024. The current standard is v4.0.1, which became fully mandatory on March 31, 2025. This article explains what changed, what the 12 requirements demand, and what your security team must have in place right now.

What Is PCI DSS?

PCI DSS (Payment Card Industry Data Security Standard) is a set of technical and operational security requirements developed by the PCI Security Standards Council (PCI SSC) — a consortium founded by the major card brands. The current version is v4.0.1, published in June 2024.

Who must comply:

• Merchants that store, process, or transmit cardholder data
• Service providers that store, process, or transmit cardholder data on behalf of merchants
• Any entity whose systems can affect the security of the cardholder data environment (CDE)

Compliance levels: Determined by annual transaction volume. Level 1 merchants (over 6 million card transactions per year) must undergo an annual on-site QSA assessment and quarterly network scans. Level 4 merchants (fewer than 20,000 e-commerce or 1 million other transactions) can self-assess using the appropriate SAQ type.

The CDE: The cardholder data environment includes all system components — people, processes, and technology — that store, process, or transmit cardholder data. Systems connected to the CDE that could affect its security are also in scope. CDE scope reduction — via tokenization, point-to-point encryption (P2PE), or network segmentation — is one of the most impactful things an organization can do to reduce PCI DSS compliance burden.

How PCI DSS v4.0 Works

What Changed from v3.2.1

PCI DSS v4.0 introduced over 60 new requirements compared to v3.2.1. The most significant changes affecting data security teams are:

Requirement 12.3.3 — Cryptographic Inventory (new, mandatory from March 2025): Organizations must maintain a documented inventory of all cryptographic algorithms, cipher suites, and protocols in use across all in-scope systems. This inventory must be reviewed annually, and a documented response plan must exist for when a cipher suite is found to be vulnerable.

Requirement 6.4.3 and 11.6.1 — Client-Side Security (new): All payment page scripts must be authorized and their integrity verified. A change detection mechanism must alert when unauthorized modifications occur. This targets Magecart-style attacks where attackers inject JavaScript skimmers onto e-commerce checkout pages.

Requirement 8.4.2 — MFA for All Access (expanded): Multi-factor authentication is now required for all access to the CDE — not just remote access. Previously, MFA was mandated only for non-console administrative access. Now it applies to any user accessing the CDE, even from inside the corporate network.

Customized Approach (new methodology): Organizations can now meet PCI DSS objectives using controls different from the standard’s prescriptive requirements if they can demonstrate the objective is achieved. This is a significant shift toward risk-based security assessment.

The 12 Requirements at a Glance

The 12 PCI DSS requirements are organized into six goals:

Build and Maintain a Secure Network:

• Req 1: Install and maintain network security controls (firewalls, segmentation)
• Req 2: Apply secure configurations to all system components

Protect Account Data:

• Req 3: Protect stored account data (encryption, prohibited data elements)
• Req 4: Protect cardholder data with strong cryptography during transmission

Maintain a Vulnerability Management Program:

• Req 5: Protect all systems against malware
• Req 6: Develop and maintain secure systems and software

Implement Strong Access Control Measures:

• Req 7: Restrict access to system components and cardholder data by business need-to-know
• Req 8: Identify users and authenticate access to system components
• Req 9: Restrict physical access to cardholder data

Regularly Monitor and Test Networks:

• Req 10: Log and monitor all access to system components and cardholder data
• Req 11: Test security of systems and networks regularly

Maintain an Information Security Policy:

• Req 12: Support information security with organizational policies and programs

VIDEO · READY 16:9

PLAY

PCI DSS Compliance Overview

PCI DSS Compliance Checklist

This checklist covers the most critical controls across the 12 requirements, with emphasis on v4.0’s new mandatory requirements effective March 2025.

Requirement 3 — Protection of Stored Account Data

1. Confirm: full magnetic stripe data is never stored after authorization (Req 3.3.1)
2. Confirm: CVV/CVC is never stored after authorization under any circumstances (Req 3.3.2)
3. Confirm: PIN and PIN block are never stored after authorization (Req 3.3.3)
4. PAN rendering: all stored PANs are rendered unreadable using strong cryptography (Req 3.5.1) — AES-256 recommended
5. Cryptographic key management policy documented covering: key generation, distribution, storage, rotation, and destruction (Req 3.7)
6. Keys stored securely using split knowledge and dual control — no single person has access to all key components (Req 3.7.1)
7. Annual key rotation documented for all keys protecting stored cardholder data (Req 3.7.4)
8. Disk-level encryption not used as sole protection for CDE systems (Req 3.5.1.3)

Requirement 4 — Cardholder Data in Transit

1. Strong cryptography used for all cardholder data in transit over open, public networks (Req 4.2.1)
2. TLS 1.2 minimum enforced — TLS 1.0 and 1.1 disabled (NIST SP 800-52 Rev 2)
3. Certificate management: all TLS certificates are from trusted CAs, not expired, not self-signed on production (Req 4.2.1.1)
4. Payment page: no cardholder data transmitted in cleartext via browser redirects or API calls

Requirement 6 — Secure Systems and Software

1. All payment page scripts inventoried and authorized (Req 6.4.3 — new, mandatory March 2025)
2. Script integrity verified — hash or Subresource Integrity (SRI) implemented for all scripts (Req 6.4.3)
3. Change detection mechanism in place to alert on unauthorized script modifications (Req 11.6.1 — new)
4. Vulnerability scanning: authenticated internal scans quarterly; external scans by ASV quarterly (Req 6.3.2, Req 11.3)

Requirement 8 — Authentication and Access

1. MFA enforced for ALL access to CDE — not just remote access (Req 8.4.2 — expanded in v4.0)
2. No shared or generic accounts in the CDE (Req 8.2.2)
3. Password minimum 12 characters (Req 8.3.6 — increased from 7 in v3.2.1)
4. Account lockout after maximum 10 failed login attempts (Req 8.3.4)
5. Inactive accounts disabled after 90 days (Req 8.2.6)

Requirement 10 — Logging and Monitoring

1. All access to cardholder data logged with: user, date/time, action, type of data accessed (Req 10.2)
2. Logs protected from modification and unauthorized access (Req 10.5)
3. Log retention: minimum 12 months with 3 months immediately available (Req 10.7)
4. Automated alerts for critical security events (Req 10.6, 10.7.1)

Requirement 12 — Organizational Policies

1. Cryptographic cipher suite inventory documented for all in-scope systems (Req 12.3.3 — new, mandatory March 2025)
2. Annual review of cryptographic inventory completed and documented (Req 12.3.3)
3. Documented response plan for compromised or vulnerable cryptographic algorithms (Req 12.3.3)
4. Annual PCI DSS scope review confirming all CDE systems are identified (Req 12.5.2)
5. Penetration testing: annual network and application penetration testing by qualified tester (Req 11.4)

Scope Reduction (strongly recommended)

1. Tokenization implemented for payment data storage — reduces Req 3 scope significantly
2. Point-to-point encryption (P2PE) solution validated by PCI SSC — removes terminal devices from CDE scope
3. Network segmentation controls documented and tested to confirm CDE isolation (Req 11.4.1)

PCI DSS v4.0 vs v3.2.1

The table reveals the direction of travel: v4.0 closes specific attack vectors that have caused major breaches in recent years. Magecart-style script injection attacks drove Requirements 6.4.3 and 11.6.1. Credential stuffing and brute-force attacks drove the expanded MFA requirement (8.4.2) and the longer minimum password length (8.3.6).

Real-World Use Cases

E-commerce merchants: An online retailer processing card payments must ensure their payment page scripts are inventoried under Req 6.4.3. If they use a third-party checkout widget (Stripe.js, Braintree), they must verify the script’s integrity hash and implement a change detection alert. A compromised or modified payment script that exfiltrates card numbers can result in a forensic investigation mandated by Visa or Mastercard, with the merchant bearing the cost.

SaaS payment platforms: A SaaS company providing billing services to other businesses acts as a Level 1 service provider if it processes over 300,000 card transactions annually. It requires an annual QSA assessment and quarterly ASV scans. Its customers need to verify the SaaS provider’s PCI DSS compliance via their current Attestation of Compliance (AOC) before storing their customers’ card data with them.

Point-of-sale merchants: A retail chain using dedicated POS terminals can dramatically reduce PCI DSS scope by deploying a PCI-validated P2PE solution. Validated P2PE encrypts card data at the point of swipe or tap, before it enters any network the merchant controls. This removes POS terminals from CDE scope and reduces the applicable SAQ to SAQ P2PE with fewer than 40 requirements.

Common Mistakes to Avoid

Storing prohibited data elements. The most severe PCI DSS violation is storing CVV/CVC after authorization. CVV is used only for card-not-present verification — there is no legitimate reason to store it. Many breaches occur not because attackers bypassed encryption, but because developers stored CVV in a log file, a database column added for debugging, or a data warehouse for analytics. Regular data discovery scans across your entire environment are the only way to confirm prohibited data is absent.

Scope creep after the initial assessment. Systems added to your network after the initial CDE definition may inadvertently connect to in-scope systems and expand your CDE without anyone realizing it. New microservices, analytics pipelines, and internal tools frequently touch production databases. Every new system deployment requires a CDE scope review.

Policy rotation without log evidence. Requirement 12.3.3 mandates a documented cryptographic inventory reviewed annually. Having the inventory document without the annual review log produces a finding. Auditors ask for the review record, not just the document.

Missing MFA on internal CDE access. Many organizations implemented MFA for VPN and remote access but never extended it to internal access to the CDE. Requirement 8.4.2 in v4.0 closes this gap. Every user — including internal employees on the corporate network — must use MFA to access CDE systems. Legacy applications that cannot support MFA must be addressed through compensating controls or replaced.

Getting Started

Begin with a CDE scoping exercise. Map every system that touches cardholder data — application servers, databases, payment gateways, log aggregators, backup systems, and monitoring tools. For each system, determine whether it stores, processes, or transmits cardholder data directly, or whether it is connected to a system that does. Systems in the second category are still in scope.

Identify your compliance level based on annual transaction volume. If you are Level 1, engage a QSA. If you qualify for SAQ, select the correct SAQ type based on your payment processing method (SAQ A for fully outsourced card-not-present, SAQ D for direct card data processing).

Run the cryptographic inventory required by Req 12.3.3. Document every cipher suite, TLS version, and encryption algorithm in use across your CDE. Test against NIST SP 800-52 Rev 2 guidance — disable TLS 1.0, TLS 1.1, and any cipher suite using RC4, DES, or export-grade keys.

Implement MFA on all CDE access if you have not already. For systems that cannot natively support MFA, deploy a reverse proxy or identity-aware proxy in front of them.

For the related compliance framework covering payment data tokenization and scope reduction, read tokenization vs encryption: PCI-DSS and data protection. For the key management requirements behind Requirement 3, see hardware security modules: HSM vs KMS explained.