From 1999 to 2017: PCI Continues to Evolve

The origins of the Payment Card Industry Data Security Standard (PCI DSS) go back to the late 1990s – the dawn of the Internet era, but despite its humble beginnings, the PCI DSS has come a long way. What began as a customer security proPCIgram at VISA is now a regulatory body for nearly all retailers who want to use credit cards. Sword & Shield Enterprise Security Consultant Joe Gray takes a look back and explains why PCI is important for security, as well as compliance.


As cybersecurity professionals, we consistently deal with compliance and the recurring debate of security versus compliance. While the two are related, in many aspects similarly to how security also relates to privacy, they are distinctly different. Compliance in the traditional sense is a measurement of adherence of a defined security standard, framework, and/or policy or policies  at a point or point(s) in time.

Regardless of where you stand in the debates, compliance has become a fact of life in information security. In the healthcare segment, we have the Health Insurance Portability and Accountability Act of 1996 (HIPAA) and the Health Information Trust Alliance (HITRUST). Other compliance requirement include the Federal Information Security Management Act of 2002 (FISMA) for federal information systems and the International Organization for Standardization (ISO) 27000, which is a cornerstone of many compliance frameworks. While HIPAA and FISMA are implemented via federal law or regulation, ISO and Payment Card Industry (PCI) vary in that they are independent compliance regulations.


PCI is unique in the sense that it is not mandated via a law or regulation and it addresses a specific market segment or “vertical” via self-governance. Before the PCI/DSS (Payment Card Industry Data Security Standard), each card issuer – Visa, MasterCard, Discover, American Express, and JCB had separate security standards. These companies cumulatively lost between $500 million and $1 billion from credit card fraud. While each were similar, there were variances in each which was difficult for any organization doing business with more than one issuer to maintain the difference in requirements and terminology.

The Core Requirements for PCI are:

  1. Install and maintain a firewall configuration to protect cardholder data
  2. Do not use vendor-supplied defaults for system passwords and other security parameters
  3. Protect stored cardholder data
  4. Encrypt transmission of cardholder data across open, public networks
  5. Use and regularly update anti-virus software on all systems commonly affected by malware
  6. Develop and maintain secure systems and applications
  7. Restrict access to cardholder data by business need-to-know
  8. Assign a unique ID to each person with computer access
  9. Restrict physical access to cardholder data
  10. Track and monitor all access to network resources and cardholder data
  11. Regularly test security systems and processes
  12. Maintain an information security policy


While the companies were, and still are, competitors, they came together to define a uniform standard. PCI DSS 1 was born in 2004. Over the course of the 6 years that PCI/DSS 1 was the standard, it underwent 2 major and 1 minor changes. All parties in the payment processing life cycle were subject to the requirements. With version 1.1, The PCI Security Standards Council (SSC) was created and formal requirements for Web Application Firewalls (WAFs) were mandated to address E-Commerce issues. Version 1.2 saw additional requirements for anti-virus and 802.1x wireless authentication. The final stride of PCI/DSS 1 was the change from 2 year cycles to 3 year cycles, which mean less time auditing and more time implementing and self-assessing.


PCI/DSS Version 2 came to existence in late 2010. While few surprises came out of it for the most part, some changes occurred. Through the lifetime of PCI/DSS Version 2, we saw additional requirements for virtualization, tokenization, and peer-to-peer (P2P) encryption. Through the remaining period of PCI/DSS’s 6 years of existence, we also saw compliance hit a record high and rules for mobile applications. In late 2013, PCI/DSS 3.0 was announced.


Today, we use PCI/DSS 3.2. Major changes from previous versions include multi-factor authentication (MFA), incorporation with the Designated Entities Supplemental Validation (DESV), and a continuation of migrating from all versions of Secure Sockets Layer (SSL) encryption and Transport Layer Security (TLS) version 1.0 in favor of TLS 1.1 and 1.2. Provisions for service providers have been added to the requirements in version 3.x as well. Based on analysis of timing of previous major releases of PCI, we can expect PCI 3.x to exist through 2018, or longer.


There are a few terms and definitions that are common within PCI. This is a section where I examine some of them to help your comprehension of lingo you may hear in audits and assessments or, if you routinely work with PCI, in the office.

  • Approved Scanning Vendor (ASV): Company approved by the PCI SSC to conduct external vulnerability scanning services.
  • Audit: A PCI compliance audit assesses a merchant’s point-of-sale (POS) system by examining it, identifying vulnerabilities and instituting precautions to prevent data from being compromised.
  • ISA (Internal Security Assessor): The ISA Program provides an opportunity for eligible internal security audit professionals of qualifying organizations to receive PCI DSS training and certification that will improve the organization’s understanding of the PCI DSS, facilitate the organization’s interactions with QSAs, enhance the quality, reliability, and consistency of the organization’s internal PCI DSS self-assessments, and support the consistent and proper application of PCI DSS measures and controls.
  • QSA (Qualified Security Assessor): QSAs are qualified by PCI SSC to perform PCI DSS on-site assessments.
  • Penetration Test: Penetration tests attempt to identify ways to exploit vulnerabilities to circumvent or defeat the security features of system components. Penetration testing includes network and application testing as well as controls and processes around the networks and applications, and occurs from both outside the environment (external testing) and from inside the environment.
  • Report on Compliance (ROC): a form that has to be filled by all level 1 merchants Visa merchants undergoing a PCI DSS (Payment Card Industry Data Security Standard) audit. The ROC form is used to verify that the merchant being audited is compliant with the PCI DSS standard.
  • Report on Validation (ROV): Report documenting detailed results from a PA-DSS assessment for purposes of the PA-DSS program.
  • Self-Assessment Questionnaire (SAQ): a set of Questionnaires documents that merchants are required to complete each and every year and submit to their transaction Bank.


While PCI is not perfect – no compliance framework is – it is the result of self-governance and now raises the bar for vulnerability assessments, password management and provider compliance. The PCI Council has resolved to continue to strengthen its controls as threats and technology change. Expect to see PCI grow in the following years as credit card data is still a lucrative target for attackers.

Joe Gray is an enterprise security consultant with Sword & Shield Enterprise Security, Inc. He has worked as a systems engineer, information systems auditor, senior UNIX administrator, information systems security officer and director of IT security. 

He holds the (ISC)² CISSP-ISSMP, GIAC GSNA, GCIH, CompTIA Security+, CompTIA Network+, and CompTIA A+ certifications. 


  1. […] This blog post originally appeared on Sword & Shield’s Blog on 12 January […]

  2. […] Sword & Shield Blog Hosted Locally on Advanced Persistent Security […]

  3. […] Sword & Shield Blog Hosted Locally on Advanced Persistent Security […]