Skip to main content

PCI DSS Version 3.2 Released

May 02, 2016

Last Thursday, April 28, 2016 the PCI Security Standards Council (PCI SSC) released version 3.2 of the PCI Data Security Standard (PCI DSS). To save you the trouble of accessing the change log, we have put together some of the more notable changes in the new version.

  • The official sunset date for v3.1 will be October 31, 2016. So any assessments done after that date will need to comply with and use v3.2.
     
  • Two new sections to Appendix A have been added. In addition to the Appendix for shared hosting providers (now marked A.1), we get Appendices A.2 and A.3. A.2 covers SSL and early TLS for those of you that will miss the June 30, 2016 date. For those of you that thought 2018 was the deadline and missed discussions on the webinar about the SSL/early TLS deadline, while the deadline was extended to June 30, 2018, any organizations missing the June 30, 2016 date must fill out Appendix A.2. A.3 is where the Council added the designated entities supplemental validation (DESV) requirements.
     
  • There are a number of new requirements for service providers that are best practices until February 1, 2018. Those new requirements include: (1) maintain a documented description of the cryptographic architecture, (2) detect and report on failures of critical security control systems, (3) perform penetration testing on segmentation controls at least every six months, (4) executive management to establish responsibilities for the protection of cardholder data and a PCI DSS compliance program, and (5) perform reviews at least quarterly, to confirm personnel are following security policies and operational procedures. I would bet that numbers three and five will likely create a lot of contention with service providers. But you have until February 1, 2018 to get those in place. However, if experience teaches us anything, service providers had better start now getting these new requirements in place and operating.
     
  • All organizations picked up the following new requirements that are best practices until February 1, 2018: (1) change control processes to include verification of PCI DSS requirements impacted by a change, and (2) multi-factor authentication for all personnel with non-console administrative access to the CDE. As with the aforementioned new requirements for service providers, these will also require a lot of organizations to get started now to ensure these new requirements are in place and operating.
     
  • The Council clarified requirement 8.1.5 to show that it is intended for all third parties with remote access, rather than only vendors. While most organizations understood the intent of this requirement, there were a few that played “legal eagle” and refused to require compliance for non-vendors.
     
  • Requirement 6.5 has been clarified that developers must go through secure coding training at least annually. This change will likely create some consternation for some organizations that are developing their own software that is in-scope for PCI compliance.
     
  • Clarified 11.5.a by removing “within the cardholder data environment” from the testing procedure for consistency with requirement, as the requirement may apply to critical systems located outside the designated CDE. This will likely expand the number of systems that require critical file monitoring.
     
  • Clarified 12.8 1 by saying that the list of service providers now must include a description of the service(s) provided.
     
  • Clarified 12.8.2 by adding guidance that service provider responsibility will depend on the particular service(s) being provided and the agreement between the two parties.
     
  • One of my pet peeves has finally been addressed. I have always had an issue with requirement 1.1.6 and the use of the terminology “insecure protocols”. The reason is that in one way or another, all protocols have their insecurities whether they are known or not. In v3.2, the Council has finally removed the “insecure” designation as, in their words, “these may change in accordance with industry standards.” It is those small battles at times that make your day.

This is just a sample of the notable changes; there are other clarifications and edits that have been made to the new version not listed above. You can access the full document as well as the Reporting Template on the PCI SSC website


    Jeff Hall

By: Jeff Hall

Principal Security Consultant

See More

Related Blogs

June 08, 2018

The Business Trusts the Third Party – Should You?

In this day and age we are faced with some hard facts within information security. One of those facts is that breaches are imminent and we must be pre...

See Details

March 08, 2018

Part 2: Frameworks in Context: The Business-Aligned Information Security Program and Control Frameworks

In part 1 of this series, we provided insights responding to the frequent question regarding control frameworks and their place in the security strate...

See Details

February 28, 2018

Part 1: Frameworks in Context: The Business-Aligned Information Security Program and Control Frameworks

During hundreds of strategy, risk and compliance engagements, Optiv’s consultants often have been asked very thoughtful and deep questions about contr...

See Details

How Can We Help?

Let us know what you need, and we will have an Optiv professional contact you shortly.


Privacy Policy

Stay in the Know

For all the latest cybersecurity and Optiv news, subscribe to our blog and connect with us on Social.

Subscribe

Join our Email List

We take your privacy seriously and promise never to share your email with anyone.

Stay Connected

Find cyber security Events in your area.