Latest PCI DSS Versions: A Look At How the Standard Has Evolved

It may be hard to believe, but almost a decade and a half has passed since the Payment Card Industry Data Security Standards (PCI DSS) were created. Following that introduction, the five major payment card brands, American Express, Discover, JCB, Mastercard and Visa, aligned with merchants and others with a vital interest in the security of payment card transactions to form the PCI Security Standards Council (PCI SSC) in 2006. The initial focus of the Council was to introduce the first revisions to the standard (PCI DSS 1.1) and to manage the PCI DSS moving forward. Since then, there have been a number of significant updates to the standards and to payment card security in general. Here we review some of the updates and changes to the standards and explore some of the circumstances, events and reasons for these modifications.

> Download Now: PCI DSS Compliance Checklist for Call & Contact Centers <>

The Story Behind PCI DSS

Before the PCI DSS, each payment brand created and managed its own security criteria for accepting their branded cards to facilitate payments. In practice, this meant that merchants would have to have reviewed, implemented and certified their payment program to five core regulation schemes – if they wanted to offer their customers the convenience of choosing to pay with almost any branded card in their wallet. While there were a number of significant areas of overlap among these different standards, the variances and the differing reporting methodologies were enough to be a persistent thorn in the side of compliance managers and security teams around the world. Five separate annual Reports on Compliance (ROC) would seem to be 400 percent overkill from today’s reporting requirements.

In 2004, with the unification of these programs to form the PCI DSS, (and the subsequent formation of the PCI SSC in 2006) the inconsistencies of policy and the demands of reporting compliance with multiple programs was removed. These days there is indeed one ROC to rule them all.

But uniting all the card brands around a single data security standard wasn’t the only reason for the formation of the PCI SSC. The Council also allowed for the building of a payment security community or forum incorporating banks, merchants and service providers that helps guide the evolution of the standards. As technology advances and criminal &fraud trends transform, the standards must also evolve to combat the shifting landscape. Feedback from the merchant and payment community plays an integral role in adjusting, augmenting and strengthening the standards to continue to minimize fraudulent activities into the future. In fact, that feedback is of such fundamental importance that it is now built into the lifecycle of the standards themselves.

The Lifecycle for Changes to PCI DSS

The Council has elaborated on the Lifecycle for Changes to PCI DSS (and the Payment Application Data Security Standard, or PA DSS) in a document sharing the planned process between the three-year updates or changes to the standards. Feedback elements make up two of the eight steps in the lifecycle process. The full process is identified by the Council as:

Stage 1: Standards Published

Stage 2: Standards Effective

Stage 3: Market Implementation

Stage 4: Feedback Begins

Stage 5: Old Standards Retired

Stage 6: Feedback Review

Stage 7: Draft Revisions

Stage 8: Final Review

Download Now: PCI DSS Compliance Checklist

Evolving PCI DSS 1.2.1 into PCI DSS 2.0

Now that you understand the process for updates and changes to the standards, what are the significant updates made over the last 10-plus years of the PCI DSS? Let’s look at some of the key revisions introduced in each major update since the standards launched.

Minor changes to the PCI DSS were made in October 2008. An incremental release, the adjustments were now reflected as PCI DSS 1.2; from 1.1). Updates included a few modifications to adjust the standards to provide more guidance on the payment card environment (scope) and relatively minor moves perceived to unify understanding about compensating controls and to tighten security around access controls.

The first major update to the standard was introduced in October of 2010, moving from PCI DSS 1.2.1 to the new PCI DSS 2.0. At this time, the PCI SSC also introduced the community to the planned three-year lifecycle of the PCI DSS, allowing specific periods for feedback, introduction of new standards and then a sunrise period for implementation – barring any emergency provisions or updates.

The primary changes introduced in PCI DSS 2.0 again focused on clarifying processes, providing additional guidance to those interpreting the standards, defining scope of the Demilitarized Zone (DMZ) and the card data environment (CDE) and introducing a few “Evolving Requirements.” These were defined by the Council as “requirement outlining (a) situation not addressed in a standard; ensures the standards are up-to-date with emerging threats and changes in the market.”

A New Era with PCI DSS 2.0

The evolving requirements introduced with version 2.0 included:

Requirement 6.2: Update requirement to allow vulnerabilities to be ranked and prioritized according to risk. This evolution came to be known as the Prioritized Approach to the PCI DSS. This process was hoped to provide a roadmap that an organization can use to address its risks in priority order.

While the stated reason for this update was to apply a risk-based approach for addressing vulnerabilities, more to the point, the Council seemed to want to simply get more people on board with and beginning to implement the PCI DSS in their organizations. Despite the fact that the Council had just celebrated its fourth birthday, at that time compliance rates were still not where the payment brands would have wished. By introducing six simple goals or “milestones,” including things like, “remove sensitive authentication data and limit data retention” and, “protect systems and networks, and be prepared to respond to a system breach,” the intention was the Prioritized Approach would afford organizations a “pragmatic approach that allows for quick wins.”

Additional guidance on the scope of an assessment and on virtualization were also included in this revision.

For the scope guidance, it was a simple matter to, “Clarify that all locations and flows of cardholder data should be identified and documented to ensure accurate scoping of cardholder data environment.”

Regarding virtualization, PCI DSS 2.0 expanded the definition of system components to include virtual components. Requirement 2.2.1 was also updated to clarify the intent of “one primary function per server” when dealing with virtualization.

In a nutshell, those were the major changes in this update to the PCI DSS. At this point in time, organizations were just becoming aware of their obligations and responsibilities to protect cardholder data and compliance rates were slowly increasing. Getting the rest of the populace on board was much more beneficial to the overall health of the payment system than making any dramatic changes just yet. Since most of the requirements in the PCI DSS are common sense best practices for information and data security, it makes sense that there were not wholesale, dramatic changes.

On to PCI DSS 3.0, 3.1, 3.2, and Now 3.2.1!

With version 3.0 of the PCI DSS, the primary drivers for change identified by the Council included:

  • Lack of education and awareness
  • Weak passwords, authentication
  • Third-party security challenges
  • Slow self-detection, malware
  • Inconsistency in assessments

In light of the growing challenge of malware, particularly within point-of-sale devices, the Council updated: the list of common vulnerabilities in alignment with  [1], NIST[2], SANS[3], etc., for inclusion in secure coding practices; and to protect POS terminals and devices from tampering or substitution; and to address requests for more details for penetration tests, and for more stringent card data environment scoping verification of segmented networks.

The Council also sought to address security considerations for authentication mechanisms such as physical security tokens, smart cards, certificates or other methodologies for authentication beyond a password.

Separately from the changes to the PCI DSS introduced in version 3.0, the Council believed it necessary to provide additional guidance on emerging technologies. Specific guidance on the use

of  technologies (including e-commerce, mobile payment acceptance and cloud computing) and how PCI Standards apply within these was released by the Council’s PCI Special Interest Group (SIG).

In later updates (PCI DSS 3.1, 3.2 and 3.2.1) the Council emphasized the importance of validating security controls by adding multi-factor authentication as a requirement for personnel with administrative access into the cardholder data environment; and incorporating the Designated Entities Supplemental Validation (DESV) to help service providers and others address key challenges in maintaining ongoing security efforts to protect payments.

Regarding the latest changes to the PCI DSS, Troy Leach, PCI Security Standards Council Chief Technology Officer said, “With a limited number of changes in PCI DSS 3.2, organizations will be able to focus attention on these type of critical controls, re-evaluate their current approach and address improvements that will help mitigate current points of attack.”

In many ways, this sums up not only the most recent updates, but the history of updates to the PCI DSS as a whole. Because the principles, practices and processes outlined within the standards are common sense and good security hygiene, massive changes should never be necessary. Incremental evolution – treating the PCI Data Security Standard as an evolving, living thing – should prove to be all the security most of us will ever require.

[1] Open Web Application Security Project:

[2] National Institute of Standards and Technology:

[3] The SysAdmin, Audit, Network, and Security Training Institute:

The post Latest PCI DSS Versions: A Look At How the Standard Has Evolved appeared first on Semafone.

*** This is a Security Bloggers Network syndicated blog from Semafone authored by Aaron Lumnah. Read the original post at:

Cloud Workload Resilience PulseMeter

Step 1 of 8

How do you define cloud resiliency for cloud workloads? (Select 3)(Required)