PCI DSS 4.0 Compliance: The Complete Guide for 2026

What Is PCI DSS?

The Payment Card Industry Data Security Standard (PCI DSS) is a set of security requirements designed to ensure that all organizations that accept, process, store, or transmit credit card information maintain a secure environment. Developed and maintained by the PCI Security Standards Council (PCI SSC) — founded by American Express, Discover, JCB International, Mastercard, and Visa — PCI DSS applies to any entity involved in payment card processing, regardless of size or transaction volume.

PCI DSS is not a law, but compliance is mandated contractually by the card brands through acquiring banks. Failure to comply can result in fines ranging from $5,000 to $100,000 per month, increased transaction fees, and in severe cases, the revocation of the ability to accept card payments altogether.

Who Needs PCI DSS Compliance?

If your organization handles cardholder data in any way, PCI DSS applies to you. This includes:

• Merchants — Brick-and-mortar retailers, e-commerce stores, and any business that accepts card payments
• Service providers — Payment processors, hosting providers, managed security services, and any third party that stores, processes, or transmits cardholder data on behalf of another entity
• Financial institutions — Banks, credit unions, and issuers involved in card transactions
• Software developers — Companies that build payment applications or integrate with payment systems

PCI DSS 4.0 — What Changed from 3.2.1

PCI DSS 4.0, released in March 2022, represents the most significant update to the standard in years. Version 3.2.1 was officially retired on March 31, 2024, and all organizations are now required to comply with PCI DSS 4.0. Additionally, many of the future-dated requirements in PCI DSS 4.0 became mandatory on March 31, 2025, making full compliance with the complete standard essential in 2026.

Key Changes in PCI DSS 4.0

1. The Customized Approach

PCI DSS 4.0 introduces a Customized Approach alongside the traditional Defined Approach. Organizations can now meet control objectives using alternative methods, provided they can demonstrate that the custom controls meet the intent of each requirement. This offers flexibility for organizations with mature security programs while maintaining the same level of protection.

2. Targeted Risk Analysis

Rather than a one-size-fits-all model, PCI DSS 4.0 requires targeted risk analysis for specific requirements. Organizations must evaluate the frequency of certain activities (such as log reviews and password changes) based on their unique risk environment, rather than relying on prescriptive timeframes alone.

3. Expanded Multi-Factor Authentication (MFA)

MFA is now required for all access to the cardholder data environment (CDE), not just remote access. This is a significant expansion from 3.2.1, where MFA was only explicitly required for remote administrative access.

4. Enhanced Authentication Requirements

Password requirements have been strengthened — minimum password length increased from 7 to 12 characters (or 8 characters if the system does not support 12). Dynamic analysis of passwords against known-bad lists is also encouraged.

5. New E-Commerce Requirements

PCI DSS 4.0 introduces specific requirements for e-commerce environments, including protections against payment page scripts. Requirement 6.4.3 mandates an inventory of all scripts on payment pages with explicit authorization, and Requirement 11.6.1 requires detection mechanisms for unauthorized changes to payment pages.

6. Continuous Security Focus

The standard shifts from point-in-time compliance to continuous security. Requirements around roles, responsibilities, and accountability have been strengthened throughout every requirement area, reinforcing that PCI DSS compliance is an ongoing operational discipline.

The 12 PCI DSS Requirements

PCI DSS is organized into 12 requirements grouped under 6 high-level goals:

Goal 1: Build and Maintain a Secure Network and Systems

Requirement 1: Install and Maintain Network Security Controls

Deploy firewalls and network security controls to protect the cardholder data environment. PCI DSS 4.0 broadened this from "firewalls" to "network security controls" to encompass modern technologies such as cloud security groups, SD-WAN, and zero-trust architectures.

Requirement 2: Apply Secure Configurations to All System Components

Do not use vendor-supplied defaults for system passwords and security parameters. All system components must be hardened according to industry-accepted standards before deployment into the CDE.

Goal 2: Protect Cardholder Data

Requirement 3: Protect Stored Account Data

Minimize data storage and implement strong encryption for any cardholder data that must be retained. PAN (Primary Account Number) must be rendered unreadable anywhere it is stored using methods such as encryption, truncation, tokenization, or hashing.

Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks

Encrypt cardholder data during transmission over open and public networks using strong cryptographic protocols. TLS 1.2 or higher is required; older protocols like SSL and early TLS are no longer acceptable.

Goal 3: Maintain a Vulnerability Management Program

Requirement 5: Protect All Systems and Networks from Malicious Software

Deploy anti-malware solutions on all systems commonly affected by malware. PCI DSS 4.0 expanded this beyond traditional anti-virus to address evolving threat types and extended coverage to more system types.

Requirement 6: Develop and Maintain Secure Systems and Software

Establish a process for identifying and addressing vulnerabilities in all system components. Apply critical security patches within one month of release. For custom software, follow secure development practices and conduct code reviews.

Goal 4: Implement Strong Access Control Measures

Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know

Implement role-based access control (RBAC) so that access to cardholder data and CDE systems is limited to individuals whose job requires it.

Requirement 8: Identify Users and Authenticate Access to System Components

Assign unique IDs to all users. Implement MFA for all access into the CDE. Enforce minimum 12-character passwords and regularly review access accounts.

Requirement 9: Restrict Physical Access to Cardholder Data

Use physical security controls such as badge readers, cameras, and visitor logs to restrict physical access to systems that store, process, or transmit cardholder data.

Goal 5: Regularly Monitor and Test Networks

Requirement 10: Log and Monitor All Access to System Components and Cardholder Data

Implement audit trails to link all access to system components and cardholder data to individual users. PCI DSS 4.0 emphasizes automated log review mechanisms and timely detection of anomalies.

Requirement 11: Test Security of Systems and Networks Regularly

Conduct regular vulnerability scans (quarterly ASV scans, internal scans) and annual penetration testing. PCI DSS 4.0 adds requirements for authenticated internal scanning and detection of unauthorized changes to payment pages.

Goal 6: Maintain an Information Security Policy

Requirement 12: Support Information Security with Organizational Policies and Programs

Maintain a comprehensive information security policy that addresses all PCI DSS requirements. Conduct annual risk assessments, implement a security awareness program, and manage third-party service provider relationships.

PCI DSS Compliance Levels

The card brands define four compliance levels for merchants based on annual transaction volume:

Level

Annual Transactions

Validation Requirements

Level 1	Over 6 million	Annual Report on Compliance (ROC) by a QSA + quarterly ASV scans
Level 2	1–6 million	Annual Self-Assessment Questionnaire (SAQ) + quarterly ASV scans
Level 3	20,000–1 million (e-commerce)	Annual SAQ + quarterly ASV scans
Level 4	Fewer than 20,000 (e-commerce) or up to 1 million (other)	Annual SAQ + quarterly ASV scans (recommended)

Service providers have two levels: Level 1 (over 300,000 transactions) requires a ROC, and Level 2 (fewer than 300,000) can complete an SAQ. Note that if your organization suffers a data breach, your acquirer may escalate you to Level 1 regardless of transaction volume.

SAQ Types — Which Self-Assessment Questionnaire Applies?

PCI DSS offers several SAQ types based on how your organization handles cardholder data:

SAQ A — For e-commerce or mail/telephone-order merchants that have fully outsourced all cardholder data functions to PCI-compliant third parties. No electronic storage, processing, or transmission of cardholder data on the merchant's systems.

SAQ A-EP — For e-commerce merchants that outsource payment processing but whose website can affect the security of the payment transaction (for example, merchants that host their own payment page that redirects to a third-party processor).

SAQ B — For merchants using only imprint machines or standalone dial-out terminals with no electronic cardholder data storage.

SAQ B-IP — For merchants using only standalone, PTS-approved payment terminals with an IP connection, with no electronic cardholder data storage.

SAQ C — For merchants with payment application systems connected to the Internet, with no electronic cardholder data storage.

SAQ C-VT — For merchants manually entering one transaction at a time via a virtual payment terminal provided by a PCI-compliant third-party service provider.

SAQ D — For all other merchants and all service providers not covered by the above SAQ types. This is the most comprehensive SAQ and covers all PCI DSS requirements.

ROC (Report on Compliance) — Required for Level 1 merchants and Level 1 service providers. Completed by a Qualified Security Assessor (QSA) or Internal Security Assessor (ISA).

The PCI DSS Assessment Process

1. Scope Definition

The most critical step. Identify all systems, people, and processes that store, process, or transmit cardholder data, as well as all systems connected to or that could affect the security of the CDE. Accurate scoping prevents both under-coverage (which creates risk) and over-coverage (which inflates costs).

2. Gap Assessment

Evaluate your current environment against all applicable PCI DSS requirements. Document where your controls meet, partially meet, or fail to meet each requirement. Prioritize gaps based on risk severity.

3. Remediation

Address identified gaps by implementing, upgrading, or reconfiguring controls. This phase typically involves technology deployments, process changes, policy updates, and staff training. Track remediation progress methodically.

4. Validation

Complete the appropriate validation instrument — SAQ for smaller merchants, ROC for Level 1 entities. Conduct quarterly network scans through an Approved Scanning Vendor (ASV). Perform penetration testing as required.

5. Report and Attestation

Submit the completed SAQ or ROC along with the Attestation of Compliance (AOC) to your acquiring bank or payment brand. Maintain all supporting evidence for ongoing compliance verification.

Common PCI DSS Challenges

Scope Creep

One of the most common and costly challenges. As environments evolve, new systems may be introduced that interact with cardholder data, expanding the scope of the assessment. Without rigorous network segmentation and change management, the CDE boundary can blur, leading to a significantly larger and more expensive compliance effort.

Network Segmentation Failures

Effective segmentation isolates the CDE from the rest of the corporate network, reducing the scope of PCI DSS compliance. However, misconfigured firewalls, overly permissive access rules, and undetected data flows can undermine segmentation, exposing the entire network to PCI DSS scope.

Third-Party Service Provider Risk

Many organizations rely on third-party providers for payment processing, hosting, and related services. PCI DSS Requirement 12.8 mandates a formal process for managing and monitoring service providers. Keeping track of provider compliance status, maintaining updated agreements, and ensuring responsibility matrices are defined is an ongoing challenge.

Logging and Monitoring Gaps

PCI DSS Requirement 10 demands comprehensive logging and timely review of log data. Many organizations struggle with the volume of log data, lack of centralized log management, and insufficient automated alerting — especially as PCI DSS 4.0 raises expectations for automated log review and anomaly detection.

Maintaining Continuous Compliance

PCI DSS 4.0 reinforces that compliance is not a once-a-year exercise. Organizations that treat the assessment as a point-in-time event often find themselves out of compliance between assessments, which creates both security risk and potential liability.

How Compliance Enablers Supports PCI DSS Compliance

Achieving and maintaining PCI DSS 4.0 compliance requires coordinated effort across multiple teams and systems. Compliance Enablers' GRC platform streamlines this process with capabilities purpose-built for complex compliance programs.

Pre-Built PCI DSS 4.0 Framework

Compliance Enablers includes a fully mapped PCI DSS 4.0 framework out of the box — all 12 requirements, organized by goals, with each sub-requirement mapped to corresponding controls. This eliminates weeks of manual framework setup and ensures nothing is missed.

Cross-Framework Control Mapping

With support for 261+ frameworks, Compliance Enablers maps PCI DSS controls to overlapping requirements in ISO 27001, SOC 2, HIPAA, NIST CSF, and others. Organizations pursuing multiple certifications can satisfy shared controls once and apply evidence across frameworks — reducing redundant effort by up to 60%.

Automated Evidence Collection

Across the platform's 27 integrated modules, evidence collection links directly to PCI DSS controls. Automated evidence gathering from connected systems reduces the manual burden of demonstrating compliance and ensures evidence is always current.

CDE Scoping and Asset Inventory

The asset inventory module helps organizations define and maintain an accurate CDE scope. Track all systems, applications, and network segments that interact with cardholder data, and flag when new assets enter the CDE boundary.

Vendor Risk Management

Manage third-party service provider compliance through dedicated vendor risk workflows. Track service provider PCI DSS compliance status, maintain responsibility matrices, and set review schedules — directly addressing Requirement 12.8.

Audit Management

Whether you are completing an SAQ or preparing for a QSA-led ROC, Compliance Enablers' audit management module organizes findings, tracks remediation, and maintains a complete audit trail from gap assessment through final report submission.

Continuous Monitoring

Move from point-in-time compliance to continuous assurance. Dashboards surface control health in real time, flag gaps before they become audit findings, and help security teams maintain PCI DSS compliance throughout the year — not just during assessment season.

PCI DSS Compliance Checklist

Use this checklist to track your progress toward PCI DSS 4.0 compliance:

• [ ] Determine your merchant or service provider level
• [ ] Identify the appropriate SAQ type or confirm ROC requirement
• [ ] Define your cardholder data environment (CDE) scope
• [ ] Implement and validate network segmentation
• [ ] Deploy network security controls (Requirement 1)
• [ ] Harden all system components — remove vendor defaults (Requirement 2)
• [ ] Encrypt stored cardholder data and minimize data retention (Requirement 3)
• [ ] Encrypt cardholder data in transit using TLS 1.2+ (Requirement 4)
• [ ] Deploy and maintain anti-malware solutions (Requirement 5)
• [ ] Establish secure development and patching processes (Requirement 6)
• [ ] Implement role-based access control (Requirement 7)
• [ ] Enforce MFA for all CDE access and 12-character minimum passwords (Requirement 8)
• [ ] Restrict and monitor physical access to the CDE (Requirement 9)
• [ ] Implement centralized logging and automated log review (Requirement 10)
• [ ] Conduct quarterly ASV scans and annual penetration testing (Requirement 11)
• [ ] Maintain information security policy and SA program (Requirement 12)
• [ ] Inventory and authorize all payment page scripts (Requirements 6.4.3, 11.6.1)
• [ ] Perform targeted risk analyses where required by PCI DSS 4.0
• [ ] Document and manage all third-party service provider relationships
• [ ] Submit SAQ/ROC and AOC to your acquiring bank

Get started with PCI DSS 4.0 compliance →