Getting ready for PCI DSS v4.0: 6 FAQ

When the Payment Card Industry Security Standards Council (PCI SSC) issued version 4.0 of its PCI Data Security Standard (PCI DSS v4.0), it gave organizations that handle payment card transactions a two-year window in which to update their security program in order to comply. The new standard includes more than 200 changes from the existing standard, some of which could entail significant shifts in organizational responsibilities, and the March 31, 2024, deadline is fast approaching.

Any organization that accepts card payments should expect to dedicate significant time and resources to the compliance effort, beginning with one of the most consequential steps: making a timely decision regarding the fundamental structure of its PCI data security program. To help organizations get ready, here are answers to some of the most frequently asked questions about PCI DSS v4.0.

Q: What is driving this update? Why is it necessary?

Recent years have seen dramatic shifts in how the payment card industry operates including major increases in online purchases and significant advances in cloud storage of customer and transaction data, to name only a few. Recognizing this, in 2019 the PCI SSC issued a request for comments from the industry regarding evolving security needs and proposed changes to the existing standard. In addition to updating requirements to reflect technological advances, the upgrade also places increased emphasis on promoting security as a continuous process, allows increased flexibility for organizations using different methods to achieve security objectives, and enhances validation methods and procedures.

Q: What are the deadlines for compliance with the PCI DSS v4.0?

The current version of PCI DSS, version 3.2.1, will remain active until the end of March 31, 2024, at which point organizations will need to demonstrate compliance with version 4.0. In addition, the council decided to allow an additional year (until March 31, 2025) for organizations to comply with some of the new requirements that involve significant departures from the existing standard.

As with earlier versions, the new standard offers several avenues for demonstrating compliance, depending on the size and nature of the enterprise. Some organizations will need to complete a detailed PCI DSS assessment, which then must be documented with a Report on Compliance from an independent Qualified Security Assessor (QSA) or a certified Internal Security Assessor (ISA). For others, a self-assessment questionnaire with management certification could be sufficient.

In either case, early adopters can begin implementing controls and tests in accordance with PCI DSS v4.0 prior to March 2024 if they choose, and they can undergo an assessment as soon as their assessors have completed training and are certified in the new standard.

Q: Why is adapting to PCI DSS v4.0 going to be more challenging than previous updates?

As the nomenclature implies, PCI DSS v4.0 is a major upgrade from the previous version, incorporating more than 200 changes. Of these, 104 could be categorized as relatively straightforward clarification or guidance updates to wording, definitions, and instructions.

Another 64 changes reflect evolving requirements, such as changes needed to keep up to date with emerging threats and changing technology. These include new or modified requirements and testing procedures, as well as upgrades such as enhanced password requirements or authorization processes.

There also are 53 structural or format changes. These involve fundamental changes to the standard itself, such as reorganizing content and combining, separating, and renumbering the standard’s 12 requirements. The most consequential of these structural changes is the introduction of a new alternative approach to compliance. In addition to the traditional defined approach, some of the mature entities now will be able to use a customized approach that allows them greater flexibility in how they meet security objectives.

Q: What are the major differences between the defined and customized approaches?

From its earliest iteration, the PCI standard always has allowed only one way for entities to meet their payment card data security objectives: by implementing the required policies, procedures, and controls exactly as spelled out in the standard. PCI DSS v4.0 changes that, offering two approaches that organizations may use:

• Defined approach. This is the traditional approach, in which an entity implements security controls exactly as spelled out for each of the standard’s 12 requirements. An assessor (either a QSA or an ISA) then follows the defined testing procedures to verify that requirements have been satisfied. If a legitimate and documented technical or business constraint prevents an entity from implementing one of the prescribed controls, the entity may implement other controls instead, provided those controls sufficiently mitigate the risk associated with the requirement in question. These controls – called compensating controls – often are used when a legacy system or process cannot be updated to meet the requirement.
• Customized approach. This approach lets mature entities implement controls that meet a stated objective in a way that does not strictly follow the defined requirement. The focus of this approach is on the intent of the requirement rather than the specific details. The customized approach provides greater flexibility to organizations that prefer to use new technologies or other innovations to meet PCI security objectives.

It is important to understand the distinction between the customized approach on one hand and the defined approach with compensating controls on the other. Compensating controls are alternative controls entities may use only if business or technical constraints make them unable to meet a requirement exactly as defined. The customized approach, on the other hand, allows organizations to choose controls that meet the requirement’s objectives in a completely different way. For example, under the customized approach, organizations might choose to use modern machine learning or artificial intelligence technology to detect threats or supplement their legacy scanning systems, even though those tools are not specifically called for in the standard.

Note that entities can combine the approaches, using the defined approach for one requirement or system component and the customized approach for others. As part of the preparation for PCI DSS v4.0, entities should identify which approach or combination of approaches best suits their needs.

Q: How does an entity determine which approach to use?

In some situations, the defined approach is the only permissible choice. For example, the customized approach is not permitted when an entity uses a self-assessment questionnaire to test and validate controls rather than using a qualified QSA or ISA to complete a Report on Compliance. The standard also states that the customized approach cannot be used to meet certain requirements, including external vulnerability scans and retention and encryption of account data, among others.

The defined approach is basically the approach entities have been following all along to meet PCI DSS. This approach is useful for those organizations that prefer clear direction about how to meet security objectives, with the requirements and testing procedures spelled out in detail. If an entity already has sufficient controls in place and does not see an advantage in developing customized objectives and tools, the defined approach is likely to be appropriate.

The customized approach is intended primarily for mature organizations with an established, risk-based approach to security and the ability to effectively design, implement, test, document, and maintain their own robust security controls. Each customized implementation will be different, and no predefined testing procedures exist. Instead, an entity’s assessor will need to develop unique testing procedures to verify that the implemented control meets the stated objective. To maintain independence, the assessor cannot be involved in developing or implementing the controls.

Because entities will develop their own controls, the customized approach requires substantial preplanning and advance documentation. An organization using the customized approach must provide its assessor advance details about a variety of points including the specific controls and PCI requirements being met by each control, lines of responsibility, maintenance procedures, descriptions of how controls were tested internally, evidence of the controls’ operating effectiveness, and a targeted risk analysis for each customized control and each applicable PCI requirement.

The PCI SSC provides a template for documenting the customized approach, which includes all the elements that must be provided to assessors in advance. The significant level of planning and preparation that will be needed reinforces the point that the customized approach is intended for risk-mature entities. When appropriate, however, it can allow organizations to meet data security objectives more effectively, with greater flexibility and innovation.

Q: What are some of the other major changes in PCI DSS v4.0?

In addition to allowing the new customized approach option, PCI DSS v4.0 incorporates more than 200 other changes, several of which have a significant impact. They include:

• Scope confirmation. Requirement for performing an annual confirmation of the PCI scope now formally falls to the assessed as well as the assessor. This confirmation must include updated dataflow diagrams as well as identification of all system components in the cardholder data environment (CDE), segmentation controls, and third-party connections to the CDE, among other elements.
• “System components” definition. The definition of this term has been expanded and made more explicit. Instead of being limited to servers, stations, and similar terms, the expanded definition now includes cloud infrastructure and components, both external and on-premises. This seemingly routine change actually can have a major impact by bringing more system elements within scope of the new PCI standard.
• Documentation, roles, and responsibilities. The standard formalizes many of the policies and procedures, roles and responsibilities, and other expectations an assessor will examine. These elements are now spelled out explicitly within each of the standard’s 12 requirements, which means they will need to be formally documented.
• Multifactor CDE access. Multifactor authentication (MFA) will be required for all access to the cardholder data environment, whereas MFA previously was required for only remote and administrative access. In addition, this layer of MFA will be evaluated independent of remote access, such that if individuals remotely access their corporate network through MFA and then want to access the CDE, they will need a second layer of MFA. Because this could necessitate significant system changes, the council extended the deadline for compliance with this requirement for an additional year, until March 31, 2025.
• User access reviews. All access by application and system accounts and related access privileges must be reviewed every six months. Management must review and confirm the appropriateness of all access that is granted. The deadline for complying with this part of the standard also has been extended until March 2025.

In addition to these relatively high-profile changes, the new standard also incorporates many other significant upgrades, revisions, and structural modifications. Any organization that handles payment card transactions will need to review the new components carefully and make an informed decision about which of the approach and control alternatives is appropriate for its situation. With the initial compliance deadline fast approaching, the time to begin this assessment has arrived.