The PCI Security Standards Council (PCI SSC) recently announced the publication of version 3.0 of the Payment Card Industry Data Security Standard (PCI DSS). PCI DSS was developed to encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally. PCI DSS applies to all entities involved in payment card processing, including merchants, processors, financial institutions, and service providers, as well as all other entities that store, process, or transmit cardholder data and/or sensitive authentication data. Version 3.0 of the standard becomes effective on January 1, 2014, with the exception of certain requirements that are not effective until July 1, 2015, although version 2.0 will remain active until December 31, 2014 to ensure adequate time for organizations to make the transition.

Version 3.0 of the standard includes new subject matter that is particularly relevant to arrangements in which a customer has outsourced certain functions to a provider who maintains (or who is to maintain) PCI DSS-compliant environments and services.

IDENTIFICATION OF SCOPE, RESPECTIVE RESPONSIBILITIES AND EVIDENCE

First, in the new version of the standard, parties to cloud or other outsourcing arrangements are encouraged to clearly identify:

  • The services and system components which are included in the scope of the provider's PCI DSS assessment
  • The specific PCI DSS requirements covered by the provider
  • Any requirements which are the responsibility of the customer to include in its own PCI DSS review.

Second, in the new version of the standard, providers that undergo their own PCI DSS assessment are encouraged to provide sufficient evidence to their customers to verify that the scope of the provider's PCI DSS assessment covered the services applicable to the customer and that the relevant PCI DSS requirements were examined and determined to be in place. The standard acknowledges that the specific type of evidence supplied by the provider to their customers will depend on the agreements/contracts in place between those parties, and as an example, cites the provision by the provider of the "Attestation of Compliance" and/or relevant sections of the provider's Report on Compliance (redacted to protect any confidential information) as the means by which such evidence could be provided to customers.

These objectives are addressed in a new requirement in version 3.0 of the standard (Req. 12.8.5). Under that requirement, each entity must maintain information about which PCI DSS requirements are managed by each provider, and which are managed by the entity. The guidance for this particular requirement clarifies that the intent of this requirement is for an entity to understand which PCI DSS requirements their providers have agreed to meet. The guidance clarifies that the specific information maintained by an entity will depend on the particular agreement with its provider, the type of service, etc.

Accordingly, in order to satisfy this requirement, an entity that has outsourced certain payment-related functions to a provider will need to ensure that it maintains information about which PCI DSS requirements are managed by each provider, and which are managed by the entity itself.

For federally regulated entities, consideration should be given to having these PCI DSS requirements integrated into the institution's compliance framework in a way that makes sense for the institution.

PROVIDER-SPECIFIC REQUIREMENTS AND TESTING PROCEDURES

Version 3.0 of the standard imposes additional requirements and testing procedures applicable to service providers only.

Written Acknowledgment of Responsibility for Security

From a legal perspective, the most significant new requirement is set out in Requirement 12.9. Under this requirement, a provider must acknowledge in writing to its customer that the provider is responsible for the security of cardholder data the provider possesses or otherwise stores, processes, or transmits on behalf of the customer, or to the extent that the provider could impact the security of the customer's cardholder data environment (CDE). Requirement 12.9 will be considered a best practice until June 30, 2015, after which it becomes a requirement.

Accordingly, in order to satisfy this requirement, each provider will need to update its policies and procedures and/or contractual documentation to incorporate a written acknowledgment that the provider will maintain all applicable PCI DSS requirements to the extent the provider handles, has access to, or otherwise stores, processes or transmits the customer's cardholder data or sensitive authentication data, or manages the customer's CDE on behalf of a customer. The guidance clarifies that the method by which the provider gives acknowledgment to its customer should be agreed between the provider and its customer.

New Requirements Having Provider-Specific Testing Procedures

Version 3.0 of the standard sets out a number of new requirements that have additional, specific testing procedures for providers. These requirements, together with the testing procedures for providers, require that:

  • Providers must have and follow internal processes to ensure that non-consumer user accounts are temporarily locked-out after not more than six invalid access attempts and customer/user documentation should reflect this (Req. 8.1.6.b)
  • Providers must render customer passwords unreadable during storage and transmission (Req. 8.2.1.d and 8.2.1.e)
  • Providers must have and follow internal processes to ensure that non-consumer user passwords have a minimum length of at least seven characters and contain both numeric and alphabetic characters, or must have equivalent complexity and strength and customer/user documentation should reflect this (Req. 8.2.3.b)
  • Providers must have and follow internal processes to ensure that non-consumer user passwords are required to change periodically and that non-consumer users are given guidance as to when, and under what circumstances, passwords must change (Req. 8.2.4.b)
  • Providers must have and follow internal processes to ensure that new non-consumer user passwords cannot be the same as the previous four passwords and customer/user documentation should reflect this (Req. 8.2.5.b)
  • Service providers with remote access to customer premises, for example, for support of POS systems or servers, must use a unique authentication credential such as a password/phrase for each customer, effective July 1, 2015 (Req. 8.5.1).

Institutions and providers will likely be expected to make system modifications to ensure compliance with these new provisions. Customer-facing documentation should also be amended to advise institutional customers of the consequences of numerous log-in attempts and the password-specific requirements. While there are some password-requirement disclosures provided by banks under the Canadian Code of Practice for Consumer Debit Services, the PCI DSS requirements go further, and apply to all entities that store, process or transmit cardholder data. In addition, given that testing is required to be undertaken by providers under PCI DSS, those contracting with service providers may wish to ask for proof of the testing results or copies of compliance attestations as part of their due diligence exercise.

GENERAL REQUIREMENTS RELEVANT IN OUTSOURCING/CLOUD ARRANGEMENTS

Customers and providers will also need to review their environments and operations to ensure compliance with a number of new requirements that apply generally to all entities that are subject to the standard. These include the following:

  • For systems considered to be not commonly affected by malicious software, perform periodic evaluations to identify and evaluate evolving malware threats in order to confirm whether such systems continue to not require anti-virus software (Req. 5.1.2)
  • Where other authentication mechanisms are used, for example, physical or logical security tokens, smart cards, certificates, etc., use of these mechanisms must be assigned to an individual account and not shared among multiple accounts, and physical and/or logical controls must be in place to ensure only the intended account can use that mechanism to gain access (Req. 8.6)
  • Physical access for on-site personnel to the sensitive areas must be authorized and based on individual job function and must be revoked immediately upon termination, and all physical access mechanisms, such as keys, access cards, etc., must be returned or disabled (Req. 9.3)
  • Protect devices that capture payment card data via direct physical interaction with the card from tampering and substitution, effective July 1, 2015 (Req. 9.9)
  • Implement a methodology for penetration testing, which is used to simulate a real-world attack situation with a goal of identifying how far an attacker would be able to penetrate into an environment, effective July 1, 2015 (Req. 11.3) and perform external and internal penetration testing at least annually and after any significant infrastructure or application upgrade or modification and correct exploitable vulnerabilities found; this requirement will be of particular interest to cloud or other outsourcing providers
  • If segmentation is used to isolate the CDE from other networks, perform penetration tests at least annually and after any changes to segmentation controls/methods to verify that the segmentation methods are operational and effective, and isolate all out-of-scope systems from in-scope systems, effective July 1, 2015 (Req. 11.3.4)
  • Implement a process to respond to any alerts generated by the change-detection solution (Req. 11.5.1).

SUMMARY

In the context of an outsourcing services arrangement, PCI DSS version 3.0 highlights the importance of clearly identifying the roles and responsibilities of each party with respect to ensuring compliance with the standard.

The best practices for implementing PCI DSS into business-as-usual processes, together with many of the PCI DSS requirements, can be used to inform the descriptions of services and service levels in an outsourcing services agreement, as many of these best practices and requirements describe activities that are to be performed and measured on an ongoing basis.

Careful consideration of the PCI DSS requirements, delineation of roles and responsibilities between customers and service providers, the specifications of services and service levels to be provided under an outsourcing agreement which reflect the PCI DSS requirements, and internal policies and procedures to manage service providers with whom cardholder data is shared or that could affect the security of cardholder data are all important strategies for minimizing or avoiding disputes, security breaches, embarrassing audit reports, and public relations nightmares.

Those subject to PCI DSS requirements will also need to examine their systems and customer-facing documentation to ensure they are consistent with the requirements.

We wish to acknowledge the contribution of Christine Ing to this publication.