Compliance Acronym Stew: Is Your Collection Agency at Risk? Part II: PCI DSS

Todd Langusch
TECH LOCK

This is the second of a three-post series from Todd Langusch at TECH LOCK. Part I focused on SSAE 16.

Next to the SSAE 16, PCI DSS is probably the next most widely misunderstood audit standard. Organizations sometimes are confused if PCI DSS even applies to them, which is important in this industry as I have not met a collection agency that has not taken a credit card as a form of payment to resolve a debt. If it does, many do not know what is required to show compliance – for example, with a Self-Assessment Questionnaire (there are 9 versions of these) or a third party audit performed by a Payment Card Industry Qualified Security Assessor (PCI QSA).

I have seen PCI DSS show up on RFPs and accepted by clients to demonstrate data security but sometimes this is misused as well. For example, PCI DSS applies specifically to cardholder information, and the scope of that report includes only the cardholder data environment, so any given PCI DSS audit may not be applicable to the data being sent to the third party (e.g., social security numbers, federal tax information, protected health information). This is true especially if the organization segments their network, separating cardholder data from other data — how then does that show overall data security for all client data? It doesn’t.

One of the best uses of PCI DSS I have seen over the years is when organizations use it as their data security questionnaire to vendors and replace the word “cardholder” with their own name. A widely known example of this is Experian’s Independent 3rd Party Assessment Program (EI3PA). Experian has adapted requirements of the PCI DSS and has applied it to the EI3PA assessment. EI3PA assessments differ in that they assess how a company provides protection of Experian-provided data rather than cardholder data and are approved solely by Experian, not by the card issuer or issuing bank.

Given PCI DSS’s technical nature, specific controls and specific evidence requirements, it really is a good standard to use as a baseline for assessing an organization’s overall security posture when it is properly assessed and implemented. The strict standardized testing procedures allow a company to be reasonably confident that they will have a consistent audit experience among auditors (compare a PCI DSS Report on Compliance to a SOC or ISO report!).

Now, don’t get me wrong, PCI DSS has opportunities for improvement, and some say that PCI DSS lacks the information security management system of ISO 27001 or the “assurance” of a SOC 2 type II or the period of assessment but you have to fully understand the intent of the PCI DSS requirements before rendering judgment. I’ve been involved in data breach forensic investigations in the ARM Industry, and based on that experience and the information that is available from Trustwave Global Security Reports and Verizon’s Data Breach Investigation Reports it is clear to me that the best choice for technical controls when applied to ALL non-public personal information (consumer data), client data, etc. is PCI DSS.

There’s great free information out there that can help you come up with your strategy to become compliant with PCI DSS as well as to answer questions about the intent of specific controls.  Much of this information can be found here.

Please note that the PCI DSS standard is the only common item with the five major card brands (Visa, Master Card, JCB, Discover, and American Express). Due to anti-trust laws, these five organizations all have their own separate programs. I frequently hear someone say they are a level 3 or 4 Merchant and when I ask them for which program the response is always the same “What do you mean?”  For example, American Express requirements can be found here; Visa here; Master Card here; and Discover here.

Another frequently missed item is determining if your company is a Merchant, a Service Provider, or both. Visa, MasterCard, Discover, and American Express categorize service providers according to transaction volume and/or type of service provided, and their PCI DSS compliance validation and reporting is defined according to the designated service provider level. The definition of a service provider is a business entity directly involved in the processing, storage, or transmission of transaction data or cardholder data on behalf of another merchant or service provider.

All ARM Companies that work with credit card payments will have to understand, comply, and address PCI DSS requirements. It is critical for an organization to contact an experienced PCI QSA who can explain the controls that pertain to you as an ARM organization and who has also sat in your chair to assist you with the process and ensure compliance.

For information on PCI DSS and how it impacts your organization contact TECH LOCK today at info@techlockinc.com.

Registration powered by RegOnline