PCI DSS 4.0.1 Update

How the New v4.0.1 Changed PCI DSS 4.0 (and How it Didn’t)

Compliance with PCI Data Security Standard 4.0 is still mandatory by March 31, 2025!

PCI DSS 4.0 was released more than two years ago, replacing v3.2.1 and imposing 64 new requirements. Payment card industry members should be well on their way to implementing those new requirements prior to their next assessments.

Recently, the PCI Security Standards Council issued a minor update to v4.0, in the form of v4.0.1, to correct formatting and typographical errors in v4.0 and also clarify the focus and intent of some of the v4.0 security requirements.

It is important to understand four important facts about PCI DSS 4.0.1:

4.0.1 is termed a “limited revision” and as such contains no new requirements.
Similarly, no existing requirements in v4.0 were deleted.
4.0.1 incorporates all of the security requirements in v4.0, along with corrections and clarifications.
The deadline for full compliance with v4.0 has not changed from March 31, 2025.

Just six months remain for payment card industry members to complete their adoption of v4.0 requirements, which are extensive, and conduct their next annual risk assessments against those requirements.

PCI DSS 4.0.1 Replaces v4.0 on December 31, 2024

PCI DSS 4.0 was published on March 31, 2022, replacing the previous version (PCI DSS 3.2.1). As organizations began implementing requirements of the new version (v4.0), formatting and typographical errors became evident, and users were requesting clarity and providing helpful feedback. In response, the PCI Security Standards Council drafted a limited revision to v4.0. Below are key milestones in the development of v4.0.1.

Comment Period. According to the PCI Security Standards Council website, a review and comment period was open from December 2023 through January 2024. During this time, the PCI SSC Board of Advisors, Global Executive Assessor Roundtable, and Principal Participating Organizations (through the Technology Guidance Group) were invited to review and provide feedback on the proposed corrections and clarifications in v4.0.1.

Parallel Versions. The new PCI Data Security Standard 4.0.1 was published in June 2024. It will run parallel to the existing v4 until December 31, 2024, when v4.0 will be officially retired. PCI DSS v4.0.1 will then be the only active version of the standard. This process is consistent with previous major releases and subsequent updates.

Updating Reports and Templates. While the complete, official v4.0.1 standard is now available on the PCI Security Standards Council website, supporting documentation is still being updated to reflect v4.0.1 content. For example, templates for the PCI DSS v4.0.1 Report on Compliance (ROC) and Attestation of Compliance (AOC), along with the Self-Assessment Questionnaires (SAQs), are expected to be published this month (October 2024). The updated Prioritized Approach tool and other supporting documents are expected shortly thereafter.

Implementation. Compliance with PCI DSS 4.0.1 will be required by March 31, 2025. All organizations must have implemented the requirements of v4.0 by this date and demonstrate compliance with those requirements in their next risk assessments.

General Changes in PCI DSS 4.0.1

A complete Summary of Changes from PCI DSS 4.0 to PCI DSS 4.0.1, dated June 2024, is available on the PCI website. Below are highlights of the general changes.

Typographical and other minor errors were corrected, including formatting errors, missing words, missing headers, and similar oversights.
Guidance was updated and clarified, including changes needed to align with related resources such as the v4.0 Quick Reference Guide and v4.0 Frequently Asked Questions.
New glossary terms were added for clarification. Definitions were removed from the Guidance section if they were also included in the Glossary, with the Glossary (Appendix G) referenced instead.
The phrase “impact the security of the CDE” was changed to “impact the security of cardholder data and/or sensitive authentication data” throughout the standard wherever appropriate.

Overview of Changes to Requirements in PCI DSS 4.0.1

Listed below are most of the changes made to v4.0 requirements by v4.0.1, to give you a sense of the limited scope and scale of this minor revision. For a complete listing, refer to the Summary of Changes from PCI DSS 4.0 to PCI DSS 4.0.1 on the PCI website. Because no changes were made to Requirements 2 and 7, they are not listed below.

Requirement 1 – Install and maintain network security controls

1.2.2 - Added the word Purpose which was inadvertently missing.

Requirement 3 – Protect stored account data (SAD)

3.3.1 - Updated Applicability Note for issuers and companies who support issuing services that any SAD storage is based on “a legitimate and documented business need.” Added description of legitimate business need. Added Good Practice to address when it may be acceptable to store SAD in non-persistent memory.
3.3.1 - Changed the word retained to stored for consistency.

3.5.1 – Changed Purpose from “The removal of cleartext PAN” to “Rendering PAN unreadable” and removed second, confusingly worded, paragraph. Added to Good Practice that implementing keyed cryptographic hashes with associated key management processes and procedures is a valid additional control to prevent correlation.

3.5.1.1 - Added Customized Approach Objective and clarified applicability for organizations who use keyed cryptographic hashes to render Primary Account Numbers (PAN) unreadable.
3.5.1.2 – Added Applicability Note about types of encryption methods requirement applies to and clarified applicability to issuers and companies who support issuing services.

Requirement 4 – Protect cardholder data with strong cryptography during transmission over open public networks

4.2.1 - Moved Applicability Note about receiving cardholder data through an unsolicited channel to a new sub-section in Section 4, Scope of PCI DSS Requirements. Removed sentence that covered self-signed certificates.
4.2.2 – Updated Good Practice regarding use of Acceptable Use Policies to manage end-user technologies.

Requirement 5 – Protect all systems and networks from malicious software

5.4.1 - Removed Applicability Note concerning automated mechanism to make it clear the requirement does apply to systems that provide the mechanism. (PCI DSS in general applies to systems that provide security services.)

Requirement 6 – Develop and maintain secure systems and software

6.3.1 - Clarified Applicability Note that requirement is in addition to performing vulnerability scans according to requirements 11.3.1 and 11.3.2.
6.3.3 - Reverted to PCI DSS 3.2.1 language that installing patches/updates within 30 days applies only for “critical vulnerabilities.” Removed language that the requirement applies to “high-security patches/updates.”
6.4.3 - Clarified that “An inventory of scripts is maintained with written business or technical justification as to why each is necessary.” Added Applicability Notes to clarify how the requirement for managing payment page scripts applies.
6.4.3 - Under Good Practice, added guidance that the entity should expect the TPSP/payment processor to provide evidence that it meets this requirement, where entity includes TPSP’s/payment processor’s embedded payment page/form on its webpage.
6.5.5 - Clarified, under Definitions, that live Primary Account Numbers (PANs) are those issued by, or on behalf of, a payment brand. Removed wording that live PANs have potential to be used for payment transactions.

Requirement 8 – Identify users and authenticate access to system components

General – Added italics to statement in Overview and Applicability Notes: “Certain requirements are not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction” and removed a parenthetical example.

8.3.9 - Clarified Applicability Note that requirement does not apply to in-scope system components where MFA is used.
8.4.2 - Added Applicability Note that multi-factor authentication for all (non-administrative) access into the CDE does not apply to user accounts that are only authenticated with phishing-resistant authentication factors.

8.4.3 - Clarified this requirement applies to “remote access” (rather than the confusing term “remote network access”) and moved bullets about which types of remote access are included to an Applicability Note.
8.4.3 - Added “third parties” to testing procedure.

Requirement 9 – Restrict physical access to cardholder data

General - Added statement that each entity should identify sensitive areas within their environment to ensure appropriate physical security controls are implemented.
9.2.1 - Added Applicability Note that requirement does not apply to locations that are publicly accessible by consumers (cardholders).
9.3.4 - Clarified the requirement is for “visitor logs” rather than “a visitor log” and for “visitor activity both with the facility and within sensitive areas.”

Requirement 10 – Log and monitor all access to system components and cardholder data

10.4.1.1 - Added information about establishing a baseline of normal audit activity under Good Practice. Under Further Information, added reference to the Information Supplement: Effective Daily Log Monitoring.

Requirement 11 – Test security of systems and networks regularly

11.3.1 - Clarified requirement applies to vulnerabilities that are “either critical or high-risk.”
11.3.1 - Added under Good Practice that vulnerabilities identified during internal scans should be part of the vulnerability management process and include multiple vulnerability sources.
11.6.1 - Clarified requirement applies to “security-impacting HTTP headers and the script contents of payment pages.”
11.6.1 - Added three Applicability Notes to clarify how requirement applies to an entity’s webpages and to a TPSP’s/payment processor’s embedded payment pages/forms.
11.6.1 - Added guidance that entity should expect TPSP/payment processor to provide evidence that it meets this requirement, where the entity includes a TPSP’s/payment processor’s embedded payment page/form on its webpage.
11.6.1 - Clarified in Examples that mechanisms which detect and report on changes to headers and content of payment pages “could include, but are not limited to, a combination of the following techniques” and added that the list of mechanisms provided is not exhaustive.

Requirement 12 – Support information security with organization policies and programs

12.1.4 – Clarified executive roles, titles, and seniority descriptions.
12.3.1 - Clarified applicability only to PCI DSS requirements that specify completion of a targeted risk analysis, and that results determine how the entity’s defined frequency or processes minimizes likelihood and/or impact of the threat.

Various - Updated Applicability Notes to clarify several points about relationships between customers and third-party service providers (TPSPs).

Appendices

Appendix D – Changed “Use of the customized approach must be completed by a Qualified Security Assessor (QSA) or ISA and documented in accordance…” to “Use of the customized approach must be documented by a QSA or ISA in accordance…”

Appendix E - Removed Customized Approach sample templates and noted that templates are available on the PCI website.
Appendix G - Added definitions for Legal Exception, Phishing Resistant Authentication, and Visitor and clarified definitions for Entity, Interactive Login, Payment Page, and QSA.

Summary

Payment card industry members must implement the rigorous security requirements of PCI DSS 4.0, released in March 2022, prior to their next annual risk assessments. In June 2024, a minor update (v4.0.1) was released to correct formatting and typographical errors and clarify certain requirements. This limited revision did not add or delete any of the v4.0 requirements, nor did it change the compliance deadline.

The PCI Data Security Standard was developed to reduce vulnerabilities, strengthen security, and avoid costly data breaches within the payment card industry. Compliance is mandatory. Security executives owe it to their customers and other stakeholders to achieve full compliance with the new standard by March 31, 2025. With the deadline now just six months away, there’s not a moment to waste. (Schedule a PCI DSS 4.0 Gap Assessment)