PCI DSS version 3.2 out – What's new?

May 6, 2016 at 10:30

This blog post covers the key changes in the PCI DSS v3.2, published on April 28, and their effects on vendors handling payment card data.

The changes can be divided into two categories: changes affecting all entities and those targeted at service providers only.

1) Changes affecting all entities

The most significant change is that the PCI Council, organisation responsible for the administration of the PCI DSS standard, is now moving away from the three-year cycle on updating the standard.

Already in spring 2015, the PCI Council released outside the update cycle version 3.1 of the standard, whose most significant amendment of which was the requirement to remove the SSL and early TLS encryption protocols from the list of accepted encryption methods by summer 2016. Since use of SSL has been, and still is, quite common, for example, in point-of-sale (POS) terminals, and because updating the encryption protocol to a more robust version may require replacing the terminals with newer ones, the industry has not exactly welcomed the change with open arms.

In late 2015, the PCI Council updated its guidelines based on received feedback and extended the deadlines for replacing the SSL/early TLS protocols to summer 2018. At the same time, the Council published the news that it will release version 3.2 of the standard in spring 2016. The new version would include the updated migration deadline and other revisions.

Shortly before the release of v3.2, the PCI Council published a communication stating that version 4.0 will not be published in late 2016, as the original schedule had indicated, and that the Council will move away from the three-year updating cycle altogether. The reasons for this, cited by the Council, are as follows:

• PCI DSS is now a mature standard now and doesn't require as significant updates as we have seen in the past.

• The three-year update cycle is too rigid to react to the needs of the industry and new innovations.

Changes affecting all vendors also include specified requirements – which the PCI Council communicated already in fall 2015 – concerning documentation required to continue using SSL/TSL encryption during the migration period. For POS terminals using end-to-end encryption, the POS service provider is usually responsible for preparing the required documentation.

2) Changes affecting service providers only

The rest of the changes primarily target service providers. The goal of the Council has been to get service providers to incorporate data security aspects more clearly as part of their day-to-day activities.

The key changes in terms of service providers are:

New DESV (Designated Entities Supplemental Validation) requirements for high-risk environments where the probability for security breaches is high. Payment transaction acquirers define who is a DESV vendor. In Finland, it is likely that only a few of the largest service providers will be considered as vendors subject to the DESV requirements.
Service providers must have in place a solution that meets the SSL/TLS requirements.
Penetration testing on segmentation controls must be performed at least every six months instead of once a year.
There must be in place operational procedures for reporting on defects in data security and following security policies.

In addition to the above requirements, the standard includes a number of other amendments, some of which, however, only concern minor linguistic and editorial changes.

Key dates

PCI DSS v3.1 expires at the end of October, after which the latest version must be used in audits. The new requirements become mandatory at the start of February 2018. Prior to that, the requirements can be considered only as recommendations.

Summary

For entities using POS terminals with end-to-end encryption, the most significant change is that the migration period from SSL/early TSL protocols has been extended. You should keep in mind, however, that there are strong reasons for removing the SSL/early TSL protocols from the list of approved encryption methods, so you should replace these protocols as quickly as possible despite the fact that currently the requirements allow continue using them.

Discarding the three-year updating cycle can be viewed as both a positive and a negative change. Positive about it is that now the requirements have become so stable that there is no longer a need for major changes. On the other hand, the changes are now becoming harder to predict: before, once the payment card environment had been updated to match the requirements, you could continue your business as usual for the next few years without having to implement any major changes to your environment. Now the standard can be amended at any time, which means that you always have to be ready to implement new changes within the required migration period.

PCI DSS v3.2 includes additional new requirements for service providers only, but they mainly require that compliance with the requirements must be monitored year-round, instead of updating the environment only in order to pass the annual security audit.

Contact us