Payment Card Industry Data Security Standard (PCI-DSS) History and Overview

The integrity and security of credit and debit card transactions are critical to both eCommerce and brick-and-mortar retailers alike. Credit card security protections are also critical for consumer to business and business to business financial transactions. Unfortunately, throughout the 1990’s, and to this day, credit card companies have witnessed an astonishing increase in credit card fraud. A major driver in the rise of credit card fraud has been the steady acceptance of eCommerce transactions. Between 1988 and 1999 Mastercard and Visa saw over $750M of losses from online fraud.  In the late 1990’s and early 2000’s multiple credit card brands began introducing their information security initiatives. Visa launched their Cardholder Information Security Program (CISP) in October 1999. Soon after that, Mastercard introduced their Site Data Protection program, American Express introduced their Site Data Protection program and Data Security Operating Policy, Discover introduced their Information Security and Compliance program, and JCB introduced their Data Security program. After a determination that having multiple disjoint security programs across credit card brands was confusing to merchants, the top brands decided to join forces, and the Payment Card Industry Security Standards Council formed in 2004. The first standard, modeled after the Visa Cardholder Information Security Program (CISP), was released on December 15, 2004, called the Payment Card Industry Data Security Standard (PCI-DSS) v1.0.

In contrast to information security requirements in other industries, enforcement of PCI-DSS is not by law or government regulations but rather self-governed by the credit card industry itself. PCI-DSS applies to any company that is part of the credit card processing ecosystem. Companies that are impacted by PCI-DSS includes:

• Merchants, includes any entity that accepts payment cards that bear the logo of one of the five members of the PCI Security Standards Council (American Express, Discover, JCB, MasterCard or Visa).
• Payment card issuing banks, includes any entity that issues payment cards that bear the logo of one of the five members of the PCI Security Standards Council.
• Merchant Bank, Processors, includes any bank or financial institution that processes credit and debit card payments on behalf of merchants.
• Developers, includes any entity that develops software that must meet the PCI-DSS requirement to “develop and maintain secure systems and applications.”
• Assessors, includes any organization that is authorized to validate an entity’s adherence to PCI-DSS requirements, referred to as “Qualified Security Assessors” or “QSAs.”
• Third-party service provider, or TPSPs, includes any organization that stores, processes, or transmits cardholder data on behalf of another entity.

The PCI-DSS framework has not changed dramatically since its first release and includes 6 logically connected information security control group areas. The original PCI-DSS v1.0 standard documented the following high-level control areas:

1. Build and Maintain a Secure Network and Systems, including requirements to install and maintain a firewall configuration to protect data and not to use vendor-supplied defaults for system passwords or security parameters.
2. Protect Cardholder Data, including requirements to protect stored data to encrypt the transmission of cardholder data and sensitive information across public networks.
3. Maintain a Vulnerability Management Program, including requirements to use and regularly update anti-virus software and to develop and maintain secure systems and applications.
4. Implement Strong Access Control Measures, including requirements to restrict access to data by business need-to-know, assigning a unique ID to each person with computer access to restrict physical access to cardholder data.
5. Regularly Monitor and Test Networks, including requirements to track and monitor all access to network resources and cardholder data and to regularly test security systems and processes.
6. Maintain an Information Security Policy, including requirements to maintain a policy that addresses information security.

Although the foundational framework of PCI-DSS has not changed since the inception of PCI-DSS, numerous incremental changes and improvements have occurred. High-Level release history of PCI-DSS is below:

• PCI v1.1, released in September of 2006, introduced improvements in web application security issues.
• PCI v1.2, released in October of 2008, introduced improvements to address wireless issues.
• PCI v1.2.1, released in August of 2009, introduced clarification improvements in multiple areas.
• PCI-DSS v2.0, released in October of 2010, was designed to provide greater clarity and flexibility to facilitate improved understanding of the requirements and eased implementation for merchants.
• PCI-DSS v3.0, released in November of 2013, introduced changes to help organizations make payment security part of their business-as-usual activities by introducing more flexibility and an increased focus on education, awareness, and security as a shared responsibility.
• PCI-DSS v3.1, released in April of 2015, introduced supporting guidance to help organizations address vulnerabilities within SSL protocol that put payment data at risk.
• PCI-DSS v3.2, released in April of 2016, introduced requirements to address growing threats to customer payment information.
• PCI-DSS v3.2.1, released in May of 2018 introduced minor updates to account for SSL/Early TLS dates that had passed.

Over the years, since PCI-DSS v1.0 was released, the Payment Card Industry Security Standards Council has introduced additional standards to address specific areas of cardholder security not addressed directly by the core PCI-DSS standard. These supplemental security standards include:

• Payment Application Data Security Standard (PA-DSS), defines security requirements and assessment procedures for software vendors of payment applications. Although the PA-DSS guidelines are derived from the PCI-DSS requirements, using a PA-DSS compliant application does not by itself make an entity PCI-DSS compliant.
• PIN Transaction Security (PTS), defines requirements against which vendor products will be evaluated to obtain Payment Card Industry (PCI) PIN Transaction Security (PTS) Point of Interaction (POI) device approval.
• PCI Point-to-Point Encryption Standard (P2PE), defines requirements to ensure secure encryption of payment card data and secure management of encryption and decryption devices.
• PCI Card Production Logical Security Requirements and Physical Security Requirements, defines physical and logical security requirements for entities involved in card production and provisioning, which may include card manufacturers, personalizers, pre-personalizers, chip embedders, data-preparation, and fulfillment companies.
• PCI Token Service Provider Security Requirements, defines additional security requirements and assessment procedures for Token Service Providers (i.e., EMV Payment Tokens).

The current version of the security standard (available at the time of this article’s publish date) is PCI-DSS v3.2.1, released in May of 2018. The PCI data security standard delivers documentation of technical and operational requirements that are designed to protect credit card account data. PCI-DSS applies to all entities involved in payment card processing—including merchants, processors, acquirers, issuers, and service providers. The following sections provide some background fundamental information on the PCI-DSS standard.

Entities that must meet the burden of PCI-DSS have their hands full. There are too many PCI-DSS “fundamentals” to cover in a high-level article like this – however, there are some very important fundamentals worth mentioning. We describe a few of these fundamentals below:

• Acquirers vs. issuers – although the PCI-DSS requirements impact many entities it is important to understand the difference of a payment “acquirer” and “issuer.” All payment card transactions involve two entities: (1) the financial institution representing the cardholder or “issuing bank” and (2) the financial institution representing the merchant or “acquiring bank.” In some instances, a larger financial institution may represent either party and act as both a payment acquirer and issuer. Each entity–the payment acquirer and issuer–has the burden of meeting the PCI-DSS requirements.
• Service providers vs. merchants – aspects of PCI-DSS can sometimes be confusing to entities that must adhere to the standard. One such area is understanding the difference between an entity acting as a “service provider” versus one acting as a “merchant.” The PCI Security Standards Council define a “service provider” as “any business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data. This also includes companies that provide services that control or could impact the security of cardholder data” and define a “merchant” as “any entity that accepts payment cards bearing the logos of any of the five members of PCI SSC (American Express, Discover, JCB, MasterCard or Visa) as payment for goods and/or services.” In some cases, an entity may act as both a service provider and a merchant. It is important for any entity that processes payment card data to be aware of their classification(s) in order to remain compliant with the standard.
• Business as Usual (BAU) PCI Compliance – Most information security professionals and compliance experts agree that being “compliant” with a regulation does not translate to being “secure.” Achieving successful point-in-time (e.g., annual or quarterly) compliance assessments as mandated by a requirement, like PCI-DSS, may be required. However, it is important to understand that new risks may emerge the day after the closing of an audit. Current guidance is that PCI affected organizations integrate PCI-DSS mandated controls into day-to-day operations, or “business as usual.” Introducing BAU compliance requires integrating appropriate people, processes, and technology into business operations to minimize the risk of a data breach on a continuous basis. Although PCI validation is performed once a year, it is of increasing importance for ensuring compliance year-round. First, PCI affected organizations have a contractual obligation to meet the PCI standard on a continuous basis. Second, organizations that are found to be out-of-compliance may incur fines and penalties. And third, it is the right thing to do to protect the data of customers.

A fundamental objective of PCI-DSS is protecting cardholder data. To this end, the PCI-DSS standard details specific cardholder data that require specific data protections. An overview of this data is below:

• PAN – Acronym for “primary account number” and also referred to as “account number.” Unique payment card number (typically for credit or debit cards) that identifies the issuer and the particular cardholder account.
• Cardholder Name – the non-consumer or consumer customer name to whom a payment card is issued to or any individual authorized to use the payment card.
• CAV/CID/CVC2/CVV2 – a data element on a card’s magnetic stripe that uses secure cryptographic processes to protect data integrity on the stripe and reveals any alteration or counterfeiting. Referred to as CAV, CVC, CVV, or CSC depending on payment card brand. The following list provides the terms for each card brand
• Chip or Magnetic Strip Data – also referred to as “full track data” or “magnetic-stripe data.” Data encoded in the magnetic stripe or chip used for authentication and authorization during payment transactions. Can be the magnetic-stripe image on a chip or the data on the track 1 and track two portions of the magnetic stripe.
• Sensitive Authentication Data – a combination of the user ID or account ID plus the authentication factor(s) used to authenticate an individual, device, or process.

Although the PCI-DSS standard is common across all cardholder brands, actual compliance requirements vary by the different bank brands. It is important for any PCI affected organization to work with their cardholder bank(s) to understand the specific requirements that apply to them. Most all cardholder banks have similar concepts in their compliance requirements, including:

• Compliance Levels – cardholder brands segment affected organizations into “levels” based on certain criteria including the volume of credit card transactions an entity performs per year. The number of compliance levels varies by cardholder brand. For example, VISA has four levels, and MasterCard has 5. It is important for an organization to know their classification level because it dictates what needs to be achieved to be “compliant.” Links to an overview of the compliance level of each cardholder brand are below:
  • Discover
  • MasterCard
  • Visa
  • American Express
  • JCB
• Assessment Questionnaires – The Payment Card Industry Security Standards Council has developed self-assessment questionnaires (SAQ) to help service provider and merchant entities assess the security of their cardholder data. A PCI-DSS self-assessment is a great first step for any organization that wants to understand the implications of PCI on their organizations.
• Attestation of Compliance – An Attestation of Compliance or certification is required by some bank brands to validate that an organization is eligible to perform and has performed the appropriate Self-Assessment. An appropriate Attestation gets packaged with each Questionnaire that an organization completes.
• The scope of Applicability – As with any information security program, it is important to understand the scope across which PCI requirements apply. It is often helpful to construct specific segmentation in people, processes, and technology to reduce the scope across which PCI applies. Determining the scope across which PCI applies is important because it can uncover un-addressed areas where PCI requirements apply. For example, entities that transmit cardholder data (and do not store cardholder data) does not mean that certain PCI requirements are applicable. Similarly, organizations that outsource cardholder processing may still have a PCI burden.

The Payment Card Industry Security Standards Council and cardholder brands have adopted a fundamental information security best practice – differentiating between an entity achieving “compliance” and having an audit practice in place to “validate compliance.” What PCI-DSS requires in these two areas will differ based on an organization’s compliance level. For some smaller organizations, the process of achieving compliance and validating compliance may require completing a self-assessment and then validating their assessment via an attestation of compliance. For many organizations, validation requires working with a “Qualified Security Assessors” or “QSA”: independent companies that have been certified by the PCI-SSC to validate an entity’s adherence to PCI-DSS.

Any organization that has a PCI burden should engage with a QSA or perform self-assessment to determine their requirements. Validation of PCI compliance requires:

• Determining Scope – the process by which a PCI affected organization determines and documents the scope across systems and process where PCI requirements apply.
• Assessing Requirements – the process by which a PCI affected organization determines and documents which requirements of PCI apply based on scope.
• Implement Controls – a process where an organization implements technical and procedural controls as required by PCI.
• Report – a process where an organization documents how PCI requirements are met, including documentation of known compliance gaps.
• Attest – a process where an organization submits an attestation to a cardholder bank that represents that supporting materials are true and accurate.
• Submit – a process where an organization submits required materials to cardholder banks for review.
• Remediate – the process of addressing issues that affected an organization's ability to achieve compliance.

Several programs and supporting materials have been developed by the PCI-SSC to assist organizations to navigate their journey to PCI compliance. A few of these programs include:

• Qualified Security Assessors (QSA) – provides the ability of an organization to enlist outside help to navigate the PCI assessment process and validate an entity's adherence to PCI-DSS. Qualified security assessors are independent security businesses that have been qualified by the PCI-SSC to validate and document an entity's compliance with PCI-DSS.
• Internal Security Assessor (ISA) – a program to train in-house staff to perform internal PCI-DSS assessments and recommend solutions to remediate issues related to PCI DSS compliance.
• Self-Assessment Questionnaire (SAQ) – a library of questionnaires to help organizations self-assess the security posture of cardholder data they manage. There are multiple questionnaires for different types of organizations including (as provided by the PCI-SSC):
  • Questionnaire A – Card-not-present merchants (e-commerce or mail/telephone-order) that have fully outsourced all cardholder data functions to PCI DSS compliant third-party service providers, with no electronic storage, processing, or transmission of any cardholder data on the merchant’s systems or premises.
  • Questionnaire A-EP – E-commerce merchants who outsource all payment processing to PCI DSS validated third parties and have a website(s) that does not directly receive cardholder data but that can impact the security of the payment transaction—no electronic storage, processing, or transmission of any cardholder data on the merchant’s systems or premises.
  • Questionnaire B – Merchants using only:
    • Imprint machines with no electronic cardholder data storage; and
    • Standalone, dial-out terminals with no electronic cardholder data storage.
  • Questionnaire B-IP – Merchants using only standalone, PTS-approved payment terminals with an IP connection to the payment processor—no electronic cardholder data storage.
  • Questionnaire C-VT – Merchants who manually enter a single transaction at a time via a keyboard into an Internet-based virtual terminal solution that is provided and hosted by a PCI DSS validated third-party service provider—no electronic cardholder data storage.
  • Questionnaire C – Merchants with payment application systems connected to the Internet—no electronic cardholder data storage.
  • Questionnaire P2PE-HW – Merchants using only hardware payment terminals that are included in and managed via a validated, PCI SSC-listed P2PE solution—no electronic cardholder data storage.
  • Questionnaire D – For Merchants: All merchants not included in descriptions for the above types or Service Providers: all service providers defined by a payment card brand as eligible to complete a Self-Assessment Questionnaire.
• Report on Compliance (ROC) – a document template that must be completed by a Qualified Security Assessor to document that requirements of PCI-DSS have been met on behalf of a company working to achieve PCI compliance.
• Approved Scanning Vendor (ASV) – independent security businesses that have been qualified by the PCI-SSC to conduct vulnerability scanning to ensure an entity in compliance with PCI-DSS section 11.2.2 (to perform quarterly external vulnerability scans).

CI-DSS enforcement is not performed by the PCI-SSC but rather by the payment card brands. As mentioned previously, each payment card brand defines their respective requirements and enforcement guidelines. Established enforcement relationships exist between various PCI affected entities, including:

Merchants and Acquiring Bank(s)

Contractional obligations between the merchant and their acquiring bank(s) determine enforcement requirements for a merchant. Entities get classified by their acquiring bank(s) based on transaction volume. Each bank determines the validation requirements for each payment card brand. Enforcement to PCI-DSS is managed by acquiring bank(s) and can include specific penalties for non-compliance.

Service providers and Merchant(s) or Acquirer(s)

Contractual obligations between a service provider and their merchant(s) or acquiring bank(s) determine enforcement requirements of the service provided. Entities get classified by their payment card brands based on transaction volume. Each bank determines the validation requirements for each payment card brand. Enforcement to PCI-DSS is managed by acquiring bank(s) and can include specific penalties for non-compliance.

Example: Visa CISP Program

The Visa Cardholder Information Security Program (CISP) provides an example of how a payment card brand manages compliance for any entity that store, process, or transmit Visa cardholder data. Visa’s program provides the framework for entities to demonstrate compliance with PCI-DSS on a regular basis and define penalties for non-compliance. Important information on the Visa CISP program is below:

Merchant Levels

Visa defines four merchant levels in the program. It is important to note that some levels differentiate between Visa e-commerce transactions versus transactions from other channels (i.e., any transaction other than an e-commerce transaction). A summary of these levels is below:

• Level 1 – Merchants that process over 6 million Visa transactions annually (across all channels).
• Level 2 – Merchants that process 1-6 million transactions annually (across all channels).
• Level 3 – Merchants that process 20,000-1 million Visa e-commerce transactions annually.
• Level 4 – Merchants that process less than 20,000 Visa e-commerce transactions annually or any merchant that processes up to 1 million Visa transactions annually.

Validation Procedures & Documents for Each Merchant Level

It is a good practice (because of occasional updates to the CISP program) that any PCI affected entity review the validation procedures and documents for their merchant level. At the time this article was published, the following compliance validation guidelines describe Visa’s validation procedure for each merchant level:

* We recommend the internal auditor obtain the PCI SSC Internal Security Assessor (“ISA”) certification.

The Payment Card Industry Data Security Standard (PCI-DSS) affects any entity that stores, processes, or transmits data for any of the cardholder brands that are part of the Payment Card Industry Security Standards Council (PCI-SSC). Each cardholder brand (e.g., Visa, Mastercard, American Express, Discover, and JCB) defines guidelines on what is required to achieve compliance validation. Each cardholder brand defines merchant tiers that directly map how an entity must validate adherence to the PCI-DSS standard. To deliver validation consistency across brands, the PCI-SSC has introduced multiple programs including standardized self-assessment questionnaires (SAQ), report on compliance (ROC), and attestation on compliance (AOC). The payment card brands determine what process each affected entity must follow to validate that PCI requirements are met. Also, the PCI-DSS has introduced programs to approve qualified third-party security companies to assist affected entities meet their PCI-DSS requirements. Two helpful resources in this are qualified security assessors (QSA) and approved scan vendors (ASV). Although the task of meeting PCI-DSS may seem burdensome, it is necessary to combat today’s threat of data breach of cardholder data. When trying to navigate the landscape of PCI-DSS compliance, especially for entities that process large transaction volumes, it is important to develop a strong relationship with a qualified security assessor (QSA).