SecurityMetrics

PCI DSS has updated to Version 4.0. Learn about new requirements here: White Paper: PCI DSS Version 4.0: What You Need to Know

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. Its sucessor, version 3.2 retired on March 31 of 2024. Since then, version 4.0 has been considered a “best practice” by the PCI SCC.‍

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.
‍

Key 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. This recently recorded webinar goes in-depth on the subject of multi-factor authentication.

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. Here is a summary of requirements added to the SAQs.

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 (11.3.4.1)

‍Migration from SSL & TLS v1.0 to TLS v1.2

While migration to TLS v1.2 (from SSL & TLS v1.0) is not 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. ‍

Resources to Help You Comply with PCI DSS 3.2

Disclaimer: this information is outdated. Businesses now must achieve full compliance with PCI DSS 4.0 by March 31, 2025 Learn more about becoming compliant for 4.0

Since 2018 is just around the corner, we want to make sure our readers are aware of and prepared for compliance with PCI DSS 3.2. We’ve compiled some of the some of the best resources to support PCI DSS 3.2 education and compliance at your organization: