PCI DSS 4.0: A guide to making your organization compliant

The new version of the Payment Card Industry (PCI) Data Security Standard (DSS) becomes mandatory from 1st April 2024. As a key contributor to PCI DSS 4.0, Pluralsight Author John Elliott shares what organizations need to do to get up to speed.

There’s fewer than twelve months left before PCI DSS 4.0 becomes the only version your organization can use. Before then, it’s important to have a strategy for meeting this deadline and implementing the 51 new mandatory requirements. 

Payment card companies can impose monthly fines until you become PCI DSS compliant. If you experience a data breach, your compliance status will affect any financial penalties. And if you’re a service provider, compliance will be a contractual requirement. In short, it pays to be compliant, and costs you a lot not to be. Here’s what you need to get up to speed with PCI DSS 4.0.

• Before you start: Confirm your scope
• How to make your organization PCI DSS 4.0 compliant
• What’s changed with PCI DSS 4.0?
• Further resources

It sounds strange, but before you dive into your 4.0 compliance journey, the most important thing to do is to make a thoughtful decision about the people, the processes, and technology (aka the “scope”) that the requirements will apply to in your organization.

There are a total of sixty-four new requirements in PCI DSS 4.0. Some are going to be easy and low cost to meet, while others are going to take capital investment and changes to your business processes. If you can shrink the scope in any way, this reduces the upfront costs of achieving compliance as well as the ongoing costs of staying compliant. So, the first job is to look at the existing scope and pose the following questions:

• Is it correct: Does it include everything that stores, processes or transmits cardholder data (the cardholder data environment or CDE)? Does it include everything that is connected to the CDE? Can anything else affect the security of the CDE?

• Is it the appropriate size: Can you make architectural or payment technology changes (such as tokenization) to reduce the scope? All scope reduction will save you money in the long-term and will also reduce your attack surface.

Once you’ve understood and agreed on the scope, document it. This isn’t just for your own purposes, but is actually a new 4.0 requirement (12.5.2).

Even though there are a lot of changes in PCI DSS 4.0, an organization that is compliant with version 3.2.1 should find the initial transition reasonably painless. Here are some key steps that should make up part of your journey.

There's a really good Summary of Changes document in the PCI SSC document library and lots of other great material on the PCI SSC website, including a new version of the Quick Reference Guide. This article also has a short summary of the most impactful changes. For a deeper dive, you can also check out my Pluralsight course PCI DSS v4: What's New.

Next is the (admittedly tedious) task of going through the standard, requirement-by-requirement, noting where you're not currently compliant and what you need to do to change that.

Two separate gap assessments are recommended because there are two PCI DSS 4.0 deadlines! The new version of the standard becomes mandatory on 1st April 2024, however most of the new requirements don't become mandatory until 1st April 2025 – these are the ones that the PCI SSC believes will require new technology or processes to be procured and implemented. These requirements are clearly indicated in the summary of changes. In the standard, look for these words in the Applicability section:

"This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment."

Your organization should first focus on the 51 new requirements that become mandatory in 2025, because any gaps here will likely require you to purchase or build new technological solutions. For most organizations, this means you will have to get approval in 2023 for the money you need to spend in 2024, to have new things implemented by 2025. In some organizations you'll also need this advance planning to have your changes approved by any enterprise change process.

Most of the 2024 changes are small, either in interpretation or they only require minor policy or process changes, so after the gap assessment, fill in the gaps you have identified. 

While you're doing this, keep a focus on planning and implementing any of the big technology changes you need for that 2025 deadline.

Have your first 4.0 assessment – you can choose to do this now, but after 31st March 2024, you have no choice but to assess against 4.0. 

Given the new requirements and assessors' unfamiliarity in assessing against the new version of the standard, be prepared for assessments to take longer than they may have done previously.

If you're planning to be "sneaky" and bring forward your annual assessment to before 1st April 2024 so you can still do a version 3.2.1 assessment, beware: If your assessment slips past the end of March, you'll have to start again and do a 4.0 assessment, and that won't be easy or cheap!

Hopefully, the budget for any new technology and change programs was approved, and now you can progress the projects needed to fill the identified gaps against the new requirements.

Because those 51 new requirements became mandatory in April 2025, your first assessment that includes these requirements won't be a simple repeat of the previous year. It would be a good idea to have a pre-assessment (most QSAs provide this service) in advance of the formal assessment to make sure you can fully meet the requirements.

Again, remember that this might be one of the first few times an assessor has performed an assessment of the new requirements, so be prepared for it to take longer, cost more, and require more involvement from your GRC and technology teams.

Before looking at what has changed in PCI DSS 4.0, some good news. PCI DSS 4.0 is an evolution to reflect changes in technology, payments and how criminals attack, not a revolution.

• It still has 12 principal requirements.

• Where the requirements apply to (the scope) is the same.

• You can still use compensating controls.

• Qualified Security Assessors (QSAs) and Internal Security Assessors (ISAs) still carry out assessments.

• Organizations still report their compliance either via an assessor-produced report on Compliance (RoC) or a Self-assessment Questionnaire (QSA).

There's no substitute for reading the standard and the summary of changes document. That said, these are the key changes you'll need to concentrate on that are effective 1st April 2024:

• Roles and responsibilities for performing PCI DSS requirements are defined. 

• Documentation of scope.

• Changes to networks should follow the same change control as everything else in scope.

• Files used to create network infrastructure (e.g. Terraform scripts) need to be secured. 

• Documentation of requirements that are shared between the organization and third-party service providers.

Of the 51 new requirements that become mandatory on 1st April 2025, these are the ones that may entail the most work.

Encryption

If you store encrypted data, then disk- or partition-level encryption isn't acceptable anymore.

Hashing

If you generate and store hashes of PANs, these now need to be cryptographically keyed hashes (e.g. HMAC)

Cryptographic inventory

An inventory of all cryptography used, whether that's to protect cardholder data at rest, or in transit. And then an annual risk-assessment of the use of all cryptography – we don't know how many years away the next version of DSS is, and so this requirement promotes crypto-agility in case a well-used algorithms looks like it will become less secure than previously thought – which may happen with the maturity of quantum computing.

Prevent and detect e-commerce skimming attacks

By actively managing all JavaScript included in payment web pages and responding to unauthorized changes. With many websites having around one hundred scripts on a page and half of these from third parties, these requirements may prove harder to meet than you might initially think. 

Phishing

Deploy technology to prevent and detect phishing attacks. Users need to receive training to help them identify and report phishing and other social engineering attacks.

System and application accounts

These have previously been ignored by PCI DSS, but historically have been a major cause of system compromises. Now they need to be managed, reviewed and secured. For some organizations these requirements will only be able to be met by the use of a privileged access management solution.

Multi-factor Authentication (MFA)

Now required for all users who access the CDE, not just for remote and administrative access.

Automated log reviews

Hopefully everyone is already doing this, but if your log review is still manual, it is time to buy a SEIM.

Authenticated internal vulnerability scanning

The quarterly internal vulnerability scans now need to be authenticated. This will be perhaps one of the hardest of the changes to an existing requirement to meet, and in large enterprises who don't already do this, be prepared for a twelve-month vulnerability management project to triage, and to remediate the new vulnerabilities that authenticated scanning will undoubtedly discover.

Inventory reviews

There's always been a requirement for hardware and software inventories to be maintained. Now you also need to risk assess any end-of-life assets in the inventory and have plans to secure and replace them.

Looking to learn more about PCI DSS? Pluralsight offers a PCI DSS learning path where you can start at your skill level (Beginner, Intermediate, or Advanced), covering everything you need to know to implement the PCI DSS in your organization.

Want to test your current knowledge of PCI DSS? Take a free skills assessment and see where you need to shore up the gaps.