Audit Serve, Inc.

The Premier Audit, Security and Sarbanes-Oxley Consulting Company

  
            An Insider’s View on How to Become
                 Level 1 PCI Compliant   (Part 2 of 3)
                      By: Mitchell H. Levine, CISA - Audit Serve, Inc.

                                            

This is the second of a three part article intended to provide insights on how to navigate through the PCI project components.

 The first step of the PCI project is to perform a credit card scavenger hunt to determine from a business operations and systems perspective where and how credit card transactions are processed and the location of the credit card account numbers.  This requires a review of all business operations to identify the circumstances in which credit card transactions occur and instances in which credit card data may be stored which is not related to a credit card transaction (referred to collectively as PCI in-scope processes).  Identifying instances in which credit card data may be stored which is not related to a credit card transaction may include 1) Data interchange with an outside entity in which their account # is the credit card number and/or 2) Receipt of credit reports in which credit bureaus were not instructed to suppress the credit cards contained in the credit reports.  As part of the business operation, credit card number may be collected but not processed by one’s organization but instead it is sent to a third party for processing.  In this case, an understanding is needed of whether the data is stored and then transmitted or if the credit card payments which are collected are manually faxed to the 3^rd party for processing.

 If the credit card payment is entered into an application to store the data for later transmission to a third party for processing, the data would need to be encrypted and the ability to display multiple credit cards through the application needs to be restricted.  The delivery of the data to the third party for processing also needs to be secured either by encrypting the file which is sent to the third party or the transmission process itself needs to be encrypted.  However, the encryption of the transmission can only be used if an organization is sending the file to the 3^rd party.  If the 3^rd party is fetching the file from an organization’s system then the file itself needs to be encrypted.

The method in which credit card payments are collected needs to be closely evaluated to understand the additional security measures which need to be established.  If the credit card payments are faxed to an organization which is process through a fax server then the stored faxed data needs to be encrypted.  However, the PCI project becomes even more complicated if phone conversations are being recorded since these recording would contain the credit card number and therefore the voice recording needs to be encrypted.  If the CVC number is collected for credit card payment processing, then the CVC would be stored in the voice recording which is not allowed by PCI.  An alternative is to route the part of the transaction involving the exchange of the credit card # and CVC to another clerk whose phone is not recorded.  

Once the scavenger hunt for the use of card holder data  is completed whereby all of the PCI inscope business processes are identified, these business processes need to be traced to the application these PCI inscope processes use along with the database, servers and network segments they are part of.  

At this point, an PCI inscope inventory list can be established which includes the following PCI in-scope components

- Inscope process (e.g., credit card # is the account #, credit card payment transaction)

- Business processes

- Applications

- Databases

- Servers

- Network Segments

The next step would be determine whether there are any measures which can be taken to reduce the scope of the project which would be to reduce the number of PCI in-scope components.

Some suggested scope reduction measures include:

- Removal of PCI inscope historical data

- If inscope business processes are comprised of specific customers or account types, scope reduction measures can be implemented to isolate these PCI in-scope components to separate databases and servers.

- Utilization of credit card payment service providers where the credit card payments are processed on their systems and there is no storage of this data on the organization’s system

- Offloading of PCI in-scope components to a third party who is PCI compliant

- Migrating PCI in-scope processes to applications which are already in-scope for PCI

This article will be continued in the next issue of Audit Vision.

  ________________ _________________________________________________________

Mitchell Levine is the founder of Audit Serve, Inc. Audit Serve performs PCI Assessment and Remediation Project Management consulting services. Audit Serve also conducts Integrated & IT Audits, SOX Control Design & Testing.    Email Mr. Levine at Levinemh@auditserve.com if you would like to discuss your organization's specific project requirements in order to establish a proposal of services.

Copyright  2008, Audit Serve, Inc. All rights reserved. Reproduction, which includes links from other Web sites, is prohibited except by permission in writing.

This article appeared in a past issue of the Audit Vision E-Mail Newsletter.

Technical Articles | Conferences | Audit Programs | Audit Serve Seminars | Consulting Services | Audit Vision Newsletter | What's New | Contact US

This website has been optimized for Netscape and Internet Explorer 4.0 and above.  Your comments and suggestions are always welcome, please email webmaster@auditserve.com.
Copyright © 2000  All rights reserved.  27 Pine Street, Suite 700, New Canaan, CT 06840 USA.