SchellmanCON is back! Join us for our virtual conference on March 6 & 7, 2025

Contact Us
Services
Services
Crypto and Digital Trust
Crypto and Digital Trust
Schellman Training
Schellman Training
Sustainability Services
Sustainability Services
AI Services
AI Services
About Us
About Us
Leadership Team
Leadership Team
Corporate Social Responsibility
Corporate Social Responsibility
Careers
Careers
Strategic Partnerships
Strategic Partnerships

What's New in PCI DSS v4.0

Payment Card Assessments

Mary Shelley once said, “nothing is so painful to the human mind as a great and sudden change.”

That’s a rather bleak view from the author of the classic novel Frankenstein, but she’s got a point—change can be difficult.

And those of us in compliance are certainly faced with a big one now because, after a monumental collaboration effort within the payment card industry, the PCI Security Standards Council (PCI SSC) has finally released v4.0 of their Data Security Standard (PCI DSS).

PCI DSS is the flagship of payment security, and this update to the standard marks its largest change since the 2013 release of PCI DSS v3.0. Now that you’ve spent 8 years getting used to 3.0, you now need to start preparing for the switch to this new version, and that probably seems daunting.

As PCI Qualified Security Assessors that have completed over 150 DSS assessments in just the last 12 months, we’re in the same boat as you now, facing this big shift. But our experience, coupled with our comprehensive knowledge of PCI has also put us in a position to help you.

With all due respect to Mary Shelley, we are going to make this great—though not so sudden—change in PCI DSS as painless as possible for you.

In this article, we will provide a high-level overview of the new PCI DSS 4.0 version. We’ll go over what’s new, including approaches, requirements, and more on those edits that are labeled “clarification or guidance.”

Having read through our breakdown, you’ll be more informed about the updates, you’ll feel better about moving forward, and you’ll be better equipped to prepare for what will be a gradual transition.

When Does the New PCI DSS 4.0 Take Effect?

As we mentioned before, the new version of the standard contains updates that affect:

  • The permissible validation approaches;
  • The requirements; and
  • Further clarification.

All that together merits a big increase in complexity and size, but the good news is that the SSC has constructed a long runway to allow you to shift from PCI DSS v3.2.1 to v4.0 more comfortably.

Those required to have a PCI assessment will be able to choose which version (3.2.1 or 4.0) they use for assessments up until March 31, 2024. That date will serve as the official v3.2.1 retirement date and when 4.0 will become the singular standard.

What’s New in PCI DSS v4.0 Timeline

The Two Approaches to PCI DSS 4.0 Compliance

First, let’s break down the update’s new approaches for validating the standard’s requirements. (Of which, there are many, including new ones, which we will address momentarily.)

At its core, the intentions of the standard remain the same—protecting payment data from evolving risks and threats and reinforcing security as a continuous process. But with 4.0, there is a newly stated goal to also “support organizations using different security technologies that meet the intent of PCI DSS requirements.”  

What that translates to is new flexibility in how you can meet the individual security objectives of PCI DSS. This flexibility is evident now in the two separate approaches to PCI DSS assessments that will be permitted under version 4.0:

  • The Defined Approach will essentially take the same course you’re used to—the way things have always been.
    • During your assessment, you will be expected to meet the stated requirements, and your assessors will conduct testing procedures as stated within the standard.
    • As is familiar, where you do not meet a requirement due to legitimate and documented technical or business constraints, compensating controls will fill those gaps.
    • This is consistent with the release of PCI DSS v3.0 in 2013.
  • The all-new Customized Approach is intended for “risk-mature entities” that demonstrate a risk-based approach to security.
    • Rather than meeting every requirement as stated, this approach instead focuses on the objective of each requirement and allows entities to implement controls that make the most sense in their environment.
    • Since solutions are customized, there are no written testing procedures for assessors to follow. Instead, your assessor will derive appropriate testing procedures to validate the solution the entity has implemented.
    • This new custom approach appears to understand better than ever that PCI DSS compliance is no longer one size fits all, and thus supports innovative and modern security practices of all kinds.

To support this new approach, new requirements and tools have been included in v4.0, specifically included in:

  • Requirement 12.3.2: Asks that targeted risk analysis be performed for each PCI DSS requirement that is met with the Customized Approach.

  • Appendix D: Explains and provides instructions for the Customized Approach.

  • Appendix E: Contains templates to support the Customized Approach (Controls Matrix and Risk Analysis)

If you’re unsure about which direction you should potentially choose, don’t worry. The SSC has also provided a thorough guide to assist you in determining which way to go.

Customized Validation vs. Defined Validation

What’s New in PCI DSS v4.0 Graph

What are the New Requirements in PCI v4.0?

Though this split adding the possibility of a Customized Approach is largely the front page news of the 4.0 release, this new version also contains a substantial number of new requirements—64 in total.

  • Despite the big number, it’s important to note that new requirements will taper in over time with only 13 of those 64 being effective immediately when using 4.0.
  • The additional 51 remain “best practices” until March 2025, when they too will be required to complete a PCI DSS assessment after v3.2.1 is retired.
  • If the SSC remains consistent in its versioning methodology, we should expect to see a minor update to version 4.1, or something of that nature, in March of 2025. (They did the same general thing with updates to PCI DSS version 3.0 in 2015.)
For more on some of the major new requirements, read our article that breaks down seven of them from an assessor's perspective so that you better understand how to implement the necessary changes.

What were the Changes in PCI DSS 4.0?

 

Other than the addition of requirements, v4.0 introduced other revisions from the v3.2.1 standard that are categorized into 3 types:

  • “Clarification or Guidance”
  • “Structure or Format”
  • “Evolving Requirements”

PCI DSS 4.0 “Clarification or Guidance”

The 104 edits total categorized as this type are changes made to increase understanding or provide further information or guidance on a particular topic within the standard.

These updates include changes to wording, better explanations, and clearer definitions, as well as additional guidance and/or instructions.

Some examples:

  • In 6.5.5, the term was changed from “testing or development” to “pre-production” environments.

  • It was further clarified that live primary account numbers (PANs) are not used in pre-production environments except where all applicable PCI DSS requirements are in place, providing some flexibility to organizations using the popular DevOps development process.

  • In 11.2.1, it was clarified that rogue wireless detection must be performed even if wireless is not used in the cardholder data environment (CDE) and even if the entity has a policy that prohibits its use.

PCI DSS 4.0 “Structure of Format”

Another 53 edits were categorized this way as they are meant to reorganize content, including combining, separating, and renumbering requirements for alignment.

An example:

  • In 2.8, a note was added that this requirement does not apply to user accounts on point-of-sale (POS) terminals that have access to only one card number at a time during a single transaction.
  • In PCI DSS v3.2.1, the verbiage was a bit more ambiguous and could be misconstrued to include other user accounts in call center environments or other situations not at POS.

PCI DSS 4.0 “Evolving Requirement”

 

Labeled “Evolving Requirements,” the approximately 80 remaining changes are meant to ensure that the standard is up-to-date with emerging threats and technologies, and changes in the payment industry.

Revisions to this category include the addition of new requirements and the removal of requirements, as well as modified requirements or testing procedures.

An example:

  • Requirement 8.2.2 has now changed focus to allow the use of shared authentication credentials but only on an exception basis.
  • Because most organizations have shared user accounts for emergency or break glass purposes, this revision may help reduce the number of compensating controls an organization has historically been forced to complete.

Next Steps for PCI DSS 4.0

PCI DSS version 4.0 represents a definitive shift for the flagship standard of payment security. Mary Shelley might say that such a “great change” is painful, but now you understand all these revisions at a very high level, along with how much time you have to start adapting to them.

But this new version can’t be fully understood with just one article. That’s why we've published several additional blogs and videos on various aspects of PCI DSS v4.0:

By Industry
By Concept
By Specific Requirement

All that content will provide various specialized insights, but in the meantime, please feel free to contact us at PCIROCS@schellman.com or through our contact us page with any specific questions you may have. We are happy to set up a personal conversation that will address your concerns regarding the impact this new version will have on your organization, and we look forward to helping alleviate that anxiety.

About Matt Howard

Matt Howard is a Senior Associate with Schellman focused primarily on PCI assessments for organizations across various industries. Prior to working at Schellman, Matt ran a Security Operations Center (SOC) helping various organizations improve their security posture while preventing, detecting, analyzing, and responding to cybersecurity incidents.