PCI DSS v4.0 is here – FAQ on compliance

1. Definition of system components

With the ever-changing nature of technology, the definition of system components has undergone some clarifications and enhancements. Specifically, in PCI DSS v4.0 the definition has been expanded to include some system components that have not previously been included within scope. Newly considered systems include software deployment and configuration management tools such as:

• Source code repositories
• Continuous integration/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.

2. Formal assignment of roles and responsibilities

PCI standards include 12 base requirements, and each one handles a different part of the payment cycle in the cardholder data life cycle. With PCI DSS v4.0, every one of those requirements now has associated roles and responsibilities, and all day-to-day responsibilities for PCI requirement activities must be formally assigned, either through policy and procedures or as a separately maintained assignment. Organizations in a complex environment might want to consider using a responsible, accountable, consulted, and informed (RACI) matrix for assignments. The intent here is to establish accountability for performance of all requirements throughout the standard.

3. Management’s scoping exercise

In the past, the annual confirmation of the PCI scope might have been performed only by an assessor as part of a PCI assessment. Now it 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 new requirement is meant to emphasize a proactive approach for ongoing internal PCI focus and encourage less reliance on the assessor.

1. Preventing relocation of primary account number (PAN)

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

2. Targeted risk analysis

A new 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.

3. Protecting payment pages

Some new requirements 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.

Prepare for compliance

While some PCI DSS v4.0 requirements are not applicable yet, it’s important to make efforts now to demonstrate compliance by the time the requirements become effective. Companies might want to 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.