Keep up to date and subscribe free to this site. Just enter your e-mail address
Powered by VerticalResponse

Payment Card Industry Data Security Standard (PCI-DSS)

Abhay Bhargav

The Payment Card Industry Data Security Standard (PCI-DSS) is perhaps the most well-known standard in the family of standards developed and maintained by the Payment Card Industry Security Standards Council (PCI-SSC). The standard applies to environments that store, process, or transmit payment-card information. This article explains some peripheral aspects of the PCI-DSS with reference to compliance for enterprises the world over. It also explains some of the validation levels and requirements for various entities that are to be assessed and certified for PCI compliance. It briefly delves into some business models of companies that typically undergo PCI compliance. Finally, the article discusses different compliance options and possibilities for entities that are undergoing PCI compliance.

A Brief History of the PCI-DSS

The PCI-DSS is one of the most significant compliance requirements in the world today. It has been enforced and adopted across the world by payment brands, acquirers, and issuers on their respective payment ecosystems, thereby resulting in several compliant and certified companies.

The reason for the creation of the PCI-DSS relied on the fundamental concepts of singularity and threat. Around 1999, Visa's Cardholder Information Security Program (CISP) had taken shape. It was a standard created by Visa for companies that were storing, processing, or transmitting Visa-branded cards. This included merchants, service providers, etc. In 2001, the CISP became a standard for Visa's ecosystem of acquirers, issuers, merchants, and service providers. At around the same time, MasterCard released its Site Data Protection (SDP) program, which was very similar to Visa's standard. This program was a set of security compliance requirements that entities that stored, processed, or transmitted MasterCard cardholder information had to adhere to. At around 2003, American Express created its own security compliance program for its ecosystem. At the time, merchants, service providers, and other entities under the scope of compliance would have to go through multiple validations by assessors from different payment brands. This situation had the potential to create a great deal of inconvenience owing to the fact that multiple payment brands would have to assess and validate an entity, even though the protection requirements for the various payment brands were similar, for the most part.

There was a clear need for a unifying standard that would provide a singular route to compliance for entities under the purview of PCI compliance. This prompted the creation of the unifying standard known popularly as the PCI-DSS. The PCI-SSC (Security Standards Council) was created in 2004. All the payment brands—Visa, MasterCard, JCB, American Express, and Discover—came together to form an independent entity that would govern the standards relating to the payment card industry as well as manage and promulgate the standard.

After the formation of the PCI-SSC, the massive CardSystems breach occurred in 2005. During the year, the PCI-SSC stated that approximately 235 million card records had been breached thus far, demonstrating the need for a regulatory entity to govern and manage security for the payment card industry.

In September 2006, the PCI-DSS version 1.1 was released by the PCI-SSC. The standard consisted of 12 requirements, ranging from security requirements on networks to physical security, documentation, and risk management. The year 2007 was the proverbial annus horribilis for information security and the payment card industry because of the high-profile breaches of T.J. Maxx, Hannaford, Shell, and other companies. Millions of cardholder information records were stolen as part of these attacks. This increased the need for PCI compliance and also increased the pressure on the payment ecosystem by the payment brands and, in some cases, regulatory laws and requirements to impose security standards on the payment card industry.

In October 2008, the PCI-SSC released the PCI-DSS v 1.2. This version of the standard had certain changes and clarifications based on the previous versions of PCI-DSS. There were also several aspects relating to wireless implementations, virtualization, and encryption that were illuminated in the PCI-DSS v 1.2. The next version of the standard was v 1.2.1, released in August 2009. There were very minor changes in the standard at this time, with the PCI-SSC terming the changes as "administrative." There were some clarifications, supporting documents, etc., in this version of the standard.

Business models and technology undergo constant change, and it is essential that a security standard keep pace with this change. The PCI-DSS also undergoes change based on the change cycle defined by the PCI-SSC. (See Chapter 3 in the book PCI Compliance for further discussion about the PCI change cycle.) At the time of this writing, the latest standard from the PCI-SSC relating to the PCIDSS is the PCI-DSS v 2.0. This version of the standard has 130 amendments to the previous version. There have been several new issues that have been clarified and supported, relating to virtualization, Web application security, cloud computing, encryption, and so on.

PCI Compliance Levels: Payment Brands

Payment Brand Compliance Programs and PCI-DSS

The creation of the PCI-DSS has brought a great deal of structure to the payment card industry compliance process. Organizations have to comply with a single, unifying standard (i.e., the PCI-DSS), and they have to be assessed and validated against the 12 requirements of the PCI-DSS. Their adherence to the requirements allows them to be either certified or otherwise against the PCI-DSS.

The compliance programs for each of the payment brands like Visa, MasterCard, American Express, and so on, are still applicable. If an organization complies with the PCI-DSS, the organization does not automatically comply with these individual compliance programs. The organization has to obtain a certification and present a report on compliance to each of the payment brands. Upon examination of the documentation and a (possible) certification of PCI-DSS by a qualified security assessor (QSA), the organization complies with individual cardholder security programs of the different payment brands. While the compliance processes for these cardholder information security programs are not automatically fulfilled because of the PCI-DSS compliance and certification, it is the most essential requirement for compliance with individual cardholder security programs from payment brands.

Compliance Levels and Compliance Requirements

Any entity that stores, processes, or transmits cardholder information must comply with the PCI-DSS. However, based on the number of cardholder information records stored, processed, or transmitted by the entity, the level of compliance with the individual cardholder security program changes. For instance, if entity ABC is processing around 50,000 Visa cards per year, then the entity would have to comply with the PCI-DSS. However, they may be able to fill out a self-assessment questionnaire and perform the external vulnerability assessment by an approved scanning vendor (ASV) to comply with the PCI-DSS. However, if merchant XYZ was processing more than 6 million Visa cards, then the merchant would have to have the scoped environment assessed by a PCI-QSA and have an external vulnerability assessment by an ASV to comply and certify, based on the PCI-DSS requirements.

Each payment brand has multiple compliance levels that are specified for different types of entities like merchants and service providers. Let's tabulate these levels.

Table 1.

Visa Merchant and Service Provider Validation Levels

Table 1 contains the merchant levels for Visa's compliance. The validation for each merchant level is dictated by the transaction volume. Similarly, service providers storing, processing, or transmitting cardholder information also have multiple validation levels for their compliance with Visa. They are listed in Table 2.

Table 2.

MasterCard Merchant and Service Provider Validation Levels

The MasterCard merchant and service provider compliance validation levels are listed in Tables 3 and 4, respectively.

Table 3.

Table 4.

MasterCard considers third-party processors in the payment card industry as Level 1 service providers. They are also referred to as TPPs. The other class of service providers as defined by MasterCard is called a data storage entity (DSE). The compliance validation levels for these entities are defined by the transaction volume of MasterCard card records that are stored, processed, or transmitted.

American Express Merchant and Service Provider Compliance Validation Levels

The American Express merchant and service provider compliance validation levels are listed in Tables 5 and 6, respectively.

Table 5.

Table 6.

Compliance Validation Levels: Identification and Implementation

The compliance validation levels for each of the payment brands also change based on the region in which they are operating. For instance, there may be some minor changes to the compliance validation between Visa Asia Pacific and Visa CEMEA (Central Europe Middle East and Africa).

The transaction volumes that have been provided in the tables are determined by the acquirer that the merchant or the service provider reports to. In the case of a franchise model, the transaction volume is determined by the model of "Doing Business As" (DBA) or a chain of stores. This does not mean that it applies to the corporation owning several chains. For instance, if a corporate entity has several franchise locations that are not owned by the corporation, then for the purposes of identifying transaction volumes, the following will have to be considered:

  • The number of payment cards processed by the entity in corporation owned locations.
  • The number of transactions handled by the corporation on behalf of the franchise owners, if any.
  • If the payment-card processing is routed through the corporation's infrastructure, then the number of cards processed is determined to establish the compliance validation level of said corporation.

PCI-DSS: Applicability

Applicability of PCI Compliance and Interplay with Compliance Validation Requirements

After learning about the various levels of PCI compliance, one might be inclined to ask the following question: "Does that mean that merchants/service providers below Level 1 that are required to only go through self-assessment or that have to consult with their acquirer have to comply with only some parts of PCI-DSS?" The answer to that question is a simple "No."

Merchants and service providers have to get compliant with PCI-DSS. This means that they have to adhere to all the PCI-DSS requirements that apply to them. Failure to adhere to even one of the applicable requirements without a suitable compensatory control will result in them being noncompliant with PCI-DSS. The PCI-DSS is not a self-directed standard like the ISO-27001, where an organization can choose the controls it wants to adopt.

However, it also does not mean that organizations have to mandatorily comply with every single one of the 12 broad requirements of the PCI-DSS. Organizations must simply adhere to requirements that apply to them. For instance, if a service provider is not storing cardholder data at all, and merely transmitting the information over an encrypted channel, then the requirements relating to "Protection of Stored Cardholder Information" will not apply to that service provider.

Another example would be in the case of an application (app) development organization that was developing an e-commerce application for its client that is undergoing PCI compliance. In this case, the app development organization would have to attain PCI compliance because its principal organization is obtaining compliance, and a key aspect of its card-management operations (in the form of the customized e-commerce application) will be deployed in the principal's environment. However, let us assume, that the app development organization only does the development of the application, does not come in contact with live card numbers, and only uses test card numbers to test the card-processing aspect of its e-commerce application. In this case, several requirements relating to protection of stored cardholder information and to protection of cardholder information in transit will not apply to the application development organization.

The next question relates to compliance validation. Compliance validation does not mean that merchants and service providers below Level 1 have to comply with a diluted version of the PCI-DSS. It just means that they can choose to fill out a self-assessment questionnaire (SAQ), which is very similar to the report on compliance (RoC) that is filled out by the PCI-qualified security assessor (QSA). The only difference would be that this form is filled out by the representatives of the organization, who have internally assessed the organization for compliance and have found the organization to be compliant with the applicable requirements of the PCI-DSS.

Merchant Organizations

Merchants are an important target group of the PCI-DSS. Merchants traditionally have the highest instance of the storing, processing, or transmitting of cardholder information the world over. Merchants may be both traditional brick-and-mortar merchants with card-management operations in physical establishments, or they may be online merchants where they accept payment cards in exchange for goods and services. In many cases, merchants have both physical "card present" operations and online "card not present" operations.

However, there are some merchant organizations where some requirements of PCI will not necessarily apply because their access to cardholder information is either limited or nonexistent. For instance, let us take a physical merchant establishment that accepts payment cards in its store. The merchant uses a bank (service provider)provided card-processing machine. The cards are swiped on these machines, and the card number or any additional detail relating to the card is not stored anywhere in the environment. In fact, the card number is also masked in the customer's charge slip that is provided to the merchant. In such cases, this merchant may not even be required to become PCI-compliant because there is no storage, processing, or transmission. The merchant is not storing any cardholder information. The merchant is not processing it either; the machine provided by the merchant's service provider is processing the transaction and is out of the merchant's scope. The merchant is transmitting the card information only via the machine provided by the service provider, which is, again, out of scope. Therefore, the merchant may effectively be removed from PCI compliance.

In a similar instance for an online commerce merchant, the merchant redirects the user to a payment gateway, where all the card details are entered and the transaction is processed subsequently, with only an authorization code appearing in the database of the online commerce site. The site does not store, process, or transmit cardholder data, thereby technically negating the need for PCI compliance.

PCI compliance for merchants is mostly driven by the acquiring banks. Acquirers are required by the payment brands to get their ecosystem compliant and certified with the PCI requirements to prevent card fraud and other card breaches. Merchants below a certain level, for instance, Level 4 merchants, may be required to first consult with their acquiring bank about whether they need to achieve PCI compliance in the first place.

Service Providers: Processors

Payment processors have to be compliant with PCI-DSS. Processors have higher instances of storage, processing, and transmission of cardholder information than most other entities. Payment processors may be acquiring processors or issuing processors or both. In the case of acquiring processors, they acquire the transactions from the merchants (and on behalf of the banks). Subsequently, they route the transactions to the right payment brand and finalize the transaction on the return from the payment brand with either an approval or decline of the transaction. In such cases, cardholder information is only processed and transmitted by the processor. However, if the processer issues cards as well, then the processor is responsible for the generation of cards for several banks. Generation includes handling the form, embossing the card, PIN mailers, etc. In such cases, processors store a great deal of information relating to the card and cardholder.

Service Providers: Everybody Else

The other class of service providers in the eyes of the PCI-DSS is those service providers that provide support functions to merchants, banks, and processor service providers. These may include companies that develop customized payment applications, call centers, and business process outsourcing centers (BPOs), among others. PCI-DSS for these companies is largely driven by their clients and principals that happen to be merchants, banks, or other service providers undergoing PCI compliance. For instance, if a bank has outsourced the collection for its credit cards to a BPO in India, then the bank will have to ensure that its service provider, which is handling the bank's card data, is compliant with the requirements of the PCI-DSS. In fact, Requirement 12.8.4 of the PCI-DSS requires that organizations track and monitor the status of their service providers' PCI compliance at least annually.

Cloud Service Providers

At the time of this writing, PCI-SSC released a new information supplement for cloud computing through its Special Interest Group on Cloud Computing. Cloud computing is a form of distributed computing that has gained in acceptance and popularity. Organizations deploy their services on the cloud to realize cost, efficiency, and management gains. However, there are various aspects of security that have to be thought out in depth, especially from a security standpoint. Security over cloud services is usually shared between the cloud service provider and its clients. There are different types of cloud deployments, they are:

  • Private cloud: As the name suggests, private cloud refers to cloud infrastructure that is provided for a single client. This cloud infrastructure is managed either by the organization or the cloud service provider. The infrastructure may be either on the premises of the client or in the service provider's location. For instance, a major telecom company has a private cloud that has been set up by a leading IT services company. The private cloud is dedicated only to the telecom company and has been hosted by the IT services company in their data center.
  • Community cloud: Community cloud refers to infrastructure shared by several organizations that share requirements or business-model considerations. It is managed by a cloud service provider and may be on or off the premises.
  • Public cloud: This refers to cloud infrastructure that is available to the general public or to a specific industry. It is owned and managed by a cloud service provider.
  • Hybrid cloud: Hybrid cloud is an amalgamation or two or more cloud services (private, public, or community). Hybrid clouds are utilized for load balancing and capacity requirements. For instance, a public cloud of a major ticket-booking service provider might utilize the resources of its private cloud when there is a great demand for capacity on its public cloud.

There are three major cloud service models. They are as follows:

  • Software as a service (SaaS) : This model is where the cloud service provider provides the software on the cloud for its customers to use. The customer has very little control over the application, infrastructure, and resources. The customer may be able to change some application configuration settings on the application.
  • Platform as a service (PaaS) : This model is where the cloud service provider provides an application platform for its clients to develop and deploy applications. The client is responsible for developing and deploying the application on a platform. However, the client has no visibility into the hardware infrastructure, the operating systems, or the platform infrastructure resources that have gone into developing/deploying the platform for the client to use.
  • Infrastructure as a service (IaaS) : Some cloud service providers provide infrastructure for the client to control and manage. For instance, the client is provided with servers or server infrastructure on which the client can deploy any operating system of choice, applications, and so on. Often clients also have the ability to define their firewall rules, security configurations, and so on.

The responsibility of PCI compliance differs on the cloud service model adopted by the client. In a SaaS scenario, the cloud service provider has the responsibility to achieve PCI compliance, as the client has little or no control over the application or the infrastructure. However, the client must achieve PCI compliance for other operations handling cardholder data like physical point-of-sale (POS) billing, and so on. I recently was consulting with a company that provided end-to-end merchant payment solutions. This company set up and managed e-commerce portals for small merchants and provided payment-gateway integration. In this case, the end-client (the merchant) has no control over the application or the cardholder data. This was similar to the SaaS model of cloud computing and, therefore, the onus was on the cloud service provider to achieve PCI compliance and certification.

Similarly, in a PaaS scenario, the responsibility and applicability is shared between the client and the cloud services provider (CSP). The CSP must achieve compliance with applicable requirements for the infrastructure, network, and operating-system security. However, the client must achieve compliance for the application security requirements, cardholder-data security requirements (Requirement 3 and 4), and so on.

PCI: Attestation, Assessment, and Certification

The Role of a PCI-QSA

The PCI qualified security assessor is an assessor who is approved by the PCI Security Standards Council (PCI-SSC). The QSA is authorized to perform audits against the PCI-DSS requirements and certify an organization based on the PCI-DSS Requirements. The PCI-QSA is required to be a security professional who is a qualified certified information systems auditor (CISA) or a certified information systems security professional (CISSP) or who possesses relevant experience of 5 years or more.

Annual on-site evaluation by a QSA is a mandatory requirement for Level 1 merchants and service providers. However, merchants and service providers below the mandatory Level 1 status may decide to use the services of a QSA for an on-site PCI assessment and certification. The PCI-QSA completes the PCI-DSS assessment and identifies whether the entity has met all of the requirements for PCI-DSS certification. Subsequently, the PCI-QSA prepares the report on compliance (RoC) based on the documentation requirements of the PCI-DSS and submits the same to the company along with the PCI certification. The QSA also needs to complete the attestation of compliance (AoC) and affix his/her signature on the document, along with the requisite details required to complete the document.

The PCI-DSS Requirements

A brief view of the 12 requirements of the PCI-DSS and with basic explanations follows:

  • Requirement 1: Install and maintain firewall configuration to protect cardholder data. This requirement delves into specific details through multiple requirements into the network security requirements that have to be met by an entity undergoing or maintaining PCI compliance. The requirement details several specific sections relating to firewalls, network segmentation, intrusion prevention systems, and other network security controls that have to be adopted by the entity.
  • Requirement 2: Do not use vendor-supplied defaults for system passwords and other parameters. This requirement specifically prohibits the use of vendor-supplied default password credentials in the PCI environment. This requirement provides specific guidance on change default settings for network devices, wireless access points, and other system components that are in scope for the compliance.
  • Requirement 3: Protect stored cardholder data. This is a key requirement that exclusively discusses the protection of cardholder data at rest. There are some requirements relating to data classification and need for storage. Additionally, the requirement details multiple options for protecting stored cardholder information at rest. The requirement also explores in detail the key management requirements for entities that encrypt stored cardholder data.
  • Requirement 4: Encrypt transmission of cardholder data across open, public networks. While Requirement 3 details the protection of cardholder data at rest, Requirement 4 delves into encryption of cardholder data across open public networks. The requirement details the use of encryption for securing Wi-Fi deployments in PCI environments.
  • Requirement 5: Use and regularly update antivirus software or programs. This requirement exclusively deals with antivirus management for the PCI environment of an organization.
  • Requirement 6: Develop and maintain secure systems and applications. This requirement encompasses secure systems from the point of view of patching and patch management and development of secure software that is used in the PCI environment. The requirement details development security practices, including systems development life cycle (SDLC), segregation of testing environment, etc. This requirement also delves into application security practices.
  • Requirement 7: Restrict cardholder information by business need to know. This requirement deals mostly with access controls. The requirement describes best practices for access control, including authentication and authorization best practices that are to be implemented in a PCI environment.
  • Requirement 8: Assign a unique ID to each person with computer access. This requirement completes the access control requirements of authentication, authorization, and accountability with specific requirements relating to accountability, password controls, and two-factor authentication requirements under certain conditions.
  • Requirement 9: Restrict physical access to cardholder data. This requirement deals almost exclusively with physical security controls and mediamanagement controls. The requirement explores physical security practices, including physical access control, video monitoring of the cardholder-data environment, and visitor management. Additionally, the requirement also details security practices for media management of tapes, data storage, data destruction, and so on.
  • Requirement 10: Track and monitor all access to network resources and cardholder data. This requirement deals with logging, log management, and monitoring controls deployed across the cardholder environment. The requirement discusses the need for audit trails of access to cardholder information. The requirement also details security practices relating to monitoring for administrative access and other user access to cardholder information. The requirement goes on to specify the details that are to be captured as part of the audit trail.
  • Requirement 11: Regularly test security systems and processes. This requirement calls for security testing to be performed in the PCI environment. The requirement details the need for the wireless access point testing to discover rogue access points within the environment. The requirement also details the need to have an external vulnerability assessment every quarter by an approved scanning vendor (ASV). Additionally, the requirement dictates the performance of internal vulnerability assessment and penetration testing as well as the use of intrusion prevention systems and file integrity monitoring solutions for sensitive system files.
  • Requirement 12: Maintain a policy that addresses information security for all personnel. This requirement deals with documentation and risk-management controls. The requirement deals with the need to maintain a risk-management framework in the organization for its PCI environment. Additionally, the requirement discusses some policies, procedures, and practices that are to be implemented by the organization to meet with PCI compliance.

Compensatory Controls

The PCI-DSS is a technically rigorous and prescriptive standard. On occasion, organizations find it difficult to implement certain controls of the standard because of a technical constraint or a business constraint. In such cases, organizations may choose to adopt a different set of controls than the ones prescribed by the standard. While these controls are not exactly the controls required by the standard, they are able to sufficiently mitigate the risk in the form of compensatory controls.

Compensating controls must mandatorily meet the following criteria:

  • Meet the intent and rigor of the original PCI requirement
  • Provide a similar level of security as the original PCI requirement
  • Be above and beyond the existing PCI requirement

Existing PCI-DSS requirements cannot be considered as compensating controls. For instance, if the organization is not able to "render the PAN [primary account number] unreadable" (Requirement 3.4) with encryption, one-way hashing, or tokenization, then the organization cannot cite "access control" with username and password as a compensating control, as the control is already required by the PCI-DSS.

Documentation: The Report on Compliance

The report on compliance (popularly known as the RoC, pronounced "rock") is the most important document in a PCI-compliance process. The RoC is a document containing all 12 requirements of the PCI-DSS along with an executive summary containing the organization's key information relating to business areas, network topology, etc. The RoC is the document validating the PCIcompliance effort of an organization. It is documented by the PCI-QSA when he/she validates the organization against each control in the PCI-DSS that is applicable to the organization. If the organization is found to be noncompliant with even one of the requirements, without a valid compensating control, then the organization is not PCI-DSS-compliant. The PCI-QSA documents the observations, interviews, and tests conducted to validate a requirement in the RoC, and then stipulates whether the requirement has been met based on the intent and rigor required by the PCI-DSS requirement.

Documentation: The Attestation of Compliance

The attestation of compliance (AoC) is a document that has to be filled out by the QSA upon completion of the PCI-DSS assessment for the purposes of certification. The AoC is meant as a declaration of compliance of a merchant or service provider entity against the requirements of the PCIDSS. The AoC form captures some details about the company and its industry of operation. The AoC form also contains details requiring the organization to declare that it is compliant with all the requirements of the PCI-DSS.


In this article, the prime focus was on PCI-DSS. We began with a brief history of the PCI-DSS. We then focused our attention on understanding compliance validation levels. We identified that the compliance validation levels for merchants and service providers were dictated based on the transaction volume of a particular entity. We then specified transaction volumes and compliance validation levels for different payment brands. Subsequently, we learned about PCI-DSS applicability and how multiple entities like merchants, service providers, and so on, come under the purview of the PCI-DSS requirements. This article ended with a brief description of some of the documentation requirements of the PCI-DSS, including the report on compliance (RoC), the attestation of compliance (AoC), and the role of the PCI-QSA in the compliance process.

Read more IT Performance Improvement

This article is an excerpt from:

This step-by-step guidebook delves into PCI standards from an implementation standpoint. It begins with a basic introduction to PCI compliance, including its history and evolution. It then thoroughly and methodically examines the specific requirements of PCI compliance. PCI requirements are presented along with notes and assessment techniques for auditors and assessors.

The text outlines application development and implementation strategies for Payment Application Data Security Standard (PA-DSS) implementation and validation. Explaining the PCI standards from an implementation standpoint, it clarifies the intent of the standards on key issues and challenges that entities must overcome in their quest to meet compliance requirements.


About the Author

Abhay Bhargav is the founder and chief technical officer of the we45 Group, a Bangalore based information security solutions company. He has extensive experience with information security and compliance, having performed security assessments for many enterprises in various domains, such as banking, software development, retail, telecom, and legal. He is a qualified security assessor (QSA) for the payment-card industry and has led several security assessments for payment-card industry compliance. He is also the co-author of Secure Java for Web Application Development, published by CRC Press.


Interested in submitting an article? Want to comment about an article?
Contact John Wyzalek editor of IT Performance Improvement.