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: Show
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 ApplicabilityPCI 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:
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 AssessmentsThe 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 ProvidersThe 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:
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:
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 ScopingThe 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:
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 ApproachIn 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 ProvidersVersion 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 RequirementsIn addition to the above, version 4.0 makes numerous changes to PCI DSS's substantive requirements. These substantive changes include the following:
ConclusionPCI 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. This article was originally featured as a privacy and security advisory on DWT.com on May 6, 2022. Our editors have chosen to feature this article here for its coinciding subject matter. What encryption is required for PCI compliance?Strong Cryptography
The SSC considers the following standards and algorithms as acceptable for meeting PCI DSS encryption requirements: AES (128 bit or higher) TDES/TDEA (i.e., the Triple Data Encryption Algorithm) RSA (2048 bits or higher)
What does the PCI PTS standard cover?The PCI PTS standard is modular, covering hardware and firmware security requirements to protect against physical, logical and network tamper attacks.
What does PCI stand for?Payment card industry (PCI) compliance is mandated by credit card companies to help ensure the security of credit card transactions in the payments industry.
What is PCI DSS compliance?Payment Card Industry Data Security Standard (PCI DSS) compliance is adherence to the set of policies and procedures developed to protect credit, debit and cash card transactions and prevent the misuse of cardholders' personal information. PCI DSS compliance is required by all card brands.
|