Scoping Validation Requirements in PCI DSS 4.0: What’s Changed?

When the state lines of America were drawn, many different elements came into play.

Things like natural geographic boundaries—the Connecticut, Ohio, and Colorado Rivers, for example—and manmade ones, like railroad construction, played parts. Some states even drew their own borders—California and Texas—and Congress just accepted them.

The point is, every State is a different shape that was decided by different things unique to its landscape and circumstances. The same is true for your PCI DSS scope. And just like state lines are respected and recognized, your scope must be validated.

But those who solidified said state lines were mapping a country—you are trying to stay in compliance. The process of carving out your scope has always been involved enough, but now we have v4.0 of the PCI DSS standard, and it has brought with it changes in how your scope is validated.

Defining, documenting, and communicating the scope and applicability of PCI DSS requirements continues to be a critical component of a successful assessment. What would help is understanding how you must now change your approach.

As a PCI Qualified Security Assessor, Schellman has performed over 150 DSS assessments in the last 12 months under version 3.2.1. More recently, we’ve dissected the new 4.0 version to understand the differences. Now, we want to pass on what we’ve learned to you.

In this article, we’ll redefine what is considered in scope under PCI DSS v4.0 and the changes to validation from the previous version, including new requirements for such. When you “map” your scoping exercise for your next DSS assessment, you’ll know exactly what the scoping requirements are, paving for a smoother way forward.

Changes to Scope Validation Under PCI DSS v4.0

Under PCI DSS 3.2.1, it’s recommended that you confirm your scope at least annually and before the start of the annual assessment. To this point, it’s only been a recommendation that you complete this scoping exercise, and validation of the scope you define has been solely your assessor’s responsibility.

Until now.

There have been two big changes to scoping validation in PCI DSS v4.0:

• In PCI DSS 4.0, both the entity and the assessor now share the burden of validating scope.
• New Requirement 12.5 has formalized scoping reviews as part of your annual assessment. 

What is Considered In-Scope Under PCI DSS?

This is a big shift. And now that you will share a required responsibility to validate your scope, you should understand what it means under PCI DSS. We’ll address that first.

The cardholder data environment (CDE) is the primary focus of PCI DSS scope, and is defined as:

• System components; as well as
• People or processes that process, store, or transmit any element of cardholder data (CHD) and/or sensitive authentication data (SAD)—these two are collectively known as account data. 

So then, what is cardholder data? Reviewing the existing definitions, its elements include:

• Cardholder Name
• Expiration Date
• Primary Account Number (PAN): A unique identifier that identifies the issuer and the account of the cardholder. (Often also referred to as the account number.)
• Service Code: A three or four-digit value contained within the card’s magnetic stripe following the expiration date of the card on the track data. That has multiple uses including defining usage restrictions and service attributes. 

Then, sensitive authentication data elements include:

• Full track data (magnetic-stripe data or chip equivalent)
• Card verification code: A data element that may refer to either the magnetic stripe data or the printed security features on the card. Each payment card brand has its nomenclature and format for this value.
• PINs and/or PIN blocks: Associated with the cardholder’s personal identification number, which is used for authentication purposes at ATM or in conjunction with EMV chips to replace signatures. 

It’s a common misconception that the CDE represents the boundary of scope and that any people, processes, or systems not directly involved in the transmission, processing, or storage are excluded from PCI DSS requirements.

But an accurate scoping of your organization must extend to people, processes, and systems that could impact the security of the CDE (or that connect directly or indirectly to the CDE). This nuance in scoping must be a critical consideration for your successful PCI DSS assessment—one that persists in both version 3.2.1 and version 4.0.

Scoping Validation Requirements in PCI DSS v4.0

Nuanced scoping regarding accuracy may have carried over from the previous standard, but there is a change to how you document it under v4.0.

As we mentioned before, the new requirement 12.5. mandates the previously only recommended scope validation. You must confirm your scope annually and after any significant changes, and whether you do is subject to review as part of your assessment.

Your assessors will review your supplied documentation to verify you’ve done so, and the expectations for acceptable supporting documentation may include (but are not limited to):

• An accurate inventory of system components in scope for PCI DSS, including their function/use
• Identification of all data flows and updated data flow diagrams
• An inventory of all locations where account data is stored, processed, and transmitted to/from, including:
  • Locations outside the CDE
  • Applications involved in storage, processing, or transmission
  • All transmission channels between networks and systems
  • All file backups
• Identification of all segmentation controls
• Inventory of all third party connections which facilitate access to the CDE 

Your scoping validation exercise must also confirm that all data flows, account data, system components, segmentation controls, and connections from third parties with CDE access are included in scope.

If this seems extensive, it is. Therefore, if you’re already under assessment or considering compliance with PCI DSS 4.0, you should begin planning now for your annual scope validation exercise. Do two things:

• Determine which personnel should be involved and what actions will need to be taken to ensure your scope is accurate.
• Produce adequate evidence of the occurrence of these reviews to satisfy these updated requirements.

Scoping Validation for Service Providers Under PCI DSS v4.0

But PCI DSS can be particular for service providers, no matter the version, and the same is true regarding these new scoping validation requirements in v4.0. For those of you that fall into this category, you have additional obligations:

• Starting now, service providers are strongly recommended to conduct the scoping validation exercise every six months as a best practice.
  • After March 31, 2025, this recommendation becomes a requirement.
• Additionally, service providers who undergo any significant changes to the organizational structure are required to conduct a documented internal review of how those changes will impact your scope and controls applicability.
  • Examples of these types of structural changes cited in requirement 12.5.3 include mergers, acquisitions, or any major changes or reassignments of personnel with security control responsibilities.
  • The results of this review must be communicated to executive management.
  • Again, this will remain a recommended best practice until March 31, 2025, after which it will become a requirement. 

Additional Considerations with PCI DSS v4.0

Regardless of whether you’re a service provider or not, it will be critical to consider these new and changed requirements and the timelines for implementation as your organization begins planning the transition to PCI DSS v4.0.

America may have been mapped over decades, but you don’t have that much time to draw your scoping boundaries before these recommended practices become required.

So to ensure that you plot your course as accurately and easily as possible, read our other breakdowns on various aspects of the new PCI DSS v4.0:

• Factoring In the New Multi-Factor Authentication Requirements in PCI DSS 4.0
• Decrypting the New Cryptographic Requirements in PCI DSS v4.0
• How to Keep Legacy Systems Compliant Under PCI DSS v4.0

Of course, Schellman can assist with your compliance burdens if you’d rather speak more specifically on de-mystifying the timelines and expectations for your organization regarding the new standard. If that’s your preference, please reach out to us. We’re happy to set up a conversation so that we can answer any pressing questions you may have.