PCI Introduction and Background

• The Payment Card Industry (PCI) was created by the major credit card brands (Visa, Mastercard, Discover, Amex, Discover, and JCB) in 2001 in response to the increase in theft of credit card data and the impact it had to consumers.

• The brands drove the creation of the PCI Security Council, which maintains and updates the set of standards collectively known as PCI.

• These standards provide merchants who accept credit cards with a set of requirements that are designed to protect credit card data as it traverses electronic networks as part of the acceptance process.

• While merchants are not mandated by law or regulation to adopt PCI standards, the major card brands do mandate its use via the banks and other organizations who process all credit card transactions.

• Failure to comply with the applicable standards can result in a merchant being unable to accept credit card transactions at all, along with the associated financial impact of such a ban.

• Therefore, PCI standards are a requirement for all merchants to follow without exception.

The PCI Security Council maintains multiple standards to address areas of risk associated with the different types of credit card business that organizations perform.

When organizations refer to “PCI Compliance”, they are typically referring to the PCI Data Security Standard (PCI-DSS). However, this is only one of the many standards that are a part of PCI.

The PCI Standards developed by the PCI Security Council include the following:

The PCI standards are designed to protect both Cardholder Data (CHD) and Sensitive Authentication Data (SAD):

Assessing Compliance

• All merchants must perform assessments of their compliance to the applicable standard(s) on an annual basis.

• This ensures that controls are assessed on a regular basis and that merchants are performing their obligations for PCI compliance continuously.

• A popular misconception amongst smaller merchants is that PCI and its associated assessments are not required if the bulk of credit card processing is outsourced to a third party. However, this is not the case.

• All merchants must comply with all applicable PCI requirements.

• While the operation of associated controls may be outsourced to these third parties, the individual merchant is ultimately responsible for their transactions.

• The specifics around the way controls are assessed are driven by a merchant’s Merchant Level.

Merchant Levels

Merchants are classified into levels based on the number of transactions processed in a given year.

The levels differ slightly by credit card brand, but assessment requirements for each merchant level are consistent.

Generally, the greater number of transactions processed by a merchant means that the assessment criteria and methodology are more stringent.

The table below illustrates a sample of the different merchant levels (one through four) by card brand, based on transaction counts.

Assessment Methods

• The method used to assess compliance with PCI requirements differs depending on the type of business a merchant is performing and the merchant level they are currently at.

• While all merchants must perform some type of annual assessment, who performs the assessment and to what level of detail the assessment is performed is determined by merchant level.

PCI-DSS assessments generally fall into one of three methods:

Reports on Compliance and Attestations of Compliance

• Assessments result in either a Report on Compliance (RoC), Attestation of Compliance (AoC), or both. The RoC and/or AoC are provided to the merchant’s credit card acquirer annually to prove their compliance with PCI requirements.

• As with the assessment methods, the proof of compliance method is determined by merchant level and the requirements of the specific card brand.

• Higher-level merchants may also be required to provide quarterly network vulnerability scans performed by an Approved Scanning Vendor (ASV).

The table below provides a sample of these requirements, along with definitions of each type of proof.

PCI-DSS Requirements

• As it is a compliance requirement for all merchants, it’s important to understand the twelve high-level requirements that make up the PCI-DSS.

• Each requirement addresses a specific area of risk associated with credit card data handling.

Preparing for PCI Compliance

Preparing for PCI compliance for the first time can seem like a daunting exercise. However, each of the standards provide detailed descriptions of each requirement and provide testing guidance that can be used by merchants to determine the best means for testing their controls.

It is important to note that PCI Compliance is not a “one and done” exercise; it requires constant testing of controls to ensure that things like configuration drift or changes to policies do not impact the effectiveness of controls.

This continuous monitoring approach can be difficult to organize and maintain, but the use of ZenComply can help to simplify the process.

Determine Applicability of Requirements

Determine Network Scope

Open

TIPS:

Building Your System of Record

The use of ZenGRC to manage PCI compliance can save organizations time and effort. The first step in leveraging ZenGRC for PCI compliance is to build out a System of Record that reflects your organizations PCI controls and that considers the methodology used to audit those controls.

Determining the Structure of Program(s)

The main considerations in how PCI programs should be structured within ZenGRC are:

• How audits are conducted (i.e., is there a single RoC or are there multiple RoCs?)

• How assessment results need to be reported (i.e., is it necessary to see results by individual retail site, at the aggregate level, or both?)

Common Controls vs. Unique Controls

An effective way to reduce audit overhead is to determine where common controls exist within the organization. Some examples of common controls are an enterprise information security policy that applies to all retail sites, or an enterprise change management program that applies to all changes made to systems in the CDE. Common controls can be mapped to applicable systems and/or retail sites but are typically tested only once.

Unique controls should be used wherever there is a nuance that is specific to a system or retail site (i.e., a legacy system that uses its own access control), or if there is a need to report compliance at the individual system or retail site level.

Testing Your PCI Controls

One of the benefits of using a framework like PCI for testing controls is that the testing criteria is typically defined and designed to ensure that testing results are accurate and consistent.

The PCI-DSS provides actual testing procedures that can be used by both qualified assessors and organizations using SAQs for compliance. These procedures can be used to determine the evidence that would prove your specific controls are in place.

The table below shows sample testing procedures from the PCI-DSS and samples of acceptable evidence.