By February 1, 2018, all PCI security assessments will need to use version 3.2 of the PCI DSS.

From PCI DSS 3.1 to 3.2

The Payment Card Industry Security Standards Council (PCI SSC) announced PCI Data Security Standard (PCI DSS) version 3.2 on April 28, 2016. This latest version adds clarification, guidance as well as some new requirements to the standard.

According to Troy Leach, the PCI SSC’s CTO, the council made these changes to the PCI DSS, “to ensure it continues to protect against old exploits that are still causing problems, addresses new exploits and provides greater clarity for implementing and maintaining PCI DSS controls.”

PCI DSS 3.1 officially retired on October 31 of 2016. Since then, version 3.2 has been considered “best practice” by the PCI SCC.

Starting February 1, 2018, the changes in version 3.2 will be effective as requirements, and all assessments will need to use the new version.

PCI DSS 3.1 to 3.2 Timeline

  • April 28, 2016: The PCI SCC announced the change to 3.2.
  • May 2016: PCI DSS 3.2 published.
  • October 31, 2016: PCI DSS 3.1 retired. Version 3.2 considered best practices.
  • January 31, 2018: Last day PCI DSS 3.1 can be used.
  • February 1, 2018: Changes in PCI DSS 3.2 effective as requirements.

Important Takeaways from the PCI DSS 3.2 Changes

Multi-Factor Authentication

Previously, the PCI DSS required only untrusted, remote access into cardholder data environment to require “two-factor authentication.” They changed the name to “multi-factor authentication” to clarify that at least two factors must be used—they also extended this requirement to any personnel with administrative access into the cardholder data environment.

Changes to SAQs

No new SAQ categories have been added, but most SAQ categories have added new requirements that reflect the new PCI DSS 3.2 requirements.

Supplement on Scoping & Network Segmentation

The PCI SCC released this supplement in December of 2016. Its purpose is to help organizations know which of their systems should be included in their PCI scope and understand how segmentation can reduce PCI scope. One of the biggest takeaways for organizations is to make sure they also include any systems that are connected to the cardholder data environment in their PCI scope, not just systems located within the CDE.

Segmentation Checks

Starting February 1, 2018, segmentation checks (penetration tests on segmentation controls) must be performed by an organizationally independent resource (as is already required for other penetration tests). Also, service providers will be required to perform segmentation tests at least every six months and after any changes to segmentation controls/methods.

Changes for Service Providers

As mentioned above, PCI DSS 3.2 requires service providers to perform segmentation checks at least every six months and after any changes. There are also a few new requirements specific to service providers in the following areas:

  • Cryptographic architecture (requirement 3.5.1)
  • Timely detection and reporting (requirement 10.8), (10.8.1)
  • Establish responsibilities for PCI and data (12.4.1)
  • Quarterly personnel Reviews (12.11, 12.11.1)
  • Penetration testing (
Migration from SSL & TLS v1.0 to TLS v1.2

While migration to TLS v1.2 (from SSL & TLS v1.0) is required by the PCI SSC until June 30, 2018, it’s a good idea to make sure your organization makes this change in conjunction with the PCI DSS 3.2 updates.