PCI DSS v4.0.1 – FAQ on Compliance

With all future-dated requirements under the Payment Card Industry Data Security Standard version 4.0.1 (PCI DSS v4.0.1) now effective, organizations are entering a new stage of comprehensive compliance. The focus shifts from preparation to execution, assessing every control and process so it aligns with the full intent of the standard. Our PCI team answers some of the most frequently asked questions about PCI DSS v4.0.1.

What changes should an organization already have in place?

Definition of system components

In PCI DSS v4.0 the definition was expanded to include some system components that had not previously been included within scope. Newly considered systems include software deployment and configuration management tools such as:

• Source code repositories
• Continuous integration and continuous deployment pipeline tools
• Infrastructure-as-code tools

While some companies might not have these types of technology in place currently, the systems are worth noting in case these technologies are used in the future. Also, applicable requirements have expanded for tools already in scope, including anti-malware tools, logging and security information and event management tools, and authentication and authorization tools.

Management’s scoping exercise

The annual confirmation of the PCI scope must be performed independently by the assessed entity itself, separately from any scoping evaluation performed by the assessor. The scope from both the entity and the assessor should align, and any differences must be specifically noted in Section 3.1 of the report on compliance (ROC) executive summary. This is a separate requirement from simply maintaining an inventory of in-scope systems.

Elements of the requirement are:

• Identify all data flows involving cardholder data.
• Maintain and update data flow diagrams.
• Identify all locations where account data is stored, processed, and transmitted.
• Identify all system components that:
  • Are within the cardholder data environment (CDE)
  • Are connected to the CDE
  • Can affect the security of the CDE
• Identify all segmentation controls, if applicable, including which networks are in scope and which are out of scope.
• Identify third-party connections to the CDE.

This requirement is meant to emphasize a proactive approach for ongoing internal PCI focus.

How should an organization approach scope?

Performing a comprehensive scoping exercise can be a significant effort, depending on the size of the organization. It’s important to define a consistent and repeatable methodology to complete that scoping.

What strategies can be used to identify scope?

While numerous publications cover determining scope, guidance on performing a scoping exercise is limited. Some actions to take in identifying the initial scope include:

• Surveying employees to detect where cardholder data enters the organization, where it is stored, and where it leaves
• Using data discovery tools to detect instances of cardholder data
• Evaluating inventories of existing systems
• Assessing network and segmentation diagrams to identify key network segments, including ingress and egress points
• Evaluating existing vendor management processes to identify vendors that might receive cardholder data and those that can affect the security of the organization

How should diagrams be approached as part of scoping?

A variety of data flow and network diagrams are required under PCI standards, including:

• A data flow diagram that shows the flow of account data across in-scope systems
• A network diagram that shows all CDE-related connections and highlights network security controls in place
• A business process diagram that can highlight people-centric processes where cardholder data is handled by specific business areas and can be integrated into data flow diagrams

To determine the relevant data to capture for each of these diagrams, organizations can start by identifying:

• Business processes and data flows involving cardholder data – both electronic and physical
• Applications associated with business processes and downstream storage, processing, and transmission
• Underlying application infrastructure
• Security services and other functions provided to the in-scope systems
• End-user computing devices involved in transmission of cardholder data or administration of in-scope systems
• Network segments that contain in- and out-of-scope components as well as associated network components
• Physical locations
• Third parties involved at all points

What else should be considered when scoping?

While no single approach will be applicable for every organization, it’s important to evaluate the current scope and establish processes to make the right individuals aware of any scope changes. Consider the details required within the report on compliance executive summary as part of scoping and inventory management, including a business overview, network and data diagrams, account data flows, and in-scope components, networks, locations, and business processes.

What other significant requirements should an organization focus on?

Protecting payment pages

Some requirements (6.4.3, 11.6.1) are designed to further protect online payment pages from both malicious scripts and unauthorized modification. Scripts that are in use must be authorized and have their integrity validated, and methods must be in place to detect any changes to payment page contents and HTTP headers. These requirements are applicable to fully in-scope payment pages as well as payment pages that contain embedded payment forms, and they are designed to combat e-commerce skimming and payment page substitution.

Targeted risk analysis

A risk-based approach for certain requirements allows an entity to define the frequency of occurrence for certain controls. Targeted risk analyses are required to determine the frequency of controls and must be updated at least annually.

Preventing relocation of a primary account number (PAN)

One requirement prevents the relocation of a PAN when using remote access technologies. A change in policy or procedure does not achieve this requirement; prevention must be achieved via a technical control. This requirement is designed to prevent a PAN from being moved to systems not designed for PAN storage and includes any remote technology that provides access to a PAN – for example, remote or virtual desktops and secure socket shell sessions.

Consider engaging with a third party that has a deep understanding of these requirements and can help create a specific and detailed plan for compliance with PCI DSS v4.0.1.

This article was originally published on April 22, 2024, and was reviewed and updated.