The unique challenge of upgrading to PCI DSS v4.0

On March 31st, 2024, the Payment Card Industry Data Security Standard—commonly known as PCI DSS—is officially sunsetting v3.2.1 in favor of a more robust standard v4.0 (Security standards council's timeline here). Similar to v3.2.1, PCI DSS v4.0 is a set of security requirements and recommendations to ensure that organizations handle PANs (Primary Account Numbers, a.k.a. credit card numbers) responsibly so that they aren’t at major risk of a breach.

Presently, PCI DSS v4.0—which was announced in 2022—is the “most recommended” standard. However, this March, it will become the only accepted standard (except a few requirements that will be enforced in the subsequent year). The change affects SaaS applications, e-commerce websites, and marketplaces—anyone who processes online payments. Otherwise, those organizations are at risk of hefty fines should they want to continue to accept credit cards.

The transition between PCI DSS v3.2.1 and PCI DSS v4.0 is particularly unique; the new v4.0 standard changes some of the prescriptive requirements of v3.2.1 in favor of a more goal-oriented approach. This isn’t to say that v3.2.1 was a stricter standard; v4.0 still mandates a more robust security outcome. v4.0 is simply more flexible.

Regardless, taking a custom approach is an expensive process that’s suitable for organizations with niche security needs. Most organizations will still stick to v4.0’s explicit instructions, especially if migrating from v3.2.1. This doesn’t mean, however, that they aren’t able to re-evaluate some of their security decisions.

Today, we’ll discuss two strategies for upgrading PCI DSS compliance—the (i) lift-and-shift approach and a (ii) ground-up re-evaluation.

Two Quasi-Competing Goals

Before discussing the best strategy on upgrading PCI DSS compliance, it’s important to recognize that there are two goals, sometimes at odds with one another. The first is efficiently reaching compliance, with minimum engineering work. This could be summarized as decreasing PCI DSS compliance costs. The second is achieving an optimally secure system that doesn’t skimp on PCI DSS v4.0’s goals. This could be condensed to improving the effectiveness of security.

In most problems, a reduction in costs translates to a reduction in quality. Here, that is only partially true. Sometimes, by decreasing costs, organizations can improve the overall effectiveness of their security program. This is specifically possible whenever PCI DSS’s scope is reduced due to changes with how PANs are processed. Granted, this often involves more short-term costs with a dramatic long-term payoff.

“Reducing scope” is a phrase you’ll see throughout this guide. It’s often the most efficient way to economically improve security.

The Two “Ideal” SAQs

PCI DSS has various SAQs—security assessment questionnaires—where the applicable questionnaire is dependent on how PANs are handled. The most stringent SAQ, where over 500 controls are considered, is SAQ D—primarily applicable to organizations that store PANs on their own resources.

The most ideal SAQ is SAQ A, followed by SAQ A-EP. In comparison to SAQ D, SAQ A involves only a simple 29 controls in PCI DSS v4.0. That is because SAQ A applies to organizations that use PCI DSS compliant processors—like Stripe or Evervault—to handle PANs for them, only instructing processors who can and cannot see the data.

SAQ A-EP, meanwhile, applies to organizations that partially touch PANs albeit not storing them. An example of this would be a frontend interface that collects PANs in the same frame (e.g. no iframe’d form), where a nefarious Javascript snippet could silently steal the numbers. SAQ A-EP specifically adds 169 additional controls, spanning almost everything in the full standard outside of things like cardholder data storage.

When migrating from v3.2.1 to v4.0, organizations have the chance of changing the SAQ they qualify for (a process known as descoping). If an organization on SAQ A-EP or stricter can descope to SAQ A, PCI DSS maintenance will be dramatically easier long-term (incurring far less costs).

The Traditional Lift-and-Shift Approach

Typically when organizations are looking to migrate to a refreshed compliance standard, they adopt a lift-and-shift approach. Lift-and-shift minimizes changes by just tweaking security practices to abide by the standard, with no interest in building the best possible system.

Lift-and-shift may or may not involve less work than a ground-up reevaluation—if organizations aren’t able to effectively descope to a more relaxed SAQ, the new restrictions imposed by the corollary v4.0 SAQ may be more taxing. However, if an organization is close to achieving re-certification by remaining within their existing SAQ, a lift-and-shift approach may be ideal.

A lift-and-shift approach has a detailed process to ensure effective abidance with the upgraded standard. The first step is ensuring which SAQ / scope they are operating within. Then, developers need to identify gaps between their current system and the required system. Once these gaps are identified, developers can determine to eliminate them, address them accordingly, and submit a revised system for a PCI DSS audit.

Lift and shift approach to PCI DSS v.4 migration

It is a bit of an open secret that different PCI DSS auditors apply different strengths of rigor when evaluating compliance. This, obviously, isn’t ideal as PCI DSS’s goal is to standardize security, but the decentralized nature of PCI DSS auditing gives way for inconsistent reviews. Regardless, the goal of any organization should be to robustly abide by PCI DSS, not skimping out on the requirements. Otherwise, they leave their customers vulnerable.

The Argument for a Strategic Re-evaluation

One of the core acronyms in PCI DSS’s standard is CDE—cardholder data environment. If organizations can scope down their CDE, they minimize the resources relevant to their audit. Even better, if they can scope down their CDE to the point where they aren’t even handling credit card data, they can reach SAQ A.

Timeline for ground up re-evaluation

Some, including a few on the PCI team, have argued that the recent obsession of scoping down PCI’s scope is a net negative for the company’s overall security. That criticism is valid if the company is disinterested in practicing good security altogether, and is only implementing practices to achieve compliance. Thankfully, this isn’t the case for many companies, and a reduction in scope still improves net security.

Additionally, that criticism is a matter of a company’s potential internal attitude. But descoping, by itself, is a good thing. It means that if a company’s internal data is compromised, the PAN numbers aren’t at risk because they are tokenized / encrypted. It’s the same reason for why they become eligible for the SAQ A control set (and, by the same leaf, why the SAQ A control set is so relaxed). It’s not a loophole—it’s a realization of the benefit of decreasing exposure.

How to descope data

The most common descoping practice is altering how PANs (Primary Account Numbers) are handled and stored. Notably, by switching from an in-house method to a third-party encryption service, organizations could descope by making it impossible for their code to directly touch PANs, including any front-end code.

PANs should always be encrypted with touching servers

Often, companies shied away from processor-specific embedded products (like Stripe elements) because it made it difficult for them to share those PANs with other payment processors for regions where a competitor’s rate was more advantageous. However, today’s encryption products make it possible for companies to collect information and share it with third-parties without ever touching the PANs. An Encryption Proxy, like Evervault’s Relay is managed by a PCI audited service provider, guarantees the recipient of the PAN is the intended recipient only.

Of course, even when using a relay service, a tokenized reference to the data is still stored on the company’s servers. However, if the encrypted data and decryption keys are not in the same environment, the encrypted data is considered out of scope!

Not only does re-factoring how PANs are treated alter the applicable SAQ, but it also dramatically reduces long-term maintenance costs. Future PCI audits will be easier to prepare for and the amount of security considerations of data processing is dramatically reduced.

Conclusion

The path to PCI DSS v4.0 compliance doesn't have a one-size-fits-all solution. A lift-and-shift might suffice for organizations with custom security measures that they want to continue to maintain. But for many, the transition to v4.0 offers a timely juncture to enhance security posture while simultaneously reducing their overall data risk exposure. Notably, external encryption can dramatically reduce PCI scope.

Before you decide, it is important to consider your organization’s specific needs, risk profile, current security infrastructure, and long-term compliance objectives. And whichever route is chosen, it’s crucial to recognize that the goal is not just compliance but the responsible handling of cardholder data.

For organizations deliberating this crucial decision, Evervault offers comprehensive consultations to explore the best course of action tailored to their needs. We’ve ramped up our bandwidth to accommodate these as PCI DSS v4.0 is on the horizon.