PCI DSS Version 4.0: Managing Your Scope for “Significant Change”

This blog was originally published by PKWARE here.

Written by Marc Punzirudu, Field CTO, PKWARE.

After a few delays, PCI DSS version 4.0 was finally announced publicly on March 31, 2022. While entities may still use PCI DSS v3.2.1 until its retirement date on March 31, 2024, there are some notable changes that should be given consideration in advance.

Since the initial evolution of PCI DSS version 2.0 back in 2010, the council has maintained the theme “Business As Usual.” This is the notion that compliance—and your security program— are continual, and not a point in time. The new standard has doubled down on that approach, implementing a number of controls that require documentation of responsible parties, as well as periodic check points to ensure that the controls are in place and functioning as intended.

It has always been a requirement for an entity to validate their scope prior to performing a PCI DSS assessment; however, because it was not a control that received a firm In-Place or Not-in-Place response, this was often the most conflicted and neglected part of implementing a compliance program for many organizations. In version 4.0, the PCI SSC has attempted to remedy that by adding some new controls to the PCI DSS. We will look at two important controls and walk through their impact on entities being assessed or otherwise having to comply with the PCI DSS.

One New Thing: Defining the “Significant Change”

Requirement 12.5.2: PCI DSS scope is documented and confirmed by the entity at least once every 12 months and upon significant change to the in-scope environment. At a minimum, the scoping validation includes:

• Updating all data-flow diagrams per Requirement 1.2.4.
• Identifying all locations where account data is stored, processed, and transmitted, including but not limited to: 0. any locations outside of the currently defined CDE, 1. applications that process CHD, 2. transmissions between systems and networks, and 3. file backups.
• Identifying all system components in the CDE, connected to the CDE, or that could impact security of the CDE.
• Identifying all segmentation controls in use and the environment(s) from which the CDE is segmented, including justification for environments being out of scope.
• Identifying all connections from third-party entities with access to the CDE.
• Confirming that all identified data flows, account data, system components, segmentation controls, and connections from third parties with access to the CDE are included in scope.

To pull this requirement apart and reference the guidance and objectives written in the PCI DSS version 4.0, all entities must review their PCI DSS scope and document it at least annually, as well as upon significant change.

What constitutes a significant change? In past versions, this has been rather ambiguous and left up to interpretation. But PCI DSS version 4.0 has done us the favor by better defining this term. While what constitutes a “significant change” is highly dependent on the scope, there are some minimum items that are now included, such as:

• Adding hardware, software, or network equipment
• Replacement or major upgrades of hardware or software
• Changes to data flows or storage of account data
• Changes to the documented scope or boundaries of the in-scope environment
• Changes to support or security mechanisms such as logging, authentication, etc.
• Changes to service providers who are providing in-scope support or impact/manage requirements on behalf of the organization

From this list, it’s easy to see that significant change happens all the time. In the past, organizations would simply tell their assessor, “We haven’t had any significant changes,” or toss in an example of an entire cloud migration. The PCI SSC has made it clear that significant changes are far more common in organizations and need to be treated as such. This makes the scope review process extraordinarily difficult to do at any scale. In smaller organizations, the resources and investments in technology are not typically there to meaningfully perform these tasks. In a moderately complex environment, perhaps they are; however, the organization changes too rapidly to perform these activities at scale.

Additionally, requirement 12.5.2.1 then stipulates that service providers must perform scope confirmation at least every six months no later than March 31, 2025. Requirement 12.5.3 adds an additional burden to service providers to ensure that when a significant change occurs to their environment, a documented scope impact analysis must be performed and shared with executive management. These changes are laser-focused on the entities providing services or support to a merchant, and are directly in alignment with the results of breach investigations, since the supply chain has become a very high priority target for criminals.

Managing This New Requirement is Critical

How would an organization manage this today? The use of scripts and manual effort is cumbersome, expensive, and inaccurate. An organization could only take this approach if it had a well-defined environment, a singular type of database, operating system, and very few (if any) business applications. They’d also need to be at least somewhat sure of where all their cardholder data lives. The reality is that very few businesses have an environment that is so simple and straightforward.

Data sprawl is real, especially over the last two years: IT infrastructure has become reliant on the cloud and/or internet due to users being highly decentralized. The number of applications used to simply enable the business has increased exponentially. A quick review of a database just isn’t enough to ensure the scope is accurate and data has been inventoried. What organizations have a critical need for right now is an automated scanning and protection platform that will maintain an accurate scope.