PCI DSS v4.0.1

Why does it matter?

PCI DSS v4.0.1 is the version every PCI DSS assessment now uses. Section 14 names it the current version, and Table 6 records that v4.0 retired on December 31, 2024 and v3.2.1 on March 31, 2024. The standard describes itself as a minimum set of requirements that may be enhanced by additional controls and by local, regional and sector laws, and states that where a requirement conflicts with country, state or local law, the law applies (Section 1). Because payment brands and acquirers decide who must validate (Section 2), the consequence of falling behind is contractual: a merchant or service provider cannot submit an Attestation of Compliance against a retired version.

Key benefits include:

• One current version

Section 14 states that v4.0.1 is the current version of the standard and that questions about the use of previous versions go to the organizations that manage compliance programs, such as payment brands and acquirers.

• Two ways to meet a requirement

Section 8 sets out the defined approach, which follows the stated requirements and testing procedures, and the customized approach, which meets each requirement's Customized Approach Objective in the entity's own way and is intended for risk-mature entities.

• Timeframes with definitions

Table 4 in Section 7 defines daily, weekly, monthly, every three months (90 to 92 days), every six months, every 12 months, periodically (a frequency the entity sets through its targeted risk analysis), immediately, promptly and significant change.

• Scope that is confirmed, not assumed

Section 4 defines the cardholder data environment and the system components in scope, and Requirement 12.5.2 requires the entity to document and confirm its PCI DSS scope at least once every 12 months and upon significant change.

• Clear third-party responsibilities

Requirement 12.8.1 requires a list of all third-party service providers with which account data is shared or that could affect its security, and Section 9 notes that TPSPs are expected to share their Attestation of Compliance with customers.

How does it work?

Each requirement is presented in the layout shown in Figure 5 of Section 15: the Defined Approach Requirement, the Defined Approach Testing Procedures an assessor follows, the Customized Approach Objective, Applicability Notes and a Guidance column with Purpose, Good Practice, Definitions, Examples and Further Information. Applicability Notes apply to both approaches and are an integral part of the standard that must be fully considered during an assessment; Guidance explains how to meet a requirement but is not itself required. The Summary of Changes for v4.0.1 notes that definitions duplicated in guidance were removed in favor of the glossary in Appendix G and that testing procedures were aligned with updated requirement wording.

An entity can use both approaches: the defined approach for some requirements and the customized approach for others (Section 8). Under the defined approach, an entity that cannot meet a requirement as stated because of a documented technical or business constraint may implement compensating controls that meet the intent and rigor of the original requirement, provide a similar level of defense and go above and beyond other PCI DSS requirements (Appendix B); they are documented each year on the Appendix C worksheet and validated by the assessor. Under the customized approach, the entity keeps a controls matrix and a targeted risk analysis for each customized control (Appendix D and Requirement 12.3.2) and the assessor derives the testing procedures.

The assessment process in Section 12 has six steps: confirm the scope, perform the assessment, complete the applicable report, complete the Attestation of Compliance for service providers or merchants, submit the documentation to the requesting organization, and remediate and re-report where requirements are not in place. A requirement is not considered in place if its controls are not yet implemented or are scheduled for a future date. Reports follow the ROC Template, self-assessments follow the SAQ Instructions and Guidelines, and official Attestations of Compliance are available only on the PCI SSC website. Section 5 adds business-as-usual practices, such as assigning overall responsibility for PCI DSS compliance and reviewing technologies at least once every 12 months.

Key Elements

• Twelve principal requirements in six groups (Table 1)

Build and maintain a secure network and systems (Requirements 1 and 2); protect account data (3 and 4); maintain a vulnerability management program (5 and 6); implement strong access control measures (7, 8 and 9); regularly monitor and test networks (10 and 11); maintain an information security policy (12).

• Account data (Section 2, Table 2)

Cardholder data is the primary account number (PAN), cardholder name, expiration date and service code; sensitive authentication data is full track data, the card verification code and PINs or PIN blocks. The PAN is the defining factor: if an entity stores, processes or transmits PAN, a cardholder data environment exists.

• Targeted risk analysis (Requirement 12.3.1)

For each requirement that allows the entity to set a frequency, the analysis identifies the assets protected, the threats, the factors contributing to likelihood and impact, and the justification for the chosen frequency, and is reviewed at least once every 12 months.

• Future-dated requirements

Several requirements carry the applicability note that they were a best practice until March 31, 2025, after which they are required and must be fully considered during a PCI DSS assessment; Requirements 12.3.1 and 10.4.2.1 are examples.

• Additional requirements for service providers only

Requirements marked for service providers apply in addition to all others, for example 12.4.1 (an executive-owned PCI DSS compliance program with a charter) and 12.9.1 (written agreements acknowledging responsibility for customers' account data); the standard recommends them to all entities.

• Appendix A

A1 for multi-tenant service providers, A2 for entities using SSL or early TLS for card-present POS POI terminal connections, and A3 Designated Entities Supplemental Validation (DESV) for entities a payment brand or acquirer designates.

• Appendices B to G

Compensating controls (B) and their worksheet (C), the customized approach (D), sample templates to support it (E), use of the PCI Software Security Framework to support Requirement 6 (F) and the glossary of terms, abbreviations and acronyms (G).

• What v4.0.1 changed

The Summary of Changes (Revision 1, August 2024) lists only clarification, guidance and format changes: typographical corrections, glossary references, 'SAD is not stored after authorization' in 3.3.1, a Customized Approach Objective for 3.5.1.1 and a new Section 4 sub-section on account data received through an unintended channel.

What does it cover?

PCI DSS v4.0.1 is intended for all entities that store, process or transmit cardholder data or sensitive authentication data, or that could impact their security, including merchants, processors, acquirers, issuers and other service providers (Section 2). Requirements apply to the cardholder data environment: the system components, people and processes that store, process or transmit account data, components with unrestricted connectivity to them, and components that could affect their security (Section 4). Some requirements apply even where no PAN is handled: SAD storage under Requirement 3, service-provider management under Requirement 12, paper records under Requirement 9 and incident response for every entity. Entities that outsource payment operations remain responsible for their account data.

What are its objectives?

Section 1 states why PCI DSS exists and how its requirements are meant to be used:

To encourage and enhance payment account data security and facilitate the broad adoption of consistent data security measures globally (Section 1).

To provide a baseline of technical and operational requirements that an entity may enhance with additional controls and with local, regional and sector laws and regulations (Section 1).

To give entities flexibility in how security objectives are met through the defined and customized approaches (Section 8).

To keep controls operating between assessments through business-as-usual processes such as control monitoring, prompt response to control failures and periodic technology reviews (Section 5).

To protect information about an entity's security posture, treating the ROC or SAQ, network and data-flow diagrams and configuration standards as sensitive while the Attestation of Compliance is shared (Section 9).

Framework in Context

v4.0.1 is the last step in the version chain in Table 6: v3.2 (April 2016, retired December 31, 2018), v3.2.1 (May 2018, retired March 31, 2024), v4.0 (March 2022, retired December 31, 2024) and v4.0.1 (June 2024). The superseded PCI DSS v3.2 page records the earlier lineage. Section 3 relates PCI DSS to the PCI Software Security Framework and notes the retirement of PA-DSS; using validated software does not by itself make an entity compliant. On October 15, 2024 the Council published the Self-Assessment Questionnaires for v4.0.1, described in its bulletin as validation tools for SAQ-eligible merchants and service providers, with the v4.0 SAQs active only until v4.0 retired; SAQ D for Merchants is the fullest of them.

Common Framework Mappings

PCI DSS v4.0.1 is commonly mapped to the information security control sets below so that controls for the cardholder data environment, and the evidence behind them, can be reused across an organization's other security programs.

Mapped frameworks include:

CIS Controls v8.1

ISO 27001:2022

ISO 27002:2022

ISO 27701

MITRE ATT&CK

NIST CSF 2.0

NIST 800-53 Rev.5

SOC 2