On April 15, 2015, the PCI Security Standards Council issued Payment Card Industry Data Security Standards (PCI DSS) version 3.1 (PCI DSS v3.1), which contains some “minor updates and clarifications” to PCI DSS v3.0, which went into effect on January 1, 2015.
The most significant change is that new PCI DSS v3.1 prohibits the use of any version of SSL for any PCI DSS standard requiring “strong cryptography.” This new standard is effective immediately with respect to new security implementations, and merchants have until June 30, 2016 to cease using SSL on existing implementations. PCI DSS v3.1 requires that merchants have a formal risk mitigation and migration plan in place to move away from SSL. As a result of the publication of v3.1, PCI DSS v3.0 will be retired on June 30, 2015.
Both PCI DSS v3.0 and v3.1 contain a few provisions that take effect on July 1, 2015. Those provisions include required changes to some service provider agreements. Up to five standards of PCI DSS v3.0/v3.1 may affect the merchants’ agreements with service providers or other documentation relating to service providers. Three of these standards specifically relate to merchants and two specifically apply to service providers:
PCI DSS standard 12.8.2 requires that the merchant
maintain a written agreement that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess or otherwise store, process or transmit on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment.
Standard 12.9 places a parallel obligation on the service provider to acknowledge in writing to customers that the service provider is responsible for that cardholder data the service provider possesses, stores, processes, or transmits on behalf of the customer. The standard does not require any specific contract wording for 12.8.2 or 12.9, and recognizes that the exact wording will depend on several factors: the parties’ agreement, the service being provided, and the responsibilities assigned to the merchant and the service provider. Note that assigned responsibilities does not necessarily equate to liability, so the parties may also wish to revise the limitations of liability in the service provider agreements to reflect the assigned responsibilities.
Related to this allocation of responsibilities, although not a contractual requirement, standard 12.8.5 requires that each merchant maintain information about which PCI DSS requirements are managed by the merchant and which are managed by the service providers. Specificity in the contract language can facilitate compliance with this documentation requirement.
In addition, standard 8.5.1 requires that any service provider that has remote access to customer premises must use a “unique authentication credential (such as a password/phrase) for each customer.” For example, if a service provider licensed and maintained software for point-of-sale systems, that service provider would need to establish separate passwords for each merchant. The standard notes that this requirement does not apply to “shared hosting providers accessing their own hosting environment, where multiple customer environments are hosted.” Notably, many payment card data breaches have occurred because merchants or their point of sale vendors have used default passwords to remotely accesses point of sale systems and take cardholder data.
Finally, Section 11.3 contains a new penetration test requirement that may become part of a service provider agreement. The requirement for penetration testing extends to ”the entire CDE perimeter and critical systems.” PCI DSS v3.1 clarifies that the techniques used in penetration testing will vary based upon the merchant organization, as well as the type, depth, and complexity of its cardholder data environment. This requirement could affect a merchant in instances where, for example, a merchant’s web site uses a third party to process credit card transactions.
Both PCI DSS v3.0 and v3.1 note that, although the effective date is Wednesday, July 1, 2015, the standards described above are considered a “best practice” until that date.
To facilitate compliance, merchants should:
- Determine which service providers store, possess, process and/or transmit cardholder data;
- Determine which service providers “could affect the security” of the very broadly defined “cardholder data environment”;
- By June 30, 2015, revise the written agreements with the affected service providers;
- Include the service provider’s acknowledgement of its responsibility for the security of the cardholder data and cardholder data environment;
- Consider whether to change the limitations of liability;
- Consider whether to add a requirement that the service provider must use a unique authentication credential for the merchant, if the service provider will have remote access to the merchant’s premises;
- Consider whether to add a requirement relating to penetration testing if the service provider is part of the cardholder data environment “perimeter or critical systems”; and
- Consider adding a requirement that the service provider use an independent verification service relating to compliance with applicable PCI DSS requirements
- Stop using SSL for new security implementations immediately, where security control standards require “strong encryption”
- Prepare formal risk mitigation and migration plan with respect to SSL for existing implementations;
- Consider using alternatives such as IPSec or SSH; and
- Transition from the use of SSL as a security control by June 30, 2016
Compliance with PCI DSS apparently can also help merchants prevent data security breaches. In its 2015 “PCI Compliance Report,” Verizon stated that “Of all the data breaches that our forensics team has investigated over the last 10 years, not a single company has been found to be compliant at the time of the breach—this underscores the importance of PCI DSS compliance.” (Report at 3.)
