What Service Providers Should Know About the Updates in PCI DSS v4.0

When Princess Leia sent R2-D2 to deliver a message to Obi-Wan Kenobi during Star Wars Episode IV: A New Hope, she changed the course of the Rebellion against the Evil Empire in one of science fiction’s most iconic films.

Still, one could argue that the life she changed the most was Luke Skywalker’s—after all, he was stuck on a desolate sand planet, dreaming of a better life, only to eventually reunite with his twin sister and save the entire galaxy from pervasive evil.

When it comes to life-affecting change, the new version of PCI DSS is going to impact us all. The Payment Card Industry Security and Standards Council (PCI SSC) is our Princess Leia, and they’ve just redirected the course of payment card security rather than a fictional rebellion.

But just like Luke’s life was debatably the most changed, PCI DSS v4.0 arguably affects service providers the most.

In the film, Luke had a guide—Obi-wan Kenobi—to help him deal with his evolution. As a PCI QSA, we at Schellman want to do the same for those of you trying to wrap your heads around such an enormous shift in a flagship standard.

We have lots of content coming addressing different aspects of PCI DSS v4.0, but in this article, we are going to focus on the major impacts to service providers. While it won’t be an exhaustive list of all changes, what we’ll highlight has the potential to significantly impact security operations, budgets, and infrastructure.

Like the whole of PCI DSS 4.0, most of the major changes are future dated to give everyone sufficient time to plan and implement the required changes, but the following will provide you a high-level list to work from and plan for so that you’re better prepared for when the changes do become permanent.

9 Key Changes Affecting Service Providers in PCI DSS v4.0

1.      Requirement 3.5.1.2

Effective 03/31/2025: Disk-level encryption (commonly referred to as Full Disk Encryption or FDE) will no longer be an acceptable control for the protection of the primary account number (PAN).

Given how we all know how little protection full disk encryption provides, this is a positive step in the right direction. FDE will still be required for removable media, but by design, it only protects against theft of the physical media where the data is stored.

That’s all well and good, but the greater risk is remote access into a system that is powered on, and you will now need to implement controls for that as well. As such, there may be financial impacts to implement acceptable encryption methods—software purchase, personnel to configure—and key management processes.

2.      Requirement 8.4.2

Effective 03/31/2025: Now, multi-factor authentication (MFA) will be required for all access to the cardholder data environment (CDE).

Before, only remote access into the CDE required MFA so this is a significant change from PCI DSS v3.2.1. For more clarification, the council also provided guidance on what constitutes MFA—e.g., using a single factor twice is now called out as not acceptable MFA.

Accommodating this change will likely impact your budget for MFA licensing and training hours for employees who may not be familiar with MFA, so make sure you plan accordingly.

3.      Requirement 8.6.3

Effective 03/31/2025: Application and system account passwords must be changed periodically based on the entity’s risk assessment (Req 12.3.1).

In the past, there was no clear requirement to rotate application and system account passwords (service accounts) due to the potential impact to business operations.

Now, the council has left the frequency of the credential rotations up to you with the caveat that these accounts must be included in the internal risk assessment. Planning and implementation will be critical to ensure interruptions to your business are kept to a minimum.

4.      Requirement 10.4.1.1

Effective 03/31/2025: Automated mechanisms for log reviews are now required.

In short, a security information and event management (SIEM) must be implemented. In our experience, most organizations already are using a SIEM for log aggregation and review, but there may be others that have not gone this far with log reviews.

For those of you who have not already gone this route, this requirement will have major financial impacts including the cost of the SIEM and data storage fees. It’ll also require more time investment from personnel to transition over and configure the SIEM and related alerts.

5.      Requirement 11.3.1.2

Effective 03/31/2025: Internal vulnerability scans must be performed using authentication credentials.

As of that effective date, unauthenticated scans for internal scans will no longer meet the requirement. But at Schellman, we like this move. Running authenticated scans that require credentialed account access gives you a much better view of the status of internal systems—there’s more insight into things like patch levels, missing patches, insecure protocols, running services, etc.

However, this change will impact your account management as those accounts will need elevated privileges and must be managed in accordance with requirement 8.2.2. You may also see some additional costs associated with using authenticated scanning tools as opposed to traditional unauthenticated scans.

6.      Requirement 11.4.7

Effective 03/31/2025: Third-party service providers (TPSP) must support customer Penetration Testing activities.

Other than adding a new acronym of TPSP, this could prompt major shifts in protocol for hosting providers and other third parties.

Why? To this point, many TPSPs have not allowed their systems to be included in a client-initiated PEN test, as the risk to other clients was not acceptable. But as of the effective date, if you are a TPSP, you must either provide access to the systems for testing or provide evidence that comparable testing has been performed.

7.      Requirement 12.5.2.1

Effective 03/31/2025): Service provider scope validation must be conducted every 6 months and after any significant changes.

You probably remember that this stipulation was only annually in PCI 3.2.1.

But this change ties in with the new requirement 12.5.3, which requires entities to formally document what constitutes a significant change. Results of these changes must be reviewed internally, any issues must be addressed, and it all must be communicated to executive management.

8.      Appendix A.1

Effective 03/31/2025: Changed the verbiage and added clarification concerning what constitutes shared hosting providers.

The council added some important language in the Appendix—shared hosting providers are now referred to as multi-tenant service providers. In PCI 3.2.1, the previously ambiguous language let many cloud providers off the hook for assessment against these requirements.

But with the release of 4.0, almost all cloud hosting providers must now address the requirements in this appendix.

9.      Requirements 2 through 11

Effective immediately with PCI-DSS 4.0: Assessed entities must have roles and responsibilities documented, assigned, and understood (communicated).

A new set of sub-requirements, these mandate the creation of either a separate responsibility document or the inclusion of such information within an established policy.

As a suggestion, a RACI matrix would be a good approach here. But for larger organizations—like contact centers, multi-tenant data centers, and cloud hosting providers—maintaining this list be more challenging, especially if there are international or multiple divisions where roles and responsibilities may or may not be standardized.

It’s a good idea to start planning out how you want to tackle these requirements so you’re not caught off guard upon an assessment and accidentally leave something out.

Next Steps for PCI DSS 4.0

Deconstructing this new version of PCI DSS will take a while. For service providers, you face some serious changes that you’ll need to adjust to, but now, you at least have a starting list of things you know to address.

As the Obi-Wan to your Luke Skywalker, we would encourage you to begin planning for these changes right away, especially if you’re anticipating budgetary and staffing considerations. As you do that, make sure you read our other content—coming over the next several weeks—on PCI DSS 4.0 to ensure you’re as prepared as possible for your transition:

• 7 New Requirements in PCI DSS v4.0 to Plan For
• How to Define Time in PCI DSS v4.0
• Decrypting Cryptographic Requirements in PCI DSS v4.0
  
  

But if you find that you already have organizationally specific questions regarding this new standard, please also feel free to reach out to pci@schellman.com or through our contact us page. We are happy to set up a call to speak more about your concerns regarding PCI DSS 4.0.