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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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.
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.
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:
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:
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).