PCI DSS 4.0
Practical Guide for 2026

§1 PCI DSS 4.0 vs 3.2.1 — Why Migration Matters

PCI DSS 4.0 was published in March 2022 by the PCI Security Standards Council (PCI SSC). v3.2.1 was retired on March 31, 2025. As of mid-2026, every merchant and service provider that stores, processes, or transmits cardholder data is expected to validate against v4.0 — the Defined Approach, the Customized Approach, or a hybrid of the two.

The most important migration dates sit on a single line: v3.2.1 was retired on March 31, 2025. From that date forward, every new attestation of compliance is required to be against v4.0. Brands and acquirers no longer accept v3.2.1 Reports on Compliance (ROC) or v3.2.1 Self-Assessment Questionnaires (SAQ). ComplianceStack flags v3.2.1 attestations as a top-priority remediation gap for any merchant discovered still on the v3.2.1 baseline.

The largest structural change in v4.0 is the new Customized Approach. Under v3.2.1, an entity that could not meet a requirement verbatim had two options: implement the requirement's Defined Approach in full, or document a Compensating Control that achieved the requirement's stated intent via alternative means. v4.0 retains the Defined Approach but replaces Compensating Controls with the Customized Approach — a documented, ongoing risk analysis showing how the alternative control achieves the requirement's Customized Approach Objective. ComplianceStack's PCI-DSS risk calculator captures Customized Approach documentation as a first-class deliverable alongside the standard Defined Approach attestation.

Three future-dated v4.0 controls became mandatory on March 31, 2025 and remain in force mid-2026: Req 8.4.2 (multi-factor authentication for all access into the cardholder data environment, not just admin and remote), Req 11.6.1 (change- and tamper-detection on payment pages), and Req 12.5.1 (targeted risk analysis on a 12-month cadence for any control using the Customized Approach). ComplianceStack notes that these three controls are the highest-frequency gap items in v4.0 assessments and the most-cited deficiencies in brand-level compliance reviews.

The PCI SSC has additionally issued v4.0.1 errata clarifying wording on authentication, e-commerce skimming (the Req 6.4.3 payment-page script control), and targeted risk-analysis scope. ComplianceStack tracks v4.0 and v4.0.1 as a single effective baseline for merchant and service-provider attestation.

§2 The 6 Goals and 12 Requirements

PCI DSS v4.0 organizes the standard into six goals covering twelve requirements (Req 1 through Req 12). The organization is unchanged from v3.2.1 — what changed is the expanded sub-requirements under each Req, particularly under Req 6 (secure development), Req 8 (authentication), Req 10 (logging), Req 11 (testing), and Req 12 (policy).

Goal 1 — Build and Maintain a Secure Network & Systems (Req 1–2)

• Req 1: Install and Maintain Network Security Controls. Req 1.1 processes and rules for firewall and router configuration; Req 1.2 network security controls between trusted and untrusted networks; Req 1.3 restrictions on inbound traffic to the CDE; Req 1.4 restrictions on outbound traffic from the CDE; Req 1.5 any wireless networks segregated from the CDE.
• Req 2: Apply Secure Configurations to All System Components. Req 2.1 configuration standards for all system components addressing known vulnerabilities; Req 2.2 vendor-supplied defaults removed (default passwords, default accounts, default SNMP community strings); Req 2.3 wireless environment defaults changed.

Goal 2 — Protect Account Data (Req 3–4)

• Req 3: Protect Stored Account Data. Req 3.1 account-data storage policies and procedures; Req 3.2 sensitive authentication data (SAD) not stored after authorization; Req 3.3 PAN masked when displayed; Req 3.4 PAN unreadable wherever stored (tokenization, truncation, hashing, strong cryptography); Req 3.5 primary account number (PAN) is rendered unreadable — codified headline control.
• Req 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open Networks. Req 4.1 cryptographic transmission controls; Req 4.2 PAN unreadable during transmission; Req 4.2.1 strong cryptography for all cardholder-data transmission over open networks, including wireless — mandatory TLS 1.2+ with no SSL/TLS 1.0/1.1 anywhere in the CDE leg.

Goal 3 — Maintain a Vulnerability Management Program (Req 5–6)

• Req 5: Protect All Systems from Malicious Software. Req 5.1 anti-malware on all systems commonly affected by malware (and systems providing CDE services); Req 5.2 anti-malware periodically updated; Req 5.3 anti-malware actively running; Req 5.4 anti-malware not disabled by users (and limited admin disable authority documented).
• Req 6: Develop and Maintain Secure Systems and Software. Req 6.1 vulnerability identification and ranking; Req 6.2 vendor security advisories addressed; Req 6.3 secure software development for bespoke and custom software; Req 6.4 public-facing web applications protected (WAF or code review); Req 6.4.1/6.4.2/6.4.3 payment-page-script management — the inventory, integrity, and PCI-DSS-compliant justification controls that together form the central anti-skimming requirement of v4.0.

Goal 4 — Implement Strong Access Control Measures (Req 7–8)

• Req 7: Restrict Access to System Components and Cardholder Data by Business Need-to-Know. Req 7.1 access-restriction policies; Req 7.2 access based on job classification and function (least privilege); Req 7.3 default-deny access (no access unless explicitly granted).
• Req 8: Identify Users and Authenticate Access to System Components. Req 8.1 unique user IDs; Req 8.2 strong authentication factors; Req 8.3 multi-factor authentication for all non-console admin access and all remote access by personnel and third parties; Req 8.4 MFA required for ALL access into the CDE — the headline v4.0 expansion from the v3.2.1 admin/remote-only scope; Req 8.5 service-provider identification and authentication; Req 8.6 use of authentication credentials, account lockout, session timeout.

Goal 5 — Regularly Monitor and Test Networks (Req 9–10)

• Req 9: Restrict Physical Access to Cardholder Data. Req 9.1 physical-access controls (facility entry controls, video, access logs); Req 9.2 physically secure media; Req 9.3 media distribution, storage, and destruction; Req 9.4 device inventory and protection; Req 9.5 point-of-interaction (POI) device protection against tampering and substitution.
• Req 10: Log and Monitor All Access to System Components and Cardholder Data. Req 10.1 audit trails linking every access to a user; Req 10.2 audit-trail contents (user, event type, date/time, success/failure, origination, affected component); Req 10.2.1.5 every change to authentication and identification mechanisms captured in audit logs — new in v4.0; Req 10.3 audit-trail protection; Req 10.4 audit-log review at least daily for security events, weekly for all other events; Req 10.5 audit-log history retention at least 12 months with the most recent 3 months immediately available; Req 10.6 time-synchronization for all systems; Req 10.7 service-provider log delivery and integrity.

Goal 6 — Maintain an Information Security Policy (Req 11–12)

• Req 11: Test Security of Systems and Networks Regularly. Req 11.1 authorized wireless-access-point identification and response; Req 11.2 internal vulnerability scans quarterly and after significant change; Req 11.3 external vulnerability scans quarterly by an ASV; Req 11.4 intrusion detection / intrusion prevention at perimeter and critical CDE points; Req 11.5 change-detection on payment pages (file-integrity monitoring); Req 11.6.1 change- and tamper-detection mechanism deployed on payment pages — the v4.0 anti-skimming equivalent to a WAF for browser-side attacks, typically header-content, script-hash, or external-page-monitoring based — mandatory since March 31, 2025.
• Req 12: Support Information Security with Organizational Policies and Programs. Req 12.1 information-security policy published, maintained, and disseminated; Req 12.2 acceptable-use policies for end-user technologies; Req 12.3 cryptographic controls policy; Req 12.4 service-provider management policy; Req 12.5.1 targeted risk analysis on a 12-month cadence for each requirement that allows the Customized Approach — mandatory since March 31, 2025; Req 12.6 security-awareness education; Req 12.7 personnel screening; Req 12.8 service-provider status; Req 12.9 service-provider acknowledgment; Req 12.10 incident-response plan in the event of unauthorized access to cardholder data.

§3 Deep Dives — the v4.0-Expanded Controls

Seven Req items in v4.0 represent the substantive v4.0-only scope expansion — controls that did not exist in v3.2.1, were scope-limited in v3.2.1, or were best-practice-deprecated controls that v4.0 elevates to mandatory. ComplianceStack treats these seven as the PCI-DSS risk calculator's "v4.0 control group" for prioritized gap analysis.

Req 3.5.1 — PAN unreadable wherever stored

The single most-cited storage control across every PCI version. v4.0 codifies that the PAN must be rendered unreadable wherever it is stored — via one-way hashing, truncation, index tokens, or strong cryptography. The control pairs directly with Req 3.2 (no SAD stored after authorization) and Req 3.3 (display masking). ComplianceStack tracks which storage locations in the merchant environment still hold clear-text PAN (most commonly: analytics exports, BI tools, data lake copies, development fixtures) and maps each to the appropriate unreadable method.

Req 4.2.1 — Strong cryptography for cardholder-data transmission

The transmission-security headline. Effective with v4.0, cardholder data transmitted over open (untrusted, typically internet-exposed) networks must be encrypted with strong cryptography — operated to render the data unreadable, undecipherable, and resistant to cryptanalytic attack. TLS 1.2 with strong cipher suites (TLS 1.3 preferred) is the operational baseline. v3.2.1 permitted broader guidance; v4.0 closes the loophole on legacy TLS 1.0 and 1.1 for any CDE leg.

Req 6.4.3 — PCI DSS-compliant payment-page scripts (new in v4.0)

The central anti-skimming control of v4.0. Req 6.4.3 requires: (a) an inventory of every script loaded into a payment page, with a written justification for why each script is necessary; (b) a method to confirm the integrity of each script (subresource integrity hashes, real-time script-content monitoring, or equivalent); (c) a method to confirm each script is authorized. The control exists specifically to address Magecart-style e-commerce skimming attacks that compromise the payment page without compromising the server. Most in-house payment pages load dozens of third-party scripts (analytics, A/B testing, chat, tag managers, fraud scoring, ad pixels); ComplianceStack's pay-page script inventory is the operationally expensive deliverable that organizations consistently underestimate.

Req 8.4.2 — MFA for all access into the CDE

The headline v4.0 expansion. v3.2.1 limited MFA to "all non-console administrative access" and "all remote network access" — the practical effect was MFA for IT administrators reaching the CDE from outside. v4.0 sweeps in EVERY form of access into the CDE, including on-site user workstations inside the CDE (cashiers, pharmacy workstations, healthcare-billing workstations, payment kiosks), service-desk technicians, and any third-party user. ComplianceStack's MFA gap analysis surveys every distinct user category that touches CDE-bearing systems, not just the IT admin perimeter.

Req 10.2.1.5 — Authentication-mechanism audit log (new in v4.0)

v3.2.1 was silent on the question of how to log administrative changes to the authentication system itself. v4.0 adds Req 10.2.1.5 to require that every change to authentication and identification mechanisms — new user creation, privilege elevation, credential resets, MFA-factor enrollment, credential revocation, group membership changes — be captured in the audit trail. ComplianceStack's Req 10.2.1.5 deliverable is a SIEM-mapped audit-trail confirming that each authentication-event class is logged with the time-synchronized source-of-truth event.

Req 11.6.1 — Change- and tamper-detection on payment pages

The Req 11 counterpart to Req 6.4.3. Req 11.6.1 requires a mechanism that detects unauthorized changes to payment-page HTTP headers and payment-page contents, and alerts on any change. Common implementations use browser-side scripts that fingerprint the page from inside the customer browser and report back to a server-side anomaly engine, or out-of-band HTTP fetchers that compare a known-good baseline against the live page. ComplianceStack's Req 11.6.1 deliverable pairs with the Req 6.4.3 script-inventory to form a defense-in-depth anti-skimming posture.

Req 12.5.1 — Targeted risk analysis (12-month cadence)

The Customized Approach's annual bookend. Any organization that implements a control via the Customized Approach must perform a targeted risk analysis for that control on at least a 12-month cadence documenting the threat, the implemented control, and the residual risk. The analysis must be re-performed annually and when there are significant changes to the threat or the control environment. ComplianceStack packages this as a recurring deliverable that fits inside the broader Req 12 organizational policy program.

§4 Merchant Levels (1–4) and Service Provider Levels (1–2)

PCI SSC uses merchant / service-provider tiers to gate the evidence required. The Visa tiering is the de-facto standard adopted in parallel by Mastercard, American Express, and Discover.

Merchant Levels

• Merchant Level 1 — >6 million Visa transactions per year OR any merchant that has suffered a cardholder-data breach (Visa retains discretion to elevate). Validation: annual Report on Compliance (ROC) by a PCI-qualified Security Assessor (QSA). This is the most rigorous tier.
• Merchant Level 2 — 1 million to 6 million Visa transactions per year. Validation: annual Self-Assessment Questionnaire (SAQ) plus quarterly network scans by an Approved Scanning Vendor (ASV); the SAQ is reviewed and signed by an officer of the merchant.
• Merchant Level 3 — 20,000 to 1 million Visa e-commerce transactions per year; OR up to 1 million total transactions where ALL transactions are e-commerce. Validation: annual SAQ plus quarterly ASV scans.
• Merchant Level 4 — fewer than 20,000 e-commerce transactions per year; OR up to 1 million total transactions through all channels except e-commerce. Validation: annual SAQ. SAQ selection depends on integration: SAQ-A, SAQ-A-EP, SAQ-B, SAQ-B-IP, SAQ-C, SAQ-C-VT, SAQ-D-Merchant, or SAQ-P2PE-HW.

Service Provider Levels

• Service Provider Level 1 — stores, processes, or transmits more than 300,000 Visa transactions per year. Validation: annual ROC by a QSA.
• Service Provider Level 2 — any other service provider handling Visa transactions. Validation: annual SAQ-D-Service Provider.

SAQ Selection Map

ComplianceStack recommends treating SAQ selection as a function of three variables: commerce model (e-commerce vs card-present), data handling (does the merchant store, process, or transmit cardholder data or only redirect to a PCI-compliant processor), and integration type (P2PE hardware, virtual terminal, payment iframe, fully outsourced). The eight SAQ types are: SAQ-A (e-commerce fully outsourced to PCI-DSS-compliant processor — lightest scope); SAQ-A-EP (e-commerce where merchant's site captures payment data but data is not stored, processed, or transmitted); SAQ-B (standalone dial-out terminal or imprint machine only); SAQ-B-IP (standalone IP-connected terminal); SAQ-C (payment application systems connected to the Internet — no e-commerce); SAQ-C-VT (virtual-terminal-only merchants); SAQ-D-Merchant (all other merchants — effectively Req 1-12); and SAQ-D-Service Provider (for service providers). SAQ-P2PE-HW is the P2PE-hardware-only variant for merchants using a validated P2PE solution.

§5 Deadlines & 2026 Enforcement Posture

Three dates govern merchant and service-provider v4.0 enforcement.

• March 31, 2024 — v4.0 future-dated requirements available alongside v3.2.1. During the year-long transition window organizations could attest against either v3.2.1 or v4.0.
• March 31, 2025 — v3.2.1 retired; v4.0 became the only acceptable attestation baseline. All three future-dated requirements (Req 8.4.2, Req 11.6.1, Req 12.5.1) became mandatory simultaneously.
• v4.0.1 errata — ongoing PCI SSC clarifications. The PCI SSC has issued v4.0.1 errata addressing wording on authentication, e-commerce skimming, and targeted risk-analysis scope. ComplianceStack monitors errata releases quarterly.

Acquirers report brand-level enforcement to Visa, Mastercard, American Express, and Discover. Mid-2026 enforcement posture reflects a maturing v4.0 audit pool — v4.0-only deficiencies (Req 6.4.3 script inventory, Req 8.4.2 MFA scope, Req 10.2.1.5 authentication-event audit log, Req 11.6.1 page tamper detection, Req 12.5.1 targeted risk analysis) are the most-cited gaps. ComplianceStack notes that acquirers are increasingly unwilling to accept Customized Approach documentation without a defensible targeted risk analysis under Req 12.5.1.

§6 Penalties — Card-Brand Fines, Forensic, & Termination

PCI DSS non-compliance is enforced by the four card brands in parallel through monthly fines, forensic investigation costs, mandatory re-assessments, and — at the top of the pyramid — revocation of card acceptance rights. ComplianceStack tracks the cumulative brand-level fine exposure as a function of (1) the time-window of non-compliance, (2) whether the trigger is a routine audit gap or a breach, and (3) the merchant's level and integration scope.

Brand-Level Monthly Fines

Visa's Merchant Compliance Charge (MCC) program is the operative template. Mastercard, American Express, and Discover run parallel regimes with similar tiered escalation. ComplianceStack provides the per-brand matrix below:

Fines are per brand, per month, until compliant. A merchant carrying Visa + Mastercard + Amex + Discover and remaining non-compliant for six months accumulates brand-tier-3 fines across all four brands simultaneously. ComplianceStack treats brand-quad-fine exposure at the maximum Tier 4 as the contingency ceiling of any PCI-DSS remediation budget.

Forensic Investigation Costs

A suspected or confirmed cardholder-data breach triggers a mandatory PCI Forensic Investigator (PFI) engagement. PFI engagements typically cost $20,000 to $100,000+ depending on environment scope, transaction volume, and the number of systems that must be imaged and analyzed. The PFI emission a final report (per PCI SSC PFI reporting requirements) that is filed with the affected brands and becomes part of the merchant's permanent compliance record. ComplianceStack recommends budgeting $100K as a conservative default contingency for any PCI-DSS gap analysis where there is breach exposure.

Level 1 Onsite Re-Assessment

Following a confirmed breach or persistent non-compliance, the brand may require a Level 1 Onsite Re-Assessment by a QSA, billed separately and typically $40,000 to $75,000+ depending on environment scope. The re-assessment produces a fresh ROC that the merchant must remediate to closure. Multiple re-assessments can be required in sequence if the initial ROC identifies material gaps.

Termination of Card-Acceptance Rights

At the top of the pyramid sits the termination right: any brand may revoke the merchant's right to accept that brand's cards entirely. Termination is invoked for prolonged non-compliance, for breaches where remediation evidence is inadequate, or for service providers whose customer merchants suffer breaches attributable to the service provider's environment. ComplianceStack treats termination as the headline contingency — card-acceptance termination is an existential event for any card-present retail business.

§7 Pair this guide with the ComplianceStack PCI-DSS tools

Four ComplianceStack tools pair directly with this pillar guide. The free PCI compliance pulse is the lightweight diagnostic (under 2 minutes); the multi-framework free assessment covers PCI-DSS alongside HIPAA / SOX / GDPR / OSHA / SEC; the deep PCI-level assessment produces an SAQ map; and ComplianceStack pricing covers audit-ready deliverable upgrades.

§7a Framework Crosswalk — PCI-DSS 4.0 Requirements ↔ NIST SP 800-53 r5 ↔ HIPAA Security Rule §164.308–312 ↔ SOC 2 CC1–CC9

ComplianceStack pairs every PCI-DSS 4.0 Requirement (Req 1–12) with its NIST SP 800-53 Rev 5 control-family counterpart, its HIPAA Security Rule safeguard (where the merchant or service provider touches PHI or operates in healthcare-adjacent scope), and its SOC 2 Trust Services Criterion. Pair this crosswalk with the two outbound pillar references below so a Req 8.4.2 MFA cell, a Req 10 audit log, and a Req 11.6.1 payment-page tamper-detection cell all resolve to a defensible multi-framework evidence row from one table.

• PCI DSS v4.0 (PCI SSC, March 2022). Payment Card Industry Data Security Standard v4.0 — replaces v3.2.1 after 2024-03-31; future-dated requirements (Req 8.4.2 MFA, Req 11.6.1 tamper detection, Req 12.5.1 targeted risk analysis) active 2025-03-31. Source: pcisecuritystandards.org/document_library.
• NIST SP 800-53 Rev 5. Security and Privacy Controls for Information Systems and Organizations (NIST, September 2020). Source: csrc.nist.gov — SP 800-53 Rev 5 final.
• 45 CFR §164.308–312. HIPAA Security Rule Administrative, Physical, and Technical Safeguards (HHS/OCR) — applicable to PCI-DSS Reqs 3, 8, 9, 10, 12 with healthcare / PHI adjacency.
• AICPA Trust Services Criteria CC1–CC9 (2022 revision). Common Criteria for SOC 2 attestation, effective for reports dated December 15, 2022 or later — the cross-mapping companion above the criteria column. Source: aicpa-cima.com — Trust Services Criteria.

Pair this crosswalk with the two other pillar references below. The HIPAA safeguard cells apply only to the Reqs flagged for healthcare exposure (Reqs 3, 8, 9, 10, 12 — encryption / authentication / facility / audit / policy); other Reqs are merchant-environment-agnostic and source only from PCI-DSS, NIST SP 800-53 r5, and the AICPA Trust Services Criteria.

§8 Frequently Asked Questions