Introducing PCI DSS 4.0: New Payment Card Security Standards Take Broad View of Scope, Offer Companies More Compliance Flexibility

On March 31, 2022, the Payment Card Industry Security Standards Council published version 4.0 of its PCI Data Security Standard (PCI DSS). The updated standards provide significant new guidance on the scope and applicability of the PCI DSS requirements and their application to third-party service providers, including:

• PCI DSS applies to organizations, systems, processes, and people that could impact the security of account data—even if they do not themselves store, process, or transmit such data.
• Likewise, a company's Cardholder Data Environment (CDE) in scope for PCI DSS applies to any systems that could impact the security of account data.
• Service providers are considered in scope for PCI DSS if they could impact the security of an entity's CDE, even if they do not process cardholder data themselves.
• Encryption alone does not take an entity or system out of scope for PCI DSS. An entity may be able to limit the scope of its compliance with PCI DSS if it receives encrypted data, has no ability to decrypt that data, and does not conduct encryption, decryption, or key management activities.

Version 4.0 also introduces a two-track approach to PCI DSS compliance. A new track, called the "Customized Approach," provides in-scope entities with greater flexibility to achieve compliance by using methods and testing procedures not specifically detailed in the standard.

PCI DSS is a set of requirements developed by the major credit card networks and is designed to enhance the security of credit card transactions and cardholder data. On its face, PCI DSS applies to any entity involved in credit card processing, including merchants, processors and service providers that store, process, or transmit cardholder data. In short, the Council takes the position that PCI DSS applies to virtually all companies, big and small, that take credit card payments from consumers or help facilitate those transactions.

Version 4.0 of PCI DSS is the first major update to the security standard since 2018. To provide organizations time to understand and implement the changes required by version 4.0, the current version of PCI DSS will remain active for two years until it is retired on March 31, 2024.

Trainings for Qualified and Internal Security Assessors on the new version will be available in June 2022. Once those trainings are conducted, companies will have the choice of assessing to either the current version or version 4.0. Companies will be able to rely on a service provider who is validated to an earlier PCI DSS version in some instances.

PCI DSS Applicability

PCI DSS takes a broad view of the entities to which it applies. Version 4.0 provides that "PCI DSS requirements apply to entities with environments where account data is stored, processed, or transmitted," and states that even where an entity does not store, process, or transmit account data, some requirements can apply when the entity's systems "can impact the security of the [account data]" (emphasis added).

Version 4.0 provides illustrative examples of this scenario, explaining that:

• If an entity does not process account information itself, but instead engages third-party service providers to store, process, or transmit account information on its behalf, requirements related to the management of service providers in Requirement 12 will be applicable.
• Requirements related to an incident response plan are applicable to all entities, to ensure that there are procedures to follow in the event of a suspected or actual breach of the confidentiality of cardholder data.
• If the entity stores sensitive authorization data (SAD), requirements specifically related to SAD storage in Requirement 3 will be applicable.
• If the entity can impact the security of a company's CDE because the security of an entity's infrastructure can affect how cardholder data is processed (for example, via a web server that controls the generation of a payment form or page), some requirements will be applicable.

In practice, payment brands and acquirers (the financial institutions that process payment card transactions for merchants) are responsible for ensuring that entities comply with the PCI DSS and generally do this through service contracts. Version 4.0 acknowledges that "whether any entity is required to comply with or validate their compliance to PCI DSS is at the discretion of … payment brands and acquirers."

Scope of PCI DSS Assessments

The updated PCI DSS requirements provide new clarification on the systems that are in scope and therefore must be included in an entity's assessment of PCI DSS compliance. As a baseline, the requirements apply to the CDE, which is comprised of "system components, people, and processes that store, process, and transmit cardholder data and/or sensitive authentication data, and system components that may not store, process, or transmit [Cardholder Data] CHD/ [Sensitive Authentication Data] SAD but have unrestricted connectivity to system components that store, process, or transmit CHD/SAD" (emphasis added).

Version 4.0 also clarifies that the requirements apply to "system components, people, and processes that could impact the security of the CDE" (emphasis added).

Third-Party Service Providers

The update includes significant clarification regarding the use of third-party service providers to manage an entity's CDE. In many cases, third-party service providers will fall in scope of PCI DSS.

Whenever an entity uses a third-party service provider within or related to its CDE, the entity must manage and oversee the third party in accordance with Requirement 12.8. This requirement applies to service providers that:

• Have access to an entity's CDE;
• Manage in-scope system components on the entity's behalf; and/or
• Can impact the security of the entity's CDE.

Under Requirement 12.8, entities engaging service providers are required to perform due diligence, have appropriate agreements in place, allocate responsibility for each requirement, and monitor the compliance of the service provider at least annually.

Importantly, the guidance provided for Requirement 12.8 states that a third-party service provider "does not need to be PCI DSS compliant for its customer to meet" the requirement. Service providers can validate their compliance with either of the following two options:

• Annual assessment: The service provider undergoes an annual PCI DSS assessment and provides evidence to its customers to show the service provider meets the applicable PCI DSS requirements; or
  
• Multiple, on-demand assessments: If a service provider does not undergo an annual PCI DSS assessment, it must undergo assessments upon request of their customers and/or participate in each of its customers' PCI DSS assessments, with the results of each review provided to the respective customer(s).

Practically speaking, if a service provider does not undergo annual, formal PCI DSS compliance validation, it may be able to provide separate evidence that the applicable requirements have been met, thereby ensuring that its customers remain PCI-DSS compliant.

Encryption and Compliance Scoping

The update also addresses the issue of whether entities that only process encrypted cardholder data fall within the scope of PCI DSS. In short, "encryption alone is generally insufficient to render the cardholder data out of scope for PCI DSS and does not remove the need for PCI DSS in that environment. The entity's environment is still in scope for PCI DSS due to the presence of cardholder data."

The standard provides the following situations in which encrypted cardholder data will still be in scope of PCI DSS:

• Systems performing encryption and/or decryption of cardholder data, and systems performing key management functions;
• Encrypted cardholder data that is not isolated from the encryption and decryption and key management processes;
• Encrypted cardholder data that is present on a system or media that also contains the decryption key;
• Encrypted cardholder data that is present in the same environment as the decryption key; and
• Encrypted cardholder data that is accessible to an entity that also has access to the decryption key.

Nevertheless, if a service provider (or other entity) merely receives and/or stores encrypted data and does not have the ability to decrypt it, the data can largely be considered out of scope of the PCI DSS. Version 4.0 explains that in a case where a service provider stores encrypted cardholder data on behalf of a customer, does not have access to the decryption key, and does not perform key management for its customer, the data can be excluded when the service provider determines its PCI DSS scope. Similarly, if a service provider only receives encrypted cardholder data for the purpose of routing the data to other entities and does not have access to the decryption key, the service provider may be considered the same as a public network and would not have any PCI DSS responsibility for the encrypted data.

Given the fact-based assessment that must go into determining the scope of an entity's PSI DSS environment and responsibilities, the update encourages service providers and their customers to clearly define which party is responsible for ensuring compliance with each of the PCI DSS requirements.

Two-Track Approach

In perhaps the most significant structural change to the standard, PCI DSS version 4.0 introduces a two-track method of implementing and validating compliance with the standards.

First, under the "Defined Approach," organizations may follow the traditional method of validating PCI DSS compliance, specifically, by implementing security controls to meet each of the requirements set out in the standard.

Second, under a newly introduced "Customized Approach," organizations may implement their own controls to meet the stated "Customized Approach Objective" for each of the requirements. While this bespoke option provides organizations a significant degree of flexibility, the Customized Approach carries with it additional documentation requirements to demonstrate compliance with PCI DSS. For example, organizations will be required to perform a targeted risk analysis for each PCI DSS requirement that it meets with the Customized Approach.

Rules for Multi-Tenant Service Providers, Including Cloud Service Providers

Version 4.0 contains significant updates and new requirements in the section that applies to cloud service providers, referred to as "multi-tenant service providers." Multi-tenant service providers are defined as "a type of third-party service provider that offers various shared services to merchants and other service providers, where customers share system resources (such as physical or virtual servers), infrastructure, applications (including Software as a Service (SaaS)), and/or databases." For example, if a service provider hosts multiple entities on a single shared server, provides e-commerce and/or "shopping cart" services, or provides web-based hosting services, it would be considered a multi-tenant service provider.

In a new requirement, multi-tenant service providers are specifically required to implement logical separation so that (1) the provider cannot access its customers' environments without authorization, and (2) customers cannot access the provider's environment without authorization.

The update maintains a requirement to implement controls to ensure that each customer only has permission to access its own cardholder data and CDE and can only access the resources allocated to the customer. The update contains a new requirement that multi-tenant service providers confirm the effectiveness of these logical separation controls every six months via penetration testing.

Multi-tenant service providers also are now required to provide audit logging capabilities for customers and establish processes to address customer-reported security incidents.

Key Changes to the Requirements

In addition to the above, version 4.0 makes numerous changes to PCI DSS's substantive requirements. These substantive changes include the following:

• Rule 1.4.4 has been clarified to require entities to ensure that system components that store cardholder data are not directly accessible from untrusted networks. Similarly, Rule 1.5.1 clarifies that entities must implement security controls on any computing device that connects to both untrusted networks and the CDE to help protect against internet-based attacks.
• Rule 5.3.2 requires entities to perform periodic and active or real-time scans and also includes a new option to perform continuous behavioral analysis to scan for malware. If companies perform periodic malware scans, Rule 5.3.2.1 creates a new requirement to define the frequency of the scans in the entity's risk analysis.
• Rule 8.4.2 creates a new requirement to implement multi-factor authentication (MFA) for all access into the CDE. With this rule, MFA is now required for both remote and direct access to the CDE.
• Rule 11.3.1.2 creates a new requirement to perform internal vulnerability scans via authenticated scanning.
• Rule 11.4.7 creates a new requirement for multi-tenant service providers to support their customers for external penetration testing, and cannot forbid penetration testing.
• Under the new Rule 12.3.1, entities now have the flexibility to determine how frequently to undertake certain compliance efforts, based on a targeted risk analysis. For example, organizations may now define the frequency with which they need to:
  
  • Assess systems identified as not at risk for malware;
  • Inspect point of interaction devices; and
  • Train incident response personnel.
• Rule 12.5.2 creates a new requirement for entities to document and confirm their PCI DSS scope at least every 12 months and upon significant change to the in-scope environment. Similarly, Rule 12.5.2.1 creates a new requirement for service providers to document and confirm PCI DSS scope at least once every six months and upon significant change to the in-scope environment.
• Rule 12.10.7 creates a new requirement for incident response procedures to be in place and initiated upon detection of stored PAN anywhere it is not expected.

Conclusion

PCI DSS version 4.0 provides clarification on common scoping issues related to PCI DSS compliance and injects significant levels of flexibility into the standard. Entities—particularly those looking to limit their PCI DSS compliance requirements through the use of service providers or third-party technology solutions—should consult the new guidance carefully to determine their obligations.

DWT's information security team regularly advises clients on PCI DSS compliance and other issues related to data security for ecommerce and payment processing, helping to bring clarity and implement compliance standards for complex industry-specific obligations.