Skip to content ↓ | Skip to navigation ↓

The Payment Card Industry Data Security Standard (PCI DSS) is a benchmark with tenure in the industry, with the first version being introduced in 2004. The PCI DSS was unique when it was introduced because of its prescriptive nature and its focus on protecting cardholder data. Cybersecurity is a changing landscape, and prescriptive standards must be updated to address those changes. The most recent update to the PCI DSS was in 2018, and the world has certainly changed since then.

The new version, 4.0, doesn’t immediately come into effect for all organizations. The PCI Council sets full compliance out to 2025, labeling them as best practices until then. As stated on the PCI website:

“In addition to an 18-month period when v3.2.1 and v4.0 will both be active, there will be an extra period of time defined for phasing in new requirements that are identified as “future-dated” in v4.0.”

PCI DSS v4.0 Transistion Timeline

While this transition period provides organizations with time to adapt to new requirements, it also leaves room for greater risk through that transition period. Determining the appropriate implementation time frame for new compliance requirements is a balancing act that simply can’t make every stakeholder happy. Of course, in a perfect world, it would be ideal if most organizations moved to the best practices before they’re required. What does that entail exactly, and is it easily achieved, or does that 18-month window indicate a foreboding of some difficulties in implementation?

Lead with Optimism

I am optimistic that most organizations can meet, or outpace the deadline, primarily due to the fact that many of the updates are focused on redefining a lot of the individual requirement sections. Instead of dictating a specific technical requirement, they generalized a lot of the requirements and the specific details within them to talk about ongoing operational security or compliance business processes, rather than a specific event in time to meet a technical criterion.

Most noticeable is that the PCI Security Standards Council does not want PCI compliance to be something that is performed once per year. They want it to be part of the ongoing day-to-day operations for both operational processes, as well as security processes. The word that pops off the page for most of the updates is “clarification.”  The main clarification is that PCI compliance should not be an annual task. Rather, it should be a continuous practice with the goal of reduced business risk and increased security for your environment.

Expanded Configuration Management

Any additional emphasis on securely configuring systems is a welcome addition to cybersecurity best practices. While the previous version of the PCI DSS addressed secure configuration, it unfortunately focused more specifically on single topics, such as changing vendor-supplied default passwords. Secure configuration management goes well beyond vendor-supplied passwords, and it’s great to see the updated version of the standard take a more expansive approach to the requirement.

The object is no longer to be compliant only for an audit. If you want to be compliant with the new standard, you need to check your compliance routinely. The update is aiming towards significant guidance on what an organization’s business processes should be, not what their technical configurations are. That’s really the big change. It’s more of an ethos, a thought process, an idea that every time a new business process is created, it must be done so with the mindset of “how does this make us more secure and more compliant with our PCI standards?”

Is an Organizational Transformation Required?

For many organizations, the audit scramble is a reality, but with the constant threats, this is no longer an acceptable security approach. The new standard will force many companies to take a new approach, moving away from compartmentalized security. Too often, a department would have specific technical controls for which they were responsible. However, that will no longer be acceptable. From a customer impact perspective, they’re going to look at this as a need for either centralizing the idea of compliance and security within the organization. So, if they don’t already have a GRC team, they might need to think about forming one. If they don’t look at operational processes as part of their security and compliance state, they will want to think about that.

Will the Audit Process Change as a Result of PCI 4.0?

An audit usually represents a point-in-time snapshot of an organization’s compliance state. Typically, the process consisted of seeking justification to prove a particular system met the standard. This was often achieved with a random sample of the devices and systems that were in scope.

Much of the evidence gathering will probably remain the same. The change will take place in how an organization can prove how a process is in compliance. The data collection method will play a key role in this. I anticipate that there will probably be more emphasis from the auditors on identifying the business processes based on the additional requirements in PCI 4.0.

Organizations should expect that if they do not have clear written, documented, approved, dated, history tracked, business process documents defining how they go about their compliance, they are going to find that their audits become more strenuous and difficult to pass.

Cardholder Data has been upgraded to Account Data

Another interesting change in the wording in the new standard is that information is no longer referred to as “cardholder data.” This has been changed to “account data.” While this may seem trivial, there is a difference between cardholder and account data. Account data is a very generalized term. This has broader implications for an organization. For example, data that is stripped of card number information is still subject to the new standard. It is no longer acceptable to store this stripped data without the same protections as the full data set. This could increase the scope of most PCI audits.

Adding Zero Trust into the Standard

Zero Trust Architecture has grown in adoption since the previous version of the PCI DSS was released in 2018. The latest version of the standard makes room for Zero Trust approaches to authentication and authorization with allowances for a “dynamically analyzed” security posture. This can serve as a mechanism for providing “real-time access to resources” as an alternative to rotating passwords. Keeping up to date with best practices in cybersecurity is important in order to avoid organizations downgrading security to maintain compliance.

How Tripwire Can Help

Like most of the security industry, the PCI Security Standards Council is following the approach that compliance is something that must be proven every day–this is an attainable goal. Products such as Tripwire Enterprise, as well as File Integrity Monitoring can help your organization to meet the PCI 4.0 standard well before the deadline. Whether your needs are to comply with Requirement 11 using FIM, or to expand configuration monitoring throughout your environment, Tripwire can help.

Interested in getting more out of your PCI compliance efforts? Learn how to use the transition to PCI 4.0 as leverage to maximize the security value of your compliance budget.

Join us to learn about the five key changes in the recent PCI 4.0 update that can help your organization leverage compliance to become more secure, and learn how Tripwire can help you minimize the work associated with PCI audits.

Register today:

Read more about PCI 4.0 requirements

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