PCI DSS v4.0 Compliance Guide 2026

PCI DSS v4.0 is the current mandatory version of the Payment Card Industry Data Security Standard, governing cybersecurity requirements for every entity that stores, processes, or transmits payment card data. Version 3.2.1 was retired on March 31, 2024, and all assessments — whether conducted by a Qualified Security Assessor (QSA) or completed via Self-Assessment Questionnaire (SAQ) — must now be evaluated against v4.0 requirements. The v4.0 update is the most significant revision in the Standard’s history, introducing a customized approach that allows organizations to demonstrate compliance through risk-based controls rather than strictly prescriptive requirements. It also significantly expands multi-factor authentication scope, introduces targeted risk analysis for control frequency decisions, and adds new requirements addressing e-commerce security and anti-phishing controls. Non-compliance carries severe consequences: card brand fines of $5,000 to $100,000 per month, potential loss of the right to accept payment cards, and mandatory forensic investigation costs following a breach. This guide covers what v4.0 requires, how to scope your assessment, and how to identify and close the most common compliance gaps before engaging a QSA.

1. PCI DSS v4.0: What Changed and Why It Matters

PCI DSS v4.0 was released in March 2022, with an 18-month transition period that ended when v3.2.1 was formally retired on March 31, 2024. Organizations that filed their most recent Report on Compliance (RoC) or Attestation of Compliance (AoC) under v3.2.1 must now reassess under v4.0. The transition is not cosmetic — v4.0 contains 64 new requirements and significant revisions to existing ones.

The Customized Approach

The most significant structural change in v4.0 is the introduction of the customized approach as an alternative to the traditional defined approach. Under the customized approach, organizations can design and implement controls that meet the stated objective of a requirement, even if those controls differ from the prescriptive methods specified. This flexibility is intended for mature security programs with robust risk management capabilities. Each customized control must be supported by a targeted risk analysis demonstrating how it meets the requirement’s stated objective, and must be assessed by a QSA.

Targeted Risk Analysis for Control Frequency

v4.0 introduced targeted risk analysis (TRA) as a mechanism for organizations to determine the appropriate frequency for certain controls rather than accepting default prescribed intervals. For example, rather than mandating quarterly log reviews, v4.0 allows an organization to define a review frequency based on its assessed risk, supported by documented analysis. TRA must be performed annually, reviewed by the management team, and retained as evidence.

Expanded MFA Scope

v4.0 substantially expands the scope of multi-factor authentication requirements. Under v3.2.1, MFA was required only for remote network access. v4.0 Requirement 8.4 extends MFA to all non-console administrative access to the CDE and all remote access by all personnel, including third-party and vendor personnel. Organizations must also implement MFA for all access to web-based payment pages.

New E-Commerce and Anti-Phishing Requirements

v4.0 introduces specific new requirements for organizations with e-commerce payment pages: Requirement 6.4 mandates that all scripts loaded and executed in the consumer’s browser from payment pages be inventoried and justified, and that a method is in place to confirm integrity of those scripts (addressing Magecart-style skimming attacks). Requirement 5.4.1 requires processes to detect and protect personnel against phishing attacks.

Who Must Comply

PCI DSS applies to any entity involved in payment card processing that stores, processes, or transmits cardholder data (CHD) or sensitive authentication data (SAD). This includes merchants of all sizes, payment processors, acquirers, issuers, and service providers. Merchant levels (1 through 4) and service provider levels (1 and 2) are determined by annual transaction volume and determine whether a QSA audit or an SAQ is required. Merchant Level 1 (over 6 million transactions annually) must undergo an annual QSA audit. Smaller merchants may self-assess using the appropriate SAQ form.

2. The 12 PCI DSS Requirements — What Each Actually Demands

PCI DSS v4.0 organizes its 259 requirements across 12 high-level requirements grouped into six control objectives. Understanding what each requirement actually demands in practice is essential for scoping your compliance program accurately.

Requirements 1–2: Network Security Controls

Requirement 1 mandates documented and maintained network security controls — firewalls, routers, and equivalent devices — that restrict inbound and outbound traffic to what is required for the cardholder data environment. CDE segmentation from other network segments is required. Requirement 2 prohibits the use of vendor-supplied default passwords and security settings on all system components. All systems must be hardened according to an industry-accepted hardening standard (CIS Benchmarks or equivalent), and all non-essential services, protocols, and ports must be disabled.

Requirements 3–4: Protect Stored Account Data

Requirement 3 governs stored cardholder data: Primary Account Numbers (PANs) must be rendered unreadable at rest using strong cryptography (AES-256 is standard), truncation, tokenisation, or one-way hashing. Sensitive authentication data — including CVV2/CVC2 values, full magnetic stripe data, and PINs — must never be stored after authorisation, regardless of encryption state. Requirement 4 protects cardholder data in transit: TLS 1.2 or higher is required for all transmissions over open, public networks. Weak cryptographic protocols (SSL, TLS 1.0, TLS 1.1) are prohibited.

Requirements 5–6: Protect Systems from Malicious Software

Requirement 5 requires anti-malware solutions on all applicable system components, with automatic updates and regular scans. Endpoint Detection and Response (EDR) capabilities satisfy this requirement for most environments. Requirement 6 mandates a secure software development lifecycle (SDLC) for all in-house developed payment applications. Public-facing web applications must be protected by a Web Application Firewall (WAF) reviewed and updated at least annually, and must undergo annual application vulnerability assessments or penetration testing. The new Requirement 6.4 script inventory for e-commerce pages applies here.

Requirements 7–9: Restrict Access to System Components

Requirement 7 mandates role-based access control (RBAC) for all CDE system components: access is allowed only to the minimum necessary for each role. Requirement 8 governs user identification and authentication: unique IDs for every individual, strong passwords (at least 12 characters under v4.0), account lockout after 10 failed attempts, and MFA for all applicable access paths. Requirement 9 covers physical access controls: visitor logs, badge access to server rooms and network equipment, protection of point-of-interaction (POI) devices against tampering, and procedures for device inspection at least once every three months.

Requirements 10–11: Log and Monitor All Access

Requirement 10 requires audit logs for all CDE system components, with automated log review and SIEM capabilities that generate alerts for suspicious activity. Logs must be retained for at least 12 months, with three months immediately available for analysis. Requirement 11 mandates quarterly internal vulnerability scans, quarterly external scans by an Approved Scanning Vendor (ASV), and annual penetration testing covering both network and application layers. Penetration testing scope must align with actual CDE boundaries, and results must be retained as evidence.

Requirement 12: Support Information Security with Organisational Policies

Requirement 12 is the governance requirement: comprehensive security policies reviewed at least annually, security awareness training for all personnel at hire and annually thereafter, a documented incident response plan tested at least annually, and a third-party risk management program requiring annual validation of all service providers that access the CDE. Under v4.0, Requirement 12.3 mandates targeted risk analyses for all controls where frequency is determined by the organization rather than prescribed by the Standard.

3. Defining Your Cardholder Data Environment (CDE)

The most critical step in any PCI DSS compliance program is accurately scoping the cardholder data environment. An overly broad scope creates unnecessary compliance cost; an overly narrow scope creates compliance risk. PCI DSS v4.0 defines the CDE as all system components that store, process, or transmit cardholder data or sensitive authentication data, plus the network on which they reside. Two additional scope categories are critical:

Connected-To and Security-Impacting Systems

Systems that are connected to CDE components are considered in scope even if they do not directly handle cardholder data — because a compromise of those systems could lead to compromise of the CDE. Systems that provide security services to the CDE (authentication servers, log aggregation systems, monitoring tools) are also in scope regardless of whether cardholder data flows through them. Employee workstations that access the CDE via web browsers, administrative consoles, or remote desktop sessions are frequently overlooked and represent a common scoping error.

Network Segmentation as the Primary Scope-Reduction Tool

Effective network segmentation is the most powerful tool for reducing PCI DSS scope. When CDE systems are isolated on a dedicated network segment with strictly controlled access, systems on other segments that have no connectivity to the CDE are out of scope. Segmentation must be validated as part of annual penetration testing and scope review. Flat networks where all systems can communicate represent maximum scope and maximum compliance burden.

Tokenisation and P2PE as CHD Elimination Strategies

Tokenisation replaces cardholder data with a non-sensitive surrogate value (a token) that is stored by the merchant instead of the PAN. When implemented using a validated third-party tokenisation solution, merchants may substantially reduce CDE scope because no actual cardholder data passes through or is stored in their environment. Similarly, validated Point-to-Point Encryption (P2PE) solutions encrypt cardholder data at the point of interaction device and decrypt it only within the service provider’s secure environment — reducing merchant scope to the validated P2PE hardware only.

Common Scoping Mistakes

• Forgetting employee workstations that access the CDE through browser-based management consoles or remote desktop
• Overlooking cloud-hosted infrastructure components that store, process, or transmit CHD
• Missing third-party integrations and service providers that access CDE systems remotely
• Failing to include segmentation devices (firewalls, routers) that enforce CDE boundaries
• Not performing annual scope review as required under v4.0 Requirement 12.5.2

4. The 10 Most Common PCI DSS Compliance Gaps

• MFA not enforced for all non-console CDE access — v4.0 expanded MFA scope significantly; many organizations have MFA on remote VPN but not on web-based administrative consoles or jump-host access to CDE systems.
• No quarterly internal vulnerability scans or ASV scan evidence — organizations often perform one scan per year and lack documentation of all four quarterly scan cycles with remediation evidence.
• Default passwords not changed on network devices — Requirement 2.1 is one of the oldest requirements in PCI DSS and still generates findings on legacy network hardware and newly deployed IoT/POI devices.
• Log monitoring is manual and infrequent rather than automated — Requirement 10.4.1 requires automated mechanisms that generate alerts; manual daily log review without automated alerting is generally insufficient.
• CDE network diagram outdated or missing — Requirement 1.2.4 requires a current, accurate diagram of all CDE connections, including wireless networks and cloud components. Stale diagrams are a top audit finding.
• No documented key management procedures — Requirement 3.7 mandates documented procedures for cryptographic key generation, distribution, storage, access, retirement, and destruction. Most organizations lack a complete key management lifecycle document.
• WAF not deployed or not actively managed for public-facing applications — Requirement 6.4 mandates a WAF for all public-facing web applications. Many organizations deploy a WAF but operate it in detection-only mode or fail to maintain updated rule sets.
• Penetration test scope doesn’t match actual CDE boundaries — Tests scoped too narrowly miss CDE-adjacent systems; tests not aligned with the actual network architecture provide insufficient evidence of segmentation effectiveness.
• Third-party service providers not validated for PCI DSS compliance annually — Requirement 12.8 requires a list of all TSPs with access to the CDE, documented acceptance of responsibility for applicable PCI DSS requirements, and annual validation of each TSP’s compliance status.
• Security awareness training records incomplete — Requirement 12.6 requires training at hire and at least annually, with records of completion. Organizations frequently lack records for all personnel or cannot demonstrate training content was updated to reflect current threats.

5. QSA Audit vs Self-Assessment Questionnaire (SAQ)

The appropriate compliance validation method depends on your merchant or service provider level and how you accept payments. Choosing the wrong SAQ type is one of the most consequential mistakes a smaller merchant can make — it can result in an incomplete assessment that leaves real vulnerabilities unaddressed.

When a QSA Is Required

Merchant Level 1 (over 6 million Visa or Mastercard transactions per year, or any merchant that has experienced a data breach) must undergo an annual Report on Compliance (RoC) completed by a PCI SSC Qualified Security Assessor. Service Provider Level 1 (over 300,000 transactions per year) also requires an annual QSA RoC. All other service providers are Level 2 and may self-assess using a designated service provider SAQ.

Choosing the Right SAQ

The eight SAQ types differ substantially in scope and number of requirements. Key distinctions:

• SAQ A: Card-not-present merchants that have fully outsourced all payment processing to PCI DSS-compliant service providers. No cardholder data passes through the merchant’s systems or environment.
• SAQ A-EP: E-commerce merchants that have outsourced payment processing but whose website affects the security of the payment transaction. Applies when third-party scripts load on the payment page.
• SAQ B: Merchants using only imprint machines or stand-alone, dial-out terminals with no electronic storage of cardholder data.
• SAQ B-IP: Merchants using standalone, IP-connected POI terminals that are PTS-approved and do not store CHD electronically.
• SAQ C: Merchants with payment applications connected to the internet but no electronic CHD storage.
• SAQ D: All merchants not eligible for SAQ A through C-VT, and all service providers eligible to complete an SAQ. The most extensive SAQ, covering all 12 PCI DSS requirement areas.

What QSAs Look For

QSA assessments evaluate operating effectiveness, not just policy existence. A firewall policy document without evidence of quarterly rule review will not satisfy Requirement 1. Access control policies without evidence of quarterly user access reviews will fail Requirement 7. QSAs request samples of logs, access review records, vulnerability scan reports, penetration test results, and training completion records — all with dates and responsible parties. The most common audit failure is the absence of dated evidence that controls were operating continuously throughout the assessment period, not just at the time of the audit.

RoC vs AoC

The Report on Compliance (RoC) is the full detailed assessment document produced by the QSA, typically 150–400 pages. The Attestation of Compliance (AoC) is a shorter summary document signed by both the QSA and the assessed organization’s executive team, attesting that the RoC findings reflect the organization’s compliance status. Acquirers and payment brands typically require the AoC; the full RoC may be requested only in the event of a suspected incident or escalated review.

6. PCI DSS and Adjacent Frameworks

Organizations subject to PCI DSS frequently maintain compliance programs under multiple frameworks simultaneously. Understanding the overlap and the differences reduces unnecessary duplication of effort.

PCI DSS and SOC 2

PCI DSS and SOC 2 Type II are separate certifications with separate auditors and separate assessment processes. However, they share approximately 40% control overlap across access management, change management, monitoring, and incident response. A well-structured control environment can generate evidence that satisfies requirements in both frameworks simultaneously. Mapping PCI DSS requirements to SOC 2 Trust Services Criteria before either audit is completed is a practical first step for organizations pursuing both.

PCI DSS and ISO 27001

ISO 27001 provides an information security management system (ISMS) framework and management system certification; PCI DSS specifies the technical controls required for payment card security. ISO 27001 Annex A controls significantly overlap with PCI DSS Requirements 5 through 12. Organizations with ISO 27001 certification have typically already implemented strong risk management, access control, and incident management programs that satisfy the governance and process aspects of PCI DSS. The PCI DSS CDE-specific technical requirements (network segmentation, CHD encryption, ASV scanning) require additional work beyond ISO 27001.

PCI DSS and NIST CSF

The NIST Cybersecurity Framework can serve as a risk management overlay for PCI DSS implementation, helping organizations prioritize control investments across the Identify, Protect, Detect, Respond, and Recover functions. NIST CSF does not itself confer PCI DSS compliance but provides a useful maturity model for organizations building or maturing their broader security program alongside their PCI DSS compliance effort.

PCI DSS and NIS2

Payment processors and financial infrastructure operators in the European Union may face simultaneous obligations under both PCI DSS and NIS2. Key differences: NIS2 requires incident notification within 24 hours (early warning) and 72 hours (detailed notification); PCI DSS Requirement 12.10.4 requires notification of the acquiring bank and relevant payment brands “immediately” upon confirmation of a breach (typically interpreted as within 24 hours). Organizations must maintain separate notification procedures for each regulatory requirement.

Tabletop Exercises as PCI DSS Evidence

Incident response tabletop exercises satisfy PCI DSS Requirement 12.10.2, which mandates annual testing of the incident response plan. Documented tabletop exercises that simulate payment card data breach scenarios — covering notification decision-making, forensic investigation initiation, and acquirer communication — generate direct audit evidence. CDE boundary and segmentation assumptions can also be validated through tabletop scenarios that test whether response teams correctly identify CDE scope during a live incident.

7. Assessing Your PCI DSS Readiness Before Engaging a QSA

Engaging a QSA without first conducting a structured internal readiness assessment is expensive. QSA findings that require remediation reset the assessment timeline and add significant cost. A structured pre-assessment typically takes 2–4 weeks and identifies the majority of critical gaps before the formal assessment begins.

Why a Self-Assessment First Saves Money

A typical PCI DSS readiness assessment from a consulting firm costs $5,000–$15,000. A QSA finding a critical gap mid-assessment — requiring remediation, re-testing, and assessment extension — can add $20,000–$50,000 in additional fees and delay your AoC by months. Organizations that complete a structured internal pre-assessment routinely reduce QSA engagement time by 20–40% by entering the formal assessment with documented controls and organized evidence packages.

The 5 Domains to Assess First

• Network: CDE boundary definition, network diagrams, segmentation validation, firewall rule review, and wireless network controls.
• Data Protection: PAN encryption at rest, TLS 1.2+ in transit, CVV2/SAD non-storage verification, key management procedures.
• Access Control: RBAC documentation, unique user IDs, MFA coverage for all applicable access paths, access review records, privileged account management.
• Monitoring: SIEM or log aggregation coverage of all CDE components, automated alerting, log retention (12 months), quarterly vulnerability scans, annual penetration test scope alignment.
• Policy and Governance: Annual policy review evidence, security awareness training completion records, third-party service provider list and validation status, incident response plan and annual test evidence.

Using the Free PCI DSS Readiness Assessment Tool

The CyberICS Solutions free PCI DSS readiness assessment tool walks through 25 structured questions across all five domains above. It generates an instant domain-level readiness score, identifies critical and major gaps, and produces a prioritized remediation checklist. No registration is required for basic results. The assessment takes approximately 8–10 minutes to complete and produces a report you can use to brief your QSA before engagement — reducing assessment scope and fees.

Interpreting Your Readiness Score

• 85–100%: Assessment-ready. Minor documentation gaps only. Recommend scheduling QSA engagement.
• 70–84%: Close to ready. 2–4 specific gaps requiring remediation before QSA engagement.
• 55–69%: Moderate gaps. 4–8 week remediation effort before assessment.
• Below 55%: Significant gaps. Structured remediation program required; 2–6 months before QSA engagement recommended.

Frequently Asked Questions

Next Steps & Related Resources

Once you have your PCI DSS readiness baseline, the most effective next step is running a tabletop exercise that simulates a cardholder data breach — covering forensic investigation initiation, QSA notification, acquiring bank communication, and public disclosure decisions. The CyberICS Solutions platform includes PCI DSS-mapped scenarios that practice exactly these notification and escalation workflows in a safe exercise environment.