← Back to all briefings
Compliance 6 min read Published Updated Credibility 87/100

PCI DSS 4.0

PCI DSS 4.0's grace period is over. March 31, 2025 ends the three-year transition from v3.2.1—no more exceptions. If you handle cardholder data, you need MFA everywhere (not just remote access), automated log review, and script integrity monitoring on payment pages.

Kodi C.

Editor & Research Lead

Accuracy-reviewed by the editorial team

Compliance pillar illustration for Zeph Tech briefings
Compliance controls, audit, and evidence briefings

The PCI Security Standards Council confirms as the end of the v3.2.1 transition period. All entities that store, process, or transmit cardholder data must implement PCI DSS 4.0 requirements, including stronger authentication, targeted risk analyzes, expanded logging, and e-commerce script integrity monitoring. QSAs will assess against 4.0 for ROC/SAQ submissions after the deadline. This is the most significant update to payment card security standards in over a decade, introducing risk-based approaches alongside prescriptive controls.

Evolution of Payment Card Security Standards

PCI DSS 4.0 represents a fundamental evolution in payment security philosophy. While previous versions relied primarily on prescriptive controls with specific technical requirements, version 4.0 introduces the customized approach, allowing organizations to implement alternative controls that meet the security objectives of each requirement. This flexibility acknowledges that security technologies and threat landscapes evolve faster than standards development cycles.

The transition from version 3.2.1 began with the publication of PCI DSS 4.0 in March 2022. Organizations have had a three-year transition period to implement the new requirements, with the final deadline of March 31, 2025 marking the end of this transition. After this date, all assessments must validate compliance with version 4.0, and version 3.2.1 controls will no longer satisfy compliance requirements.

The standard introduces several structural changes beyond new requirements. The twelve high-level requirements remain but have been reorganized for clarity. Requirements now explicitly state security objectives, providing context for both the defined approach with specific controls and the customized approach allowing alternative setups. Guidance sections have been expanded to help organizations understand the intent behind requirements.

Authentication and Access Control Enhancements

Multi-factor authentication requirements under PCI DSS 4.0 expand significantly from previous versions. Requirement 8.4.2 mandates MFA for all access into the cardholder data environment, not just remote access. This means console access, network connections from corporate networks, and all other access paths must implement MFA. Organizations relying on single-factor authentication for internal access must implement MFA capabilities before the deadline.

Password requirements have also been strengthened. Minimum password length increases from seven to twelve characters for service accounts and personnel with administrative access. Password complexity requirements must be enforced through technical controls, and periodic password rotation remains required. If you are affected, review password policies and technical enforcement mechanisms to stay compliant.

Access control reviews gain additional structure under version 4.0. Requirement 7.2.5 requires all access privileges be reviewed at least every six months. The review must verify that access remains appropriate based on job function and that endd users have been removed. Organizations need documented processes for conducting and evidencing these reviews.

Targeted Risk Analysis Framework

Perhaps the most significant conceptual change in PCI DSS 4.0 is the introduction of targeted risk analysis. Certain requirements now allow organizations to define control frequencies, scope, and setup details based on documented risk analyzes rather than prescriptive timeframes. This approach acknowledges that risk levels vary across organizations and that one-size-fits-all requirements may not improve security outcomes.

Targeted risk analyzes must follow a documented methodology that considers asset criticality, threat environment, vulnerability information, and organizational risk tolerance. analyzes must be performed at least annually and whenever significant changes occur that might affect the risk determination. Results must be documented with clear rationale supporting the chosen control parameters.

Requirements subject to targeted risk analysis include log review frequencies, vulnerability scan frequencies for internal systems, and penetration testing scope and frequency for certain organizations. Organizations must be prepared to show their risk analysis methodology to assessors and justify the parameters they have selected. Insufficient documentation or flawed methodology could result in assessment findings.

Logging and Monitoring Requirements

PCI DSS 4.0 expands logging and monitoring requirements significantly. Requirement 10 now mandates automated mechanisms to perform audit log reviews, addressing the practical challenges of manual log review at scale. Organizations must implement tools capable of analyzing logs, identifying anomalies, and alerting security personnel to potential security events.

Log retention periods remain at one year with three months immediately available. However, 4.0 adds requirements for integrity controls ensuring logs cannot be modified without detection. Organizations must implement mechanisms such as write-once storage, cryptographic hashing, or centralized logging with access controls to prevent log tampering.

Security event detection capabilities must be improved under 4.0. Organizations must implement detection mechanisms for critical file modifications, security control failures, and unauthorized configuration changes. Detection mechanisms must generate alerts to appropriate personnel for investigation and response. The requirement for security control failure detection is particularly important, as it ensures organizations are aware when protective controls become ineffective.

E-Commerce and Script Security Requirements

Requirements 6.4.3 and 11.6.1 introduce new controls specifically targeting e-commerce environments and payment page security. Organizations must maintain an inventory of all scripts executing on payment pages and implement mechanisms to ensure script integrity. This addresses the growing threat of web skimming attacks where malicious scripts are injected into payment pages to capture cardholder data.

Script inventory requirements mandate documentation of all scripts on payment pages, authorization for each script, and periodic verification that only authorized scripts are present. Organizations must implement technical controls to detect unauthorized script changes, such as Content Security Policy headers, subresource integrity attributes, or script monitoring tools.

HTTP header security requirements also apply to payment pages. Organizations must implement security headers including Content-Security-Policy to restrict script sources and X-Frame-Options to prevent clickjacking attacks. These technical controls provide defense-in-depth protection for cardholder data entry pages.

Service Provider Requirements

Organizations relying on service providers for payment processing or cardholder data storage must ensure their providers show 4.0 compliance. Requirement 12.8 requires organizations maintain agreements with service providers acknowledging their responsibilities for cardholder data security and that organizations monitor provider compliance status annually.

Attestation of Compliance documents from service providers must reflect PCI DSS 4.0 assessment after March 31, 2025. If you are affected, request updated AOCs from their providers confirming 4.0 compliance and verify that the scope of the AOC covers the services provided. Gaps in provider coverage may require additional controls or risk acceptance decisions.

Shared responsibility matrices gain importance under 4.0. Organizations must clearly document which requirements are met by the organization, which by the service provider, and which are shared responsibilities. This documentation supports both compliance evidence and operational clarity about security accountabilities.

Assessment and Evidence Preparation

Organizations approaching assessment deadlines should focus on evidence readiness. Assessors will require documentation of policies, procedures, configuration standards, and risk analyzes. Evidence should show not just control existence but control effectiveness over time. If you are affected, compile screenshots, configuration exports, log samples, and procedure documentation well before assessment fieldwork begins.

Gap remediation activities should be focus ond based on assessment timeline and setup complexity. MFA setup, log automation, and script inventory capabilities often require significant technical work and should be addressed early. Simpler documentation updates can be completed closer to assessment deadlines but should not be deferred indefinitely.

Internal audit or readiness assessment activities help identify gaps before formal QSA assessment. If you are affected, consider engaging QSAs for interim reviews or gap assessments if internal capabilities are limited. Early identification of issues provides time for remediation without assessment deadline pressure.

Similar analysis

Additional analysis covering similar themes.

Continue in the Compliance pillar

Return to the hub for curated research and deep-dive guides.

Visit pillar hub

Latest guides

  • Third-Party Risk Oversight Playbook

    Operationalize OCC, Federal Reserve, EBA, and MAS outsourcing expectations with lifecycle controls, continuous monitoring, and board reporting.

  • Compliance Operations Control Room

    Implement cross-border compliance operations that satisfy Sarbanes-Oxley, DOJ guidance, EU DORA, and MAS TRM requirements with verifiable evidence flows.

  • ESG Assurance Operating Guide

    Deploy credible ESG assurance across CSRD, SEC climate disclosure, and ISSA 5000 requirements with regulator-aligned controls, data governance, and audit-ready evidence.

Coverage intelligence

Published
Coverage pillar
Compliance
Source credibility
87/100 — high confidence
Topics
PCI DSS 4.0 · Payment security · Cardholder data protection
Sources cited
3 sources (pcisecuritystandards.org, blog.pcisecuritystandards.org, iso.org)
Reading time
6 min

Further reading

  1. PCI DSS v4.0 Standard and Summary of Changes — PCI Security Standards Council
  2. PCI SSC — PCI DSS v4.0 Resource Hub — PCI Security Standards Council
  3. ISO 37301:2021 — Compliance Management Systems — International Organization for Standardization
  • PCI DSS 4.0
  • Payment security
  • Cardholder data protection
Back to curated briefings

Comments

Community

We publish only high-quality, respectful contributions. Every submission is reviewed for clarity, sourcing, and safety before it appears here.

    Share your perspective

    Submissions showing "Awaiting moderation" are in review. Spam, low-effort posts, or unverifiable claims will be rejected. We verify submissions with the email you provide, and we never publish or sell that address.

    Verification

    Complete the CAPTCHA to submit.