What Is Cardholder Data In PCI Compliance?
Cardholder data, aka CHD, comes from credit, debit, and prepaid cards bearing the logo of one of the PCI founding card brands. CHD includes the...
5 min read
David Gamey : Dec 15, 2016 12:00:00 AM
Call centers can be challenging places. They range from small and simple to large and complex. For many businesses they are a place where new technologies can be exploited to improve service and profitability. It should come as no surprise that they can also be one of the most challenging environments to secure. Whether your business processes payments or receives card data for any reason, you need to understand how PCI compliance affects you.
Most critically, you need to understand how your people and processes deal with credit card information. Not just at the 60,000 foot high level about what is supposed to happen, but what actually happens. You also need to understand what technologies are in play and what components see the data. A seemingly simple change such as from old fashioned analogue telephony to VoIP or from a fax to a fax server can have a huge impact on your compliance footprint. Lastly you need to understand the data itself. In a call center context, cardholder (and sensitive authorization) data include the primary account number (PAN), security validation codes, and PINs regardless of the form or media type. Digitized voice, voice recordings, recordings of IVR/DTMF tones, images, videos, text data, and hard copy all must be protected.
Spend time to figure out exactly how your business handles card data. How it’s supposed to work is only a start. Find the surprises and unexpected. People trying to do a job are often very good at workarounds and improvisations and many call center databases are full of PAN in the free-form text fields as a result. You need to look at these off the books processes. Figure out where the data flows and lives, and why it’s there. Even if you don’t process payments you may have data for other purposes (e.g. credit checks) and you may receive it unexpectedly (e.g. images of third party invoices, memo lines on cheques, etc.). Customers can also provide card information when you don’t want it. How do you deal with these cases? If your staff just make it work then you may have a de facto card acceptance channel.
Once you understand what you have, how it’s handled, and where it goes, it’s time to look at the technology environment. What technology components touch the data? What components support those? How big are the networks of connected systems? What systems that have nothing to do with handling card data can potentially see the data? Are you encrypting the data during transmission? Are you encrypting all stored data? How are you dealing with securely deleting any sensitive authentication data (e.g. security codes and PINS)? Where you have technology limitations, how do you deal with the risk? What other controls do you apply?
Are you outsourcing any of this function or any support for this function? What due diligence was done? How do you know that security and compliance objectives are met? Did anything fall through the cracks? And when it comes time to demonstrate your compliance, how will the outsourced function’s compliance be demonstrated?
Do you know what your compliance status is? Do you have any gaps? Are there other risk mitigations or controls that need to be accounted for to support your compliance?
PCI requires that card data be protected. Not just with encryption of transmission and data at rest; but with policies and processes, physical controls, system and network access controls, anti-malware controls, logging and monitoring, patching and robust vulnerability management, and training and awareness. These are controls that need to be evaluated across an organization’s entire compliance footprint.
Here are a number of the major technology and security challenges facing call center operations:
Once you understand all of these things, you are well prepared to meet your compliance obligations. You should first do a gap analysis, then apply risk analysis to the results, and plan your remediation. Some measures will be clear and obvious. Others will be trickier requiring careful consideration of the intent of PCI and specific risks:
If you are considering some specialized technologies and solutions. Do take the time to make sure they meet your needs and the requirements. Some examples,
A security breach, not just a card data breach, will not help your business. Don’t ignore unintended and accidental collection. Beyond PCI what other sensitive information (e.g. Personally Identifiable Information, Health Care data) do you deal with and how are you protecting it? Also, what other laws and regulations may apply? Are any in conflict?
How will your solutions hold up over time and against the inevitability of human error and imperfection in systems of this kind? You should think of ways to periodically monitor and correct for errors. Use risk as your guide but make sure something is in place.
Below we’ve provided a series of links to useful guidance covering many of issues discussed in this article from the nature of card data, how PCI applies to specific technologies, how to deal with unintended data, as well as specific information supplements on telephony and third party assurance.
PCI Information Supplements
Frequently Asked Questions:
Cardholder data, aka CHD, comes from credit, debit, and prepaid cards bearing the logo of one of the PCI founding card brands. CHD includes the...
Many organizations have either undergone or are planning migrations or acceleration of call centers, remote working, and online presence exploiting...
Executives and managers in organizations preparing for their first onsite PCI security assessment may feel confident that having passed a SOX audit...