The Payment Card Industry Data Security Standard (PCI DSS), which had a major update in March 2022, has been revised.

This limited revision, PCI DSS v4.0.1, reflects community feedback and includes several corrections and clarifications designed to improve the usability and effectiveness of the standard for organizations that process, store, transmit, or impact the security of cardholder data and/or sensitive authentication data. 

Since keeping up with the latest changes to compliance requirements like PCI DSS can be difficult, Secureframe makes it part of its mission to keep customers informed regarding any changes that could affect their environment and to keep the Secureframe platform up-to-date. 

In line with this mission, we’ll explain the changes made in PCI DSS 4.0.1 and what they mean for your organization.

What is PCI DSS v4.0.1?

PCI DSS v4.0.1 is a limited revision to PCI DSS v4.0 that addresses stakeholder feedback and questions that have been received since v4.0 was published in March 2022. This revision demonstrates the continuous effort to encourage and enhance payment account data security and facilitate the broad adoption of consistent data security measures globally. 

Since PCI DSS 4.0.1 is a limited revision, there are no major changes, such as requirements being added or removed. Instead, this latest version includes corrections to formatting and typographical errors and clarification of the focus and intent of some of the requirements and guidance. 

PCI DSS 4.0.1 changes at a glance

All changes in PCI DSS 4.0.1 fall into two categories:

1. Clarification or guidance: This refers to any updates to wording, explanation, definition, additional guidance, and/or instruction that are made to increase understanding or provide further information or guidance on a particular topic. This change type makes up the bulk of the changes in v4.0.1.
2. Structure or format: This refers to any reorganization of content, including combining, separating, and renumbering of requirements to better align content. 

Let’s take a closer look at these changes below. 

Correcting or updating wording or formatting

PCI DSS 4.0.1 includes corrections for typographical and other minor errors, like missing headers.

For example, any instances of the phrase “impact the security of the CDE” in v4.0 has been changed to “impact the security of cardholder data and/or sensitive authentication data” in v4.0.1. Additionally, the Testing Procedures have been updated to align with updated Requirement wording in v4.0.1.

The goal of these corrections and minor tweaks are to improve the readability and effectiveness of the standard. 

Updating appendices and removing templates

There have also been several changes around the Glossary or Appendix G. First, any definitions included in Guidance that were also included in the Glossary have been removed in v4.0.1. The Guidance now refers to the Glossary instead. 

Also in v4.0.1, there are additional references to the Glossary for newly defined glossary terms (like “legal exception” and “visitor”) as well as existing ones that previously did not have references. 

The other major change was to Appendix E. In v4.0.1, the Customized Approach sample templates were removed and instead the appendix notes the templates are available on the PCI SSC website.

Adding or clarifying applicability notes

Most notably, PCI DSS 4.0.1 contains updated and clarified guidance for several requirements, particularly around applicability notes. Below we will provide an overview of the most important applicability changes: 

Requirement 3: Protect stored account data 

Who this affects: Issuers and companies that support issuing services 

Requirement 3.3.1 states that sensitive authentication data (SAD) is not stored after authorization, even if encrypted and requirement 3.3.2 states that SAD that is stored electronically prior to completion of authorization is encrypted using strong cryptography. In PCI DSS 4.0, it was not clear whether issuers and companies that support issuing services had to meet these requirements.

PCI DSS 4.0.1 clarifies that requirements 3.3.1 and 3.3.1 do not apply to issuers and companies that support issuing services that have a “legitimate and documented business need” to store SAD. 

Additionally, v4.0.1 clarifies that for organizations using keyed cryptographic hashes to render Primary Account Numbers (PAN) unreadable to meet requirement 3.5.1, this requirement applies to PANs stored in primary storage (like databases) and non-primary storage (like audit logs).

Requirement 6: Develop and maintain secure systems and software 

Who this affects: Organizations with critical and high-risk vulnerabilities

In PCI 4.0, requirement 6.3.3 states that patches/updates for critical and high-risk vulnerabilities had to be installed within one month of release. V4.0.1 reverted to PCI DSS v3.2.1 language that the requirement of installing patches/updates within 30 days applies only for critical vulnerabilities, not high-risk ones.

Who this affects: Organizations redirecting or embedding a third party service for checkout

Requirement 6.4.3 stipulates how to manage payment page scripts that are loaded and executed in the consumer’s browser. In PCI DSS 4.0, it was not clear if it applied to merchants embedding payment pages/forms from third-party service providers (TPSPs) or payment processors. v4.0.1 clarifies that it does apply to these merchants, but that script compliance ownership is split between the merchant and the TPSP so that the merchant owns scripts and headers outside of the embedded TPSP’s iframe and the TPSP owns those the inside the embedded TSPS’s iframe.

Requirement 8: Identify users and authenticate access to system components

Who this affects: Organizations with user accounts that are only authenticated with phishing-resistant authentication factors. 

Requirement 8.4.3 states that MFA is implemented for all non-console access into the CDE. PCI DSS 4.0.1 added an exception, clarifying that this requirement does not apply to user accounts that are only authenticated with phishing-resistant authentication factors. 

Requirement 12: Support information security with organizational policies and programs

Who this affects: Organizations that engage third-party service providers (TPSPs) to store, process or transmit account data or to manage in-scope system components on their behalf as well as they TPSPs themselves 

Organizations may engage third-party service providers to store, process or transmit account data or to manage in-scope system components on their behalf. Requirement 12.8 addresses how to manage these TPSP relationships and 12.9 addresses how TPSPs support their customers’ PCI DSS compliance. 

PCI DSS 4.0.1 clarifies several points about relationships between customers and third-party service providers (TPSPs). 

For example, PCI DSS 4.0.1 clarifies that, per requirement 12.9.2 all TPSPs are required to support their customers’ requests for information about the TPSP’s PCI DSS compliance status related to the services provided to customers. Additionally, for TPSPs that provide services that meet customer PCI DSS requirements or can impact security of customer account data, they must also support their customers’ request for information about which PCI DSS requirements are the responsibility of the TPSP, which are the responsibility of the customer, and any responsibilities shared between the customer and the TPSP.

When does PCI DSS 4.0.1 go into effect?

PCI DSS 4.0.1 was released on June 11, 2024 and is in effect today. Until December 31, 2024, the previous version of PCI DSS — v4.0 — will also remain active to give organizations time to adopt the latest version of the standard.  
After December 31, 2024, PCI DSS v4.0 will be retired and v4.0.1 will become the only active version of the standard. 

How Secureframe can help you comply with PCI DSS v4.0.1

Whether you’re already PCI certified or pursuing PCI certification for the first time, you should take the following steps to start transitioning to PCI DSS v4.0.1.
To start, review the Summary of Changes from PCI DSS v4.0 to v4.0.1, available now in the PCI SSC Document Library, for an in-depth comparison.

If you are a Secureframe customer, you can reach out to your compliance manager to have an in-depth discussion about your current environment and scope to help determine exactly which controls are applicable to you and how you can implement them within your environment in order to meet the changes in version 4.0.1.

You can then use the Secureframe platform to assign owners to tasks, controls, and reviews, manage the completion of security awareness training and policy acceptance, complete other readiness work, and remediate automated tests with the support of our compliance managers. Secureframe compliance managers can also perform a gap assessment with you prior to your audit so you can be confident in your PCI DSS v 4.0.1 compliance before your auditor performs the actual assessment.

Finally, you can select one of our partner QSAs to perform fieldwork directly within the platform.

For more information on how you can comply with PCI DSS v4.0.1 by December 31, 2024, schedule a demo with one of our product experts today.