“The big news with version 4 of the Data Security Standard is that this is a major release and some significant changes have occurred.”

Mark Bayerkoler, PCI Security Council

Key takeaways

You have time! Get familiar with PCI DSS v4.0 to be ready

  • March 31, 2024: PCI DSS v3.2.1 retired
  • March 31, 2025: PCI DSS v4 requirements are effective
  • Take a holistic risk-first approach to your payment card process to reduce blind spots
  • Evaluate your entire payment card process
  • Watch latest webinar with tips, tricks and full details: Prepare For PCI DSS v4.0 Now To Stay Ahead of Bad Actors

PCI DSS essentials

Depending on where you are in your compliance journey, you may or may not be familiar with the Payment Card Industry Data Security Standard (PCI DSS). The PCI DSS is a global standard that provides a baseline of technical and operational requirements designated to protect payment data. It was developed by the PCI Council to encourage and enhance payment card account data security and facilitate the broad adoption of consistent data security measures globally.

While specifically designed to focus on environments with payment card account data, PCI DSS can also be used as a security controls framework to protect against threats and secure other elements in any information system.

New in PCI DSS v4.0

The development of PCI DSS v4.0 was driven by over 6,000 pieces of industry feedback collected from over 200 companies. The goal of this latest revision was primarily to bring the requirements up to speed with today’s modern threats. Security practices must evolve as threats change and v4.0 has included several examples such as expanded multi-factor authentication requirements, updated password requirements and new e-commerce and phishing requirements to address evolving threat trends.

And to keep up with the latest threat actors, the PCI DSS v4.0 now requires clearly assigned roles and responsibilities for each requirement, additional guidance to help people better understand how to implement and maintain security, and a new reporting option to highlight areas for improvement and provide more transparency for report reviewers.

Along with this, the PCI DSS V4.0 increases flexibility for organizations using different methods to achieve security objectives. This allows more options to achieve a requirement’s objective and supports payment technology innovation. In particular, there is now an allowance for group, shared, and generic accounts and more targeted risk analyses to empower organizations to establish frequencies for performing certain activities.

One of the largest changes to note is the added requirement to review and confirm PCI DSS scope at least every 12 months. For organizations that aren’t doing this now, assessing your scope as you move towards v4.0 compliance will set a good baseline for the following years.

But the good thing to note is that most of these new requirements will remain best practices and taper in over time. Only 13 of the 64 new requirements will be effective immediately and the remaining 51 will be considered best practices until March of 2025.

Changes from PCI DSS v3.2.1

Along with those new requirements, there were many changes that have been summarized into 3 categories:

Clarification or Guidance

104 edits were made to increase understanding or provide further information or guidance on a particular topic within the standard. For example, in 6.5.5, the term was changed from “testing or development” to “pre-production” environments.

Structure or Format

53 edits were made to reorganize content, including combining, separating and renumbering requirements for alignment. For example, in 2.8, a note was added that this requirement does not apply to user accounts on POS terminals that have access to only one card number at a time during a single transaction.

Evolving Requirements

Approximately 80 remaining changes were made 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. For example, requirement 8.2.2 has now changed focus to allow the use of shared authentication credentials but only on an exception basis. This was done because most organizations have shared user accounts for emergency or break glass purposes, and this revision may help reduce the number of compensation controls an organization has historically been forced to complete.

Your path forward with the Reciprocity ZenGRC Platform

As noted above, v4.0 requires an annual scope review, and now is the perfect time to do so.
But how do you ensure you are staying up to date with PCI compliance and taking into account all of the moving parts that make up your payment processing functionality?

If you are looking at PCI DSS compliance alone, you will inevitably have siloed work and potential blind spots.

Traditional Approach

We need to be PCI DSS Compliant

Conduct control assessments

Generate compliance report

Reciprocity Approach

Secured payment processing

Assess risk associated with payment processing

Reduce and monitor risk to payment processing

The traditional approach to GRC starts with the goal of compliance, then targets activities around control assessments. We review the requirements, collect evidence and assess controls. The end result is a PCI DSS compliance report (SAQ or ROC) that you can share with your customers. And that’s where the process ends.

But what about the risks, threats and vulnerabilities? What about the facilities that house PII or equipment that processes card data? What suppliers impact or engage with your payment processing? None of these things connect.

But Instead of focusing on PCI compliance as your goal, consider instead – why are you trying to be PCI DSS compliant? I’m betting the reason is not to simply be compliant. You are attaining PCI compliance so you can ensure you are properly managing the risk associated with your payment processing.

Take a risk-first approach

That’s why we advise taking a risk-first approach and going beyond just the PCI DSS as a goal. Creating a custom program with the ZenGRC, tailored around your ability to securely process payment card data, will allow you to take into account all compliance requirements, as well as any potential threats, risks, vendors and assets that comprise your payment card process. Looking at the entire process allows you to reduce the risk through your compliance activities and thus you are achieving your goal of securing your revenue stream.

When you start with compliance as your goal, you end up with disconnected processes and a false sense of security that you are properly securing and protecting your cardholder data. Your outcome is “how are we meeting the requirements?” But by using a risk-first approach, your outcome is “how well are we securing our card handling processes?” That’s a much stronger position.

Helpful resources

In order to be fully prepared, here are a few resources for Reciprocity Community members:

Watch our latest webinar, “Prepare For PCI DSS v4.0 Now To Stay Ahead of Bad Actors” to learn expert tips to prepare for the transition and make the most of newfound flexibility and control.