Skip to content ↓ | Skip to navigation ↓

The new PCI DSS Standard, version 4.0, contains all the steps, best practices, and explanations required for full compliance.  In fact, even an organization that does not process cardholder data could follow the PCI Standard to implement a robust cybersecurity program for any of its important data.

In our series about how the new standard differs from the previous version, we examined some of the most important changes, including some nuanced differences, such as the subtle linguistic modifications that have a broad impact.  As the concluding part of the series, we continue to look at the wider meanings of the new standard.

Glancing Towards Zero Trust

The new standard does not mention zero trust architecture specifically, but it is evident that the Security Standards Council is seeing that as a future consideration. When we look at the changes in how PCI has evolved over the years up to PCI v4.0, we can identify a trend: a departure from specific technical requirements and toward the general concept of overall security. By not defining exactly what “secure” is, leaves us in what appears to be an intentionally orchestrated state of ambiguity. For example, in the new version they really break down facets such as the software side, where, instead of focusing on software security, they now talk about the component-level architecture.

The Council homed in on some important updates about authenticating and authorizing user and system access between different components in an entire solution. It is difficult to deny that this is trending towards this zero-trust topic. That’s been such a prominent focus for the entire cybersecurity industry, at least for the last year, and the Security Standards Council is laying the groundwork for the future of PCI compliance.

A lot of the activity in the marketplace is defining zero trust as the hyper secure future state that we all need to aspire to. It appears this played heavily on the minds of those that wrote the specific updates for PCI v4.0. So, the new standard is not dictating a zero trust architecture or strategy within the environment, but it’s certainly trending in that direction. Even though the idea of zero trust has been around for a much longer time, the popularity of zero trust has really risen to the top of mind in recent years. It fits perfectly, as the practice of multi-factor authentication is much more commonplace now, so the evolutionary arc of building on that higher level of security is perhaps ready to be embraced. 

If an organization was looking to extract the most value out of any effort that they have to put forth to acquire new software, or to re-architect their environment, or their network structure; if they have to put new controls in place to segregate data and access to that data, it would be very important for an organization to think long and hard about what their own goals are.  This is especially true if they were going to aspire towards a zero trust architecture. This is an opportunity to advance those efforts. Of course, it’s still quite a bit of work, but if an organization starts planning for that now, they can work towards being compliant for PCI v4.0 by March of 2024. And to further the efforts, they can be compliant with all of the evolving standards prior to the March 2025 deadline. And maybe they can have that zero trust implementation a year or two after that.

Supervision of Your Disposition

Security Configuration Management is named very clearly in the new standard. This has graduated beyond the requirement of changing default passwords on all accounts. Now, the more general approach is that secure configurations must be used, and managed. Secure configuration is fairly easy, but ensuring consistent enforcement is a very difficult task when the potential change in scope is taken into consideration.  It’s simply not possible for a person to sit down and track all of those specific configurations with the detail needed for a good compliance and security program. This will no longer be possible using an old spreadsheet program, or even a zestless database program that is incapable of rapidly detecting configuration drift. A strong SCM program is going to be very useful within the organization to manage this update to the standard.

Where the Value Resides

The general idea in terms of getting the most value out of PCI v4.0 is advocating for a particular team of people to focus on security and compliance, operationally, and ongoing.  The only way to realize the benefits of a good program is by having a team to define those roles and responsibilities, and to review everything. People and processes are where the value is created and maintained. 

A lot of the requirements that are updated in PCI v4.0 directly imply having a group of people that are able to review different security standards, and create the justification for why an organization has chosen those. With v4.0 being less specific on the actual technical requirements, the thought process is about how an organization should be looking at compliance and security.  The aim is for an organization to follow the best practices and do all the right things, even as those standards change over the coming years. Although it does so tacitly, it really highlights the need for an organization to have a group of people—existing employees, new hires, whatever their particular structure is—if they want to get the most value out of their compliance efforts for PCI v4.0. If they want to achieve the best result for both compliance and security, it will be important for an organization to make sure that they have that set of responsibilities defined and that they have a group of people that actually look at this on an ongoing basis.

This is particularly true because it is no longer sufficient to be compliant only once per year, scramble in the two weeks leading up to an audit, and then forget about it for another 11 months.  That is an artifact of the past—not something that organizations can continue to do and expect to have good results within the constantly changing threat landscape.

Cognitive Behavioral Compliance

The PCI Security Standards Council has generalized as much as they can in the new standard.  PCI DSS v4.0 leans more towards about inculcating the right kinds of behaviors, rather than these specific requirements that need to be met in order to be secure these days. While there are many technical means to achieve these ends, the importance of having a team of people that can marshal an organization’s entire security terrain is what will dictate success. Here’s wishing everyone well in this endeavor.

Read more about PCI 4.0 requirements

PCI DSS 4.0 is Here: What you Need to Consider

What you need to know about PCI 4.0: Requirements 1, 2, 3 and 4.

What you need to know about PCI 4.0: Requirements 5, 6, 7, 8 and 9

What you need to know about PCI 4.0: Requirements 10, 11 and 12

To learn more about PCI DSS v4.0, follow the five steps in this executive guide to ensure you are leading your organization down the correct path for complete PCI v4.0 adherence in the necessary timeframe. Using this checklist will help you avoid audit fines and keep your organization’s name out of data breach headlines at the same time.

Click here to learn more: