PCI DSS 4.0 Compliance: What Changed and How to Prepare
PCI DSS 4.0 is the most significant update to the Payment Card Industry Data Security Standard in over a decade. It introduces a customized approach to compliance, strengthens authentication requirements, expands encryption mandates, and requires targeted risk analysis. If you process, store, or transmit cardholder data, here is what you need to know.
What Is PCI DSS 4.0?
PCI DSS (Payment Card Industry Data Security Standard) is a set of security requirements for any organization that handles payment card data. Version 4.0, released in March 2022 and enforced starting March 2025, replaces version 3.2.1 with modernized requirements that reflect current threat landscapes, cloud-native architectures, and continuous security monitoring.
The standard is organized into 12 requirements across six goals: build and maintain a secure network, protect cardholder data, maintain a vulnerability management program, implement strong access control, regularly monitor and test networks, and maintain an information security policy.
Key Changes in PCI DSS 4.0
Customized Approach
Organizations can now design their own controls that meet the intent of each requirement, rather than following prescriptive controls. Requires documented risk analysis and validation.
Targeted Risk Analysis
Several requirements now mandate targeted risk analysis to determine frequency of activities (scanning, log review, etc.) based on the organization's specific risk profile.
Enhanced Authentication
MFA required for all access to the cardholder data environment (not just remote access). Password length increased to 12 characters minimum. Phishing-resistant MFA recommended.
Expanded Encryption
Encryption of cardholder data on trusted internal networks now required (not just public networks). Disk-level encryption alone no longer meets the requirement.
Continuous Monitoring
Automated mechanisms to detect and alert on security-relevant events in real time. Periodic manual reviews are no longer sufficient for many requirements.
Web Application Security
WAF or equivalent automated technical solution required for public-facing web applications. Annual manual reviews of web apps are no longer an alternative.
Enforcement Timeline
| Date | Milestone | Impact |
|---|---|---|
| March 2022 | PCI DSS 4.0 published | Organizations can begin adopting v4.0 |
| March 2024 | PCI DSS 3.2.1 retired | All assessments must use v4.0 |
| March 2025 | Future-dated requirements enforced | 64 new requirements become mandatory |
| Ongoing | Annual assessments | Continuous compliance validation required |
PCI DSS 4.0 Checklist for Cloud-Native
Network Security (Req 1–2)
Data Protection (Req 3–4)
Vulnerability Management (Req 5–6)
Access Control & Monitoring (Req 7–12)
Scoping: The Decision That Determines Everything Else
Before you evaluate a single control, you must define your cardholder data environment (CDE) — every system component that stores, processes, or transmits cardholder data, plus anything connected to or capable of affecting its security. Scope determines cost more than any other factor: every in-scope system needs hardening, logging, scanning, access reviews, and assessment evidence. PCI DSS 4.0 raises the stakes by formally requiring scope confirmation at least annually (Requirement 12.5.2), and every six months for service providers.
The most effective compliance strategy is therefore scope reduction, and the modern toolbox is well established:
- Outsource card handling entirely: hosted payment pages and iframes from processors like Stripe or Adyen can qualify a merchant for the short SAQ A questionnaire instead of a 300+ control assessment — though v4.0 notably added script integrity and anti-skimming requirements (6.4.3, 11.6.1) that apply even to these lightweight setups.
- Tokenization: replace stored PANs with tokens so downstream analytics, CRM, and billing systems fall out of scope.
- Point-to-point encryption (P2PE): validated P2PE solutions encrypt card data at the terminal, removing intervening networks from scope.
- Hard segmentation: in cloud environments, isolate the CDE in dedicated accounts, VPCs, or clusters with deny-by-default network policy — then prove the segmentation works with the penetration testing required by Requirement 11.4.5.
A common and expensive mistake is assuming Kubernetes namespaces alone constitute segmentation. Without enforced NetworkPolicies and workload identity boundaries, an assessor can reasonably pull the entire cluster — and everything it talks to — into scope.
Requirements 6.4.3 and 11.6.1: The Magecart Rules
Two of the most operationally challenging new requirements exist because of a specific attack pattern: client-side skimming, popularized by Magecart groups in breaches like British Airways (2018) and Ticketmaster. Attackers compromise a third-party JavaScript tag — a chat widget, an analytics snippet — and use it to skim card data directly from the checkout form in the customer's browser, bypassing every server-side control you have.
PCI DSS 4.0 responds with two paired requirements, both mandatory since March 31, 2025:
- Requirement 6.4.3: every script that loads on a payment page must be inventoried, authorized with a documented business justification, and integrity-assured. In practice this means maintaining a script allowlist and using mechanisms like Subresource Integrity (SRI) hashes or Content Security Policy (CSP) directives to prevent unauthorized scripts from executing.
- Requirement 11.6.1: a change- and tamper-detection mechanism must alert on unauthorized modification to payment page scripts and the HTTP headers received by the consumer browser, evaluated at least weekly or at a frequency justified by a targeted risk analysis.
Teams typically satisfy these with a combination of strict CSP with reporting endpoints, SRI on all third-party tags, synthetic monitoring that renders the payment page and diffs its script inventory, and ruthless pruning of tag managers from checkout flows. The simplest architecture wins: the fewer scripts on the payment page, the smaller the inventory you must defend and document.
Defined vs. Customized Approach: Which Should You Use?
The customized approach is v4.0's headline feature, but it is widely misunderstood. It is not a relaxation of the standard — it is an alternative validation path for mature organizations whose controls achieve a requirement's stated objective through different means. Choosing it per-requirement means producing a controls matrix, a targeted risk analysis (per the templates in Appendix E), and evidence sufficient for your QSA to design their own testing procedures. That is more documentation work, not less.
- Use the defined approach (the traditional prescriptive controls) if you are pursuing first-time compliance, completing a self-assessment questionnaire, or lack a dedicated risk function — SAQ merchants cannot use the customized approach at all.
- Consider the customized approach for specific requirements where prescriptive controls genuinely do not fit — for example, meeting the intent of 90-day account reviews through continuous, event-driven access certification, or replacing scheduled antivirus scans with behavioral runtime detection on immutable container workloads.
- Mix freely: the approach is chosen requirement by requirement, so most organizations run the defined approach for 95% of controls and customize the handful where their architecture is genuinely ahead of the standard.
Whichever path you choose, note that v4.0 quietly embeds targeted risk analysis (Requirement 12.3.1) into many “periodic” activities — you now must document why your chosen frequency for log reviews, POI device inspections, or malware scans is appropriate for your risk, rather than defaulting to whatever the last assessor accepted.
Making Compliance Continuous: Evidence as a Byproduct
The traditional PCI model — a frantic evidence-gathering sprint every twelve months — no longer works under v4.0, which repeatedly uses language like “continuously,” “automated mechanisms,” and “promptly.” Requirement 10.4.1.1 mandates automated log review mechanisms; 11.3.1 expects vulnerability scans at least quarterly plus after significant changes; 11.5.2 requires change detection on critical files. The practical answer is to instrument your pipeline and infrastructure so evidence accumulates as a byproduct of normal operation:
- CI/CD as Requirement 6 evidence: SAST, SCA, and container scans on every merge produce timestamped proof of secure development practices and vulnerability management, with remediation SLAs tracked in the same system.
- CSPM as Requirements 1–4 evidence: continuous cloud posture scanning against the PCI framework demonstrates segmentation, encryption at rest and in transit, and secure configuration — with drift caught in hours instead of at the next assessment.
- Runtime monitoring as Requirements 10–11 evidence: eBPF-based agents observe file integrity events, unauthorized process execution, and unexpected network egress at the kernel level, generating exactly the tamper-detection and monitoring evidence assessors ask for — this is the model TigerGate uses, mapping runtime events directly to PCI DSS controls alongside 38+ other frameworks.
- Identity provider exports as Requirements 7–8 evidence: MFA enforcement reports, 12-character password policy configuration, and quarterly access review attestations pulled automatically rather than screenshotted manually.
Organizations that adopt this model report assessment preparation dropping from months to weeks, because the QSA conversation shifts from “can you find evidence?” to “here is the dashboard.” Just as importantly, continuous evidence means continuous security — the gap between what your compliance report says and what your production environment actually does approaches zero.
Automate PCI DSS Compliance with TigerGate
TigerGate maps your security controls to PCI DSS 4.0 requirements automatically. CSPM scans cloud configurations, SAST/SCA scans code, and eBPF provides continuous runtime monitoring evidence.