SecPod

Learn Search

Search across all Learn content

← Back to Expressions & POVs
2016 PCI Sunrise: PCI DSS 3.2

2016 PCI Sunrise: PCI DSS 3.2

Mar 29, 2016By Rini4 min read

The new version of the PCI Data Security Standard is expected to be released by the PCI Security Standards Council by April. PCI DSS 3.2 will be the only release for the year 2016 and will be the final update to the standard.

The council wants to make an early release of the updated version so that enterprises can deal with the changes related to the Europay, MasterCard and Visa chip or EMV release. Troy Leach, the CTO of the PCI Security Standards Council said in a blog post about PCI DSS 3.2 that the choice was made to move to a single release earlier in 2016 for various reasons.

Leach said that primarily the revised migration dates away from SSL and early TLS [Transport Layer Security] must be addressed. Additional changes to address the threat landscape as opposed to the wholesale updates to the standard should be expected later. The industry knows PCI DSS as an established standard now and this doesn’t quite require as many updates as witnessed in the past.

Leach also said that the PCI council identifies an early release of the PCI DSS 3.2 that will help retailers to deal with the extreme changes with the payment systems being transformed to EMV chip and PIN and contactless payments in the U.S.

PCI DSS 3.2 doesn’t involve any major changes but only some significant alterations. According to Leach, when deciding what changes were to be made, the council took into account market feedback and trending attacks that were discovered in breach forensics.

Leach said “For 3.2, we are evaluating additional multifactor authentication for administrators within a cardholder data environment; incorporating some of the designated entities supplemental validation criteria for service providers; clarifying masking criteria for primary account numbers when displayed; and including the updated migration dates for SSL and early TLS that were published in December 2015″.

One thing that enterprises must be aware of is that organizations should be aware that PCI DSS 3.2 will become effective as soon as it is released. Version 3.1 will no longer be effective three months post the release of version 3.2. Depending on the release of 3.2, any ongoing PCI DSS 3.1 assessments would require to be finished by either June or July.

Leach said that “The revision of PCI DSS is as good a time as any to reevaluate how to minimize effort while improving security posture”. She also said that “It is a healthy practice for any company to regularly evaluate how it accepts payments, and whether it can reduce the risk to its customers and its organization by changing business practices for cardholder data exposure; evaluating newer payment technology, like tokenization and encryption; and confirming its third-party service providers understand the importance of the upcoming changes, as well”.

Target release date for PCI DSS 3.2: April 2016Sunset of PCI DSS 3.1: October 2016

PCI issued initial guidance and removed SSL in April 2015 as an example of strong cryptography from the PCI Data Security Standard stating that after 30 June 2016 it cannot be used as a security control. After receiving market feedback, the PCI Security Standards Council revised and updated the termination dates.

Overall, the revisions state:

  • “All processing and third party entities – including Acquirers, Processors, Gateways and Service Providers must provide a TLS 1.1 or greater service offering by June 2016”.
  • “Consistent with the existing language in the DSS v3.1, all new implementations must be enabled with TLS 1.1 or greater”.
  • “All processing and third party entities must cutover to a secure version of TLS (as defined by NIST) effective June 2018”.
  • “The use of SSL/TLS 1.0 within a POI terminal that can be verified as not being susceptible to all known exploits for SSL and early TLS, with no demonstrative risk can be used beyond June 2018 consistent with the existing language in the DSS v3.1 for such an exception”.

(source: PCI Security Standards Council LLC).

  • Rini Thomas

Featured Posts

Open The Most Effective Vulnerability Assessment Framework What Makes One Effective
The Most Effective Vulnerability Assessment Framework What Makes One Effective

Point of View

The Most Effective Vulnerability Assessment Framework What Makes One Effective

No single named standard makes a vulnerability assessment framework effective. This piece covers NIST, ISO, and CIS Controls, then breaks down what actually separates a working framework from a checklist, coverage, risk based prioritization, cadence, ownership, and a feedback loop.

Sep 11, 2026

Open Threat and Vulnerability Assessment How Risk Actually Gets Calculated
Threat and Vulnerability Assessment How Risk Actually Gets Calculated

Point of View

Threat and Vulnerability Assessment How Risk Actually Gets Calculated

A vulnerability alone doesn't tell the whole risk story. This piece breaks down how a threat and vulnerability assessment pairs technical weaknesses with real attacker context, walks through the six step process, and covers frameworks like NIST 800-30 and ISO 27005.

Sep 11, 2026

Open Vulnerability Assessment Services: What to Look For
Vulnerability Assessment Services: What to Look For

Point of View

Vulnerability Assessment Services: What to Look For

Choosing a vulnerability assessment provider means asking about actual coverage, scan frequency, and whether findings come with real prioritization or just a CVSS dump. This piece breaks down what strong vulnerability assessment services include, red flags to avoid, and questions to ask before signing.

Sep 11, 2026

Open Agentic AI Vulnerability Assessment What Changes and What Does Not
Agentic AI Vulnerability Assessment What Changes and What Does Not

Point of View

Agentic AI Vulnerability Assessment What Changes and What Does Not

Agentic AI is expanding what a vulnerability assessment needs to cover, autonomous agents bring their own credentials, tool access, and memory, adding a genuinely new asset class alongside servers and endpoints. It's also compressing attacker timelines and introducing risk categories like goal hijacking and tool misuse that don't map to a traditional CVE. But the core discipline hasn't changed: the same lifecycle of scoping, scanning, prioritizing, and remediating still applies, human judgment still drives prioritization, and accountability still sits with the people who deployed the agent, not the agent itself.

Sep 9, 2026