August 2014 IT Business Consulting Newsletter

Take Credit Cards??    A PCI Overview

By Tom K

If your staff or your systems touch credit card info, your company must be PCI DSS compliant (Payment Card Industry Data Security Standard).

I recently helped yet another VRM company work through the very tenuous PCI Compliance process. Although the full PCI Compliance process would be a huge topic to attempt in a newsletter, I thought I’d offer some experienced insights that you may find helpful. So…

In this month’s article, I outline the PCI org and the PCI DSS requirement structure in layman’s terms and show you how to greatly reduce your responsibility to large sections of the requirements.

Next month, I’ll continue the discussion and highlight some of the Merchant Requirements that we’ve found to be challenging, or are often missed.


Some Quick Definitions:

  • Cardholder Data (CHD) – Any/All information associated with a credit card
  • Cardholder Data Environment (CDE) – The people, processes and technology that store, process, or transmit cardholder data (your environment)
  • Merchant – The Company receiving Cardholder Data from the consumer. Includes Web Hosting / Service Providers if processing Cardholder Data on-line
  • Payment Application (PA) – The application used by the Merchant to process Cardholder Data
  • Payment Application Data Security Standard (PA-DSS) - The complex set of requirements the PA needs to comply with when handling Cardholder Data
  • PA-DSS certified – The PA has been certified as being in compliance with the PA-DSS
  • Payment Card Industry Data Security Standard (PCI DSS) - The complex set of requirements the Merchant needs to comply with when handling Cardholder Data

The Official PCI Glossary of Terms (24 pages) is located here: PCI-DSS Glossary v3


PCI DSS in a Nutshell

The PCI Security Standards Council (PCI SSC) is responsible for developing, defining, and managing the various PCI security standards.

Compliance with the PCI set of standards is enforced by the founding members of the Council: American Express, Discover, JCB, MasterCard, and Visa.

The PCI DSS applies to all entities that store, process, or transmit cardholder data.

The PCI DSS covers technical and operational system components included in or connected to cardholder data.

If you are a Merchant or Service Provider who accepts or processes payment cards, you MUST comply with the PCI DSS.


PCI DSS Requirements

The PCI DSS specifies 12 core requirements, each having numerous sub-components. For reference, the core requirements 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.

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 a policy that addresses information security.

A quick look shows that some appear pretty straight forward (#2, #5, #8), but the details are in the sub-components! Others look pretty technical (#1, #3, #11)… and they are.


PCI DSS Compliance

PCI DSS compliance entails meeting all of the 12 requirements. The sub-components required vary depending on how a given Merchant handles/processes credit cards and how the Merchant organization/environment is structured. These Merchant entities determine which of the nine Self Assessment Questionnaires (SAQ) applies to the Merchant’s Organization. The applicable SAQ then defines which sub-components are required. This can vary from 14 to 347 sub-components, depending on the SAQ (A thru D-SP). It looks pretty daunting and it can be.

However, you can greatly simplify the PCI DSS compliance process through two factors:

1. Ensure that your Property Management software, your Web Site, and your Company do NOT electronically store ANY Cardholder Data, whether your systems are hosted in-house or off-site (in the Cloud).

2. Ensure that your Payment Applications are PA-DSS Certified.

If your data systems and company do not electronically store ANY Cardholder Data, significant sections within the requirements just don’t apply. And, this is required to qualify for the less stressful SAQs.


We typically see three types of Payment Applications:

1. Stand alone – a card swipe attached to an independent/dedicated terminal

2. Integrated into the PM system

3. Integrated into a Web Site

If each of your Payment Applications is certified, you are assured that they have their pertinent PCI DSS requirements (transmission, encryption, tokenization, etc) covered from when the Cardholder Data is entered into their application, assuming you follow the PA’s implementation guidelines.


As I hope you have ensured these two factors, I’ll pass on the areas they generally involve when I get to specifics (next month).


Self Assessment Questionnaire (SAQ) Selection

The compliance level of difficulty is determined by which SAQ your company needs to complete. SAQ A is pretty simple, SAQ D-MER is very difficult. So how does a company determine which SAQ they will be required to utilize?

Many bank/payment processors have developed partnerships with PCI Compliancy companies that have systems in place and provide resources to assist their clients in the compliance process. If you are working with a PCI Compliance company, they usually have a wizard to help in the SAQ selection. When you begin the compliance process, you are asked a series of interactive questions. How you answer each question determines the next question selection path through the process. While this questionnaire wizard seems relatively simple, it is a very critical phase of the process. If you mis-interpret one question, it could push you into a more rigorous SAQ. You really need to avoid making a mistake here, as it could cause hours and hours of additional work through the compliance process, so I highly recommend you get help from someone who has done this before and is familiar with the requirements.

If your bank/payment processor does not partner with a PCI Compliancy company, you can contract these services directly, or you can use the documents available on the PCI site to step through all phases of the PCI compliance process. As noted above, no matter how you proceed, I recommend you not do so without help, especially if you hope to manually work through the PCI site documents.


The Revised Standard v3.0

If you’ve undertaken the compliance process in previous years, you used Version 2.0, released in October 2010. This year, you’ll notice significant changes to the Standard, as the revised Standard, Version 3.0, was released in November 2013. Note that most changes are effective as of the release date, while some are not required until July 2015.

If you are working through the compliance process manually, make sure you use a v3.0 SAQ. But be careful, as many of the instructional documents have not caught up, and are still version 2.

For those not faint of heart, the PCI DSS Version 3.0 Standard (all 112 pages) can be found here: PCI DSS v3 Standard


If you have any questions or concerns with any of the material presented in this article, or would like general or specific assistance with the PCI compliance process, I’ll be happy to discuss this with you at your convenience. Feel free to contact me at TomK@TomKConsulting.com, or via my cell 443.310.5110.


Next month, in Part 2 of this article, "Take Credit Cards??    PCI Challenges", I’ll continue the discussion and highlight some of the Merchant Requirements that we’ve found to be challenging, or are often missed.