Release of PCI DSS 4.0.1 Finetunes Industry Guidance

Share This Post

Table of Contents

In June 2024, the PCI Security Standards Council published a limited revision to PCI DSS v4.0. The revision includes corrections to typos and formatting errors. According to a post by the PCI SSC, the update “clarifies the focus and intent of some of the requirements and guidance.”  In short, PCI DSS 4.0.1 introduces “no additional or deleted requirements.”

When Does PCI DSS 4.0.1 Go into Effect?

PCI DSS 4.0.1 is running concurrently with PCI DSS 4.0 right now, but PCI DSS 4.0 will sunset on December 31, 2024.

Should I Be Worried About the Transition From PCI DSS 4.0 to 4.0.1?

The good news is that the answer is “no!” The new standard simply clarifies requirements, provides small updates, and tweaks wording and applicability notes. PCI DSS 4.0.1 is a great update. It provides users with greater clarity in many of the gray areas within requirements. Feedback from the industry prompted this latest revision.

About This Post

At Insight Assurance, PCI DSS Compliance is our specialty. This post provides a quick overview of the changes to 4.0 and is in support of our ongoing mission to secure payment card data and reduce the risk of data breaches.

What Changes Are There in PCI DSS 4.0.1?


Additional guidance has been provided for many of the requirements to aid organizations in interpretation.

Adjustments of Requirements

There are no new requirements, but requirements have been “fine-tuned based upon feedback from the industry.”

Clarifications and Corrections

Many of the updates clear up confusion within PCI DSS 4.0 and ensure a consistent application of the standards. Additional guidance has been provided for many of the requirements to aid organizations in interpretation. 

Changes to the Introductory Sections

  • Updated the term “Validated Software Vendors” to “Qualified Software Vendors” to reflect the retirement of PA-DSS, which was retired in late 2022.
  • Added a   what to do when sensitive account data (SAD) or cardholder data (CHD) is accidentally received via an unintended channel.
  • Guidance regarding understanding third-party service providers (TPSPs) used to meet compliance requirements.
  • Updated table containing timeframes and significant changes.

The Most Interesting and Significant Changes to Specific PCI DSS Requirements

Requirement 3: Protect Stored Account Data

Cleared up the applicability notes for credit card issuers and supporters. Added an objective and applicability statement for making primary account numbers unreadable.

Specific sections affected: 3.3, 3.4, and 3.5       

Requirement 4: Protect Cardholder Data With Strong Cryptography During Transmission Over Open Public Networks

Moved an applicability note about cardholder data from an unsolicited channel to a new sub-section Scope of PCI DSS Requirements. Also, the Acceptable Use Policies for Good Practice were added.

Specific sections affected: 4.2.1 and 4.2.2

Requirement 5: Protect All Systems and Networks From Malicious Software

Clarifies the requirement that automated mechanisms do not apply to “systems providing the mechanisms.”

Specific section affected: 5.4.1

Requirement 6: Develop and Maintain Secure Systems and Software Applications

Added several applicability notes clarifying how managing payment page scripts applies to maintaining secure payment card systems.

Other Specific sections affected: 6.3*, 6.4. 6.5

* 6.3.3 – Patching within one month of release previously applied to high and critical vulnerabilities. Now the one-month timeframe only applies to critical vulnerabilities. This change will lighten the workload for changes that need to take place quickly (within 30 days), as well as allow for a longer timeframe for high vulnerabilities now.

Requirement 8: Identify Users and Authenticate Access to System Components

Updated requirements statements to clarify that certain requirements “are not intended to apply to user accounts on specific point-of-sale terminals…”

Other specific sections affected: 8.2.2, 8.3.9, 8.4.1, 8.4.2, 8.4.3, and 8.5.1

Requirement 9: Restrict Physical Access to Cardholder Data

Added a statement to the overview stating that each entity must identify sensitive areas in their environment “to ensure appropriate physical security controls are implemented.” Also, the change noted that publicly accessible locations are exempted from this requirement.*          

Specific sections affected: *9.2.1, 9.3.4, 9.5.1        

Requirement 10: Log and Monitor All Access to System Components and Cardholder Data

Added information on setting up a baseline for normal audit activity.*

Other sections affected: * and 10.5.1.

Requirement 11: Test the Security of Systems and Networks Regularly

Includes several references and clarifications of the terms “high-risk” and “either critical or high risk” and how this requirement is applicable.

Sections affected: 11.2.1, 11.3.1, 11.3.2, and 11.6.1      

Requirement 12: Support Information Security With Organizational Policies and Programs

Updated and clarified several points regarding relationships between third-party service providers and customers.

Other sections affected: 12.1.4, 12.3.1, 12.3.3, 12.8.2, 12.9.1 and 12.9.2.


Removed sample templates and redirected attention to sample templates available on the PCI SSC Website. Added three definitions to Appendix G:

  1. Legal Exception
  2. Phishing Resistant Authentication
  3. Visitor


DSS PCI 4.0.1 is a user-friendly update to the standard. It demonstrates that the PCI SSC is receiving quality feedback and acting on it. As demonstrated above, most of those updates make the standard more useable and more applicable.

Again, there is nothing to fear in the new update. We have provided only a summary of the items requiring special attention. If you have any further questions and would like to talk to a QSA, please contact us for a scoping call!

For Further Reading

Referenced and linked throughout this post are the following:

Subscribe To Our Newsletter

Get updates and learn from the best

More To Explore

SOC Resources
The Essential SOC 2 Compliance Checklist

As businesses increasingly rely on cloud services and third-party vendors, ensuring the security and privacy of customer data has become a top priority. One of

How To Know If You're Ready for a SOC 2 Audit
SOC Resources
How To Know If You’re Ready for a SOC 2 Audit

Not sure if you’re prepared for a SOC 2 audit? Learn how to assess your readiness with our comprehensive guide on SOC 2 requirements and best practices.

Why Insight Assurance?

Elevate customer trust, reduce compliance burdens, and enhance security practices with us.

Is your organization ready?

Contact us to discuss your needs.