PCI DSS 4.0: Things to do by March 2024

If your organization takes credit, debit or charge cards as payment, then you need to prepare for the Payment Card Industry Data Security Standard version 4.0 (PCI DSS 4.0).

The deadline for compliance with 13 broad new requirements in the first phase of PCI DSS 4.0 is March 31, 2024. The implementation deadline for a second phase, comprising 51 requirements of a mostly more technical nature, follows a year later.

Complying with the first phase involves mostly planning, assessments and designation of responsibilities. But it might also be more than you've had to do to comply with previous versions of PCI DSS.

Here's how to prepare for Phase One of PCI DSS 4.0.

Get all your ducks in a row

You need to figure out exactly how PCI DSS 4.0 will affect your organization, and to plan accordingly. That can get complicated.

Step 1. Determine your merchant level and compliance responsibilities

Find which PCI DSS merchant level your organization falls into. There are four levels of merchants, generally grouped by how many transactions involving each payment-card brand an organization handles every year.

Each of the five major card brands defines the levels a little differently:

Level 1: More than 6 million transactions (Discover, MasterCard, Visa); 2.5 million or more transactions (American Express); 1 million or more transactions (JCB)

Level 2: Between one and 6 million transactions (Discover, MasterCard, Visa); between 50,000 and 2.5 million transactions (AmEx); fewer than one million transactions (JCB)

Level 3: Between 20,000 and 1 million e-commerce transactions (MasterCard, Visa); up to 1 million transactions of any sort (Discover); between 10,000 and 50,000 transactions (AmEx)

Level 4: Fewer than 20,000 e-commerce transactions and up to 1 million total transactions (MasterCard, Visa); fewer than 10,000 transactions (AmEx)

Discover uses only Levels 1 through 3, and JCB uses only Levels 1 and 2.

Being placed in a specific level by any issuer generally bumps the merchant up to that level with regard to other brands. Hence a retailer that handles 2.5 million American Express transactions would also be in Level 1 for MasterCard or Visa, regardless of how many transactions involved those brands' cards.

Merchants that have recently suffered data breaches or cardholder-data compromise may also be bumped into Level 1 regardless of transaction volume.

The compliance responsibilities for each level differ, but Level 1 organizations bear the heaviest burden. For all card brands, they must have yearly audits performed by PCI-certified external Qualified Security Assessors (QSAs) or in-house Internal Security Assessors (ISAs), and those audits must be concluded with an Attestation of Compliance (AOC) that verifies that all requirements have been met.

Penetration tests, approached from both inside and outside the company network, must be performed as part of the yearly audits or after "any significant infrastructure or application upgrade or change" (PCI DSS 4.0 requirement 11.4.2).

The annual pen tests do not need to be performed by a QSA or an ASV but can be done by any "qualified internal resource or qualified external third party" so long as the pen-testing group has "organizational independence" of the entity being tested.

Level 1 merchants must also have vulnerability scans performed quarterly by PCI-certified Approved Scanning Vendors (ASVs), of which there are fewer than 80 worldwide.

"The biggest thing is just understanding what your responsibilities are," said Elyse Hamilton, director of customer growth at Clone Systems, a managed security service provider and ASV in Philadelphia. "Do I need to do quarterly scans myself now? Can I rely on someone else to do it? Do I need to do extra testing?"

Compliance requirements are fuzzier for Levels 2, 3 and 4, as the five major card brands have slightly different rules, but merchants on these levels generally do not have to be audited. Instead, they can fill out Self-Assessment Questionnaires (SAQs) along with AOCs to document their compliance.

All card brands except JCB may require quarterly ASV scans for Levels 2 and 3, depending on the type of SAQ filled out. Level 4 American Express and MasterCard merchants may also be scanned quarterly depending on the type of SAQ, while Visa decides for individual merchants.

To be certain of what exactly your organization's compliance obligations are, contact the bank or other processor that settles your payment-card transactions.

Step 2. Determine the scope of your cardholder data environment

The "scope" of PCI-specific vulnerability scans, assessments and pen tests pertains only to an organization's cardholder data environment (CDE). The CDE is defined as any part of the network that processes, handles, stores or otherwise touches payment-card data, ranging from point-of-sale terminals and online-payment pages to data-center servers and cloud instances.

Determining the scope of exactly what must be scanned, probed, poked and tested to comply with PCI DSS 4.0 also satisfies requirement 12.5.2 of the Phase 1 implementation (see below).

Establishing exactly which parts of your network fall into or outside of the scope can be tricky. Do endpoints that connect to servers that store payment-card information count? What about cloud instances that may have been spun up and then forgotten?

"Scope is everything," said Norman Comstock, managing director at UHY Consulting in Houston. "Under PCI DSS 4.0, both the entity and the assessor share the burden of validating scope."

You may want to segment your network to properly isolate the CDE and/or bring in an external penetration tester to find potentially hidden connections. Such connections should subsequently be removed or isolated to narrow the PCI DSS scope and thus make compliance easier. Matt Phillips, Technology Advisor, Cyber Risk at McLean, Virginia-based consulting firm Guidehouse, recommended making sure that "those systems that are indirectly or not directly connected [to the known CDE] are part of the pen-testing program to validate and confirm that connections to the PCI environment are not in any way possible and the appropriate controls are in place."

Step 3. Assess how far you are from compliance

The next step is to perform a gap assessment, sometimes called a gap analysis, to see how far your organization has to go before it will be able to comply with either implementation phase of PCI DSS 4.0.

If your organization falls into Level 1 and must face a QSA/ISA audit, then to adequately prepare, you may need to perform a more thorough PCI DSS 4.0 readiness assessment that will analyze not just your CDE, but your entire organization.

"Once you understand the version 4.0 requirements, map them against your current security controls and analyze the impact the changes may have on your organization," wrote Lindsay Goodspeed, senior manager of corporate communications at the PCI Security Standards Council, in a recent blog post. "You might find that you already meet some of the v4.0 requirements, so you can prioritize your transition efforts where they are most needed."

Step 4. Bring in third parties to help if necessary

Unless you already have an in-house governance, risk and compliance (GRC) team, you'll probably need to call in external consultants to help with the transition to PCI DSS 4.0. Don't wait to pick up the phone, because there are only so many qualified consultants and they're going to be pretty busy.

"Any organization without specialists in designing, implementation, maintaining, and documenting security controls will need to ensure that they have access to such expertise within the next few months," said Gerald Beuchelt, CISO at Sprinklr, a customer-management-platform maker based in New York. "Given the market for cybersecurity talent, this can become a major difficulty."

If you use, or plan to use, a managed service provider (MSP) or a managed security service provider (MSSP) to oversee at least part of your CDE, then fair warning: Under PCI DSS rules, the MSP/MSSP counts as a Third-Party Service Provider (TPSP) and will need to be able to define its own roles and responsibilities with regard to your organization's CDE by the end of March 2024. (More on this below.)

Step 5: Prepare a budget and allocate other resources

Contracting all those assessors, pen testers and auditors will add up, so make sure you budget for the PCI DSS 4.0 transition accordingly and that the executive team in your organization is prepared for unforeseen expenses.

"Find the budget and allocate the funds, because it's important," said Jorja Solomon, senior growth manager at Clone Systems. "You need to invest before something happens, because there will be higher costs later down the line."

You may also need to pull IT and security team members off other projects for several months to prepare for the transition. Allocate your personnel assignments accordingly.

Changes to be implemented by March 2024

Once all that preparation has been completed — and remember, you have less than six months — then it's time to implement the requirements to comply with the first phase of PCI DSS 4.0.

All 13 of the new requirements concern compliance methods and responsibilities rather than technical details. This arrangement should give organizations a year to get used to the more stringent requirements and more clearly defined roles that will come with full implementation.

"[PCI] did it in that type of order because if they forced technical on [small businesses], they would have been lost Day One," said Tom Nianios, network security engineer at Clone Systems. "Whereas if they have time to educate themselves, learn about the standard, learn about their responsibilities and so forth, know the operational stuff first, then the technical stuff can follow after that, and it won't be a huge surprise."

1. Specify who does what

Ten of the 13 requirements (2.1.2, 3.1.2, 4.1.2, 5.1.2, 6.1.2, 7.1.2, 8.1.2, 9.1.2, 10.1.2 and 11.1.2) that must be met by March 31, 2024, have to do with identifying the "roles and responsibilities" of individuals on your organization's IT and/or security teams with regard to PCI DSS compliance and remediation of security incidents.

In other words, you must name person X as being in charge of aspect A of PCI compliance, person Y as being in charge of aspect B, and so on. This is being done to encourage the creation of a best-security-practices culture in your organization, if that doesn't already exist, in preparation for the full implementation of PCI DSS 4.0 in March 2025.

It also makes it easier for your teams to know who's going to do what when responding to an incident involving the CDE and cardholder data, and easier for a QSA, ISA or another auditor to quickly identify to whom to speak in the wake of such an incident.

"The standard formalizes many of the policies and procedures, roles and responsibilities, and other expectations an assessor will examine," said Comstock. "Having these documented by the entity bolsters that words can be actioned by named staff who know and operate those control requirements."

2. Specify what third parties handle

Another requirement, 12.9.2, mandates that third-party service providers (TPSPs) make clear which roles and responsibilities regarding a client's CDE will be handled by the client, and which by the TPSP.

A TPSP can be a payment processor or a customer-help-line provider, but as stated above, this rule also applies to MSPs and MSSPs.

TPSPs must also provide, upon client request, information about the status of their own PCI DSS compliance. TPSPs that haven't undergone QSA audits of their own can still meet the requirements of their clients' auditors by proving that individual requirements were met, or by undergoing assessments by client auditors.

3. Define CDE and scope

We've discussed this above, but requirement 12.5.2 mandates that organizations define their CDEs and their PCI DSS scope a year before the rest of PCI DSS 4.0 goes into effect.

4. Define customized approaches and perform targeted risk analyses

PCI DSS 4.0 introduces a new option for compliance, a "customized approach," that lets organizations fulfill some individual requirements in ways that may stray from the standard path but still meet the desired result.

This is useful for organizations that must comply with regulatory frameworks besides PCI DSS, such as HIPAA or GDPR, as the organizations can "mix and match" requirements from other frameworks as long as the same result is achieved. It also lets organizations with complicated internal environments meet PCI DSS 4.0 requirements without having to restructure their systems.

The catch is that each customized control must be approved by an ISA or QSA, even for Level 2 through 4 merchants who might otherwise have avoided audits by filling out a SAQ.

As the full PCI DSS 4.0 specification states bluntly, "Entities that complete a Self-Assessment Questionnaire are not eligible to use a customized approach."

Requirement 12.3.2 gets a jump on the customized-approach verification process. It compels organizations planning to use customized approaches to define and perform targeted risk analyses on those approaches as part of Phase 1 of implementation, even if those approaches won't be used until March 31, 2025. Each customized approach must also be tested as part of the risk analysis and documentation.

The documentation and risk analyses for each customized control must be performed yearly, and the results provided to the QSA or ISA.

Checklist for March 31, 2024