Skip to the main content.

5 min read

Call Centers and PCI Compliance: Things You Need to Know

Call Centers and PCI Compliance: Things You Need to Know

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.

Understanding The Process

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.

The Technology and Data Relationship

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:

  • Call recordings may need to be protected with encryption, access controls, and logging. If they do contain sensitive authentication data, it needs to be removed. Or alternately, demonstrated that it cannot be mined or queried.
  • VoIP systems bring networks and connected systems into your PCI scope. They may also support interesting functionality like call cloning/monitoring that needs to be controlled. The VOIP transmissions themselves need to be encrypted.
  • Bluetooth enabled devices like headsets and keyboards need to be considered as well. While newer Bluetooth devices support strong encryption many don’t.
  • Call center teleworker environments may need to meet PCI security requirements.
  • Cell phone technology may not be able to provide the level of encryption and control required by PCI compliance.
  • Paper and hardcopy, whether reports or post-it-notes need to be considered. As well. Can they be locked up and are there secure shredders to dispose of these when no longer needed

Creating Your Action Plan

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:

  • Do consider your business processes. Removing data you don’t need is one of the most effective ways to reduce risk, achieve and sustain compliance.
  • Do support this with training and awareness initiatives.
  • Do consider technological steps to reduce the size of your compliance foot print.
  • Do spend time on the tricky problems to make sure your solutions are justified and defensible based on risk.
  • Do validate your solutions and approaches.
  • Don’t ignore the due diligence and formalization of specific PCI compliance responsibilities required when outsourcing.
  • Do address the any data cleanup issues.
  • Don’t make assumptions or ignore issues.

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,

  • Encrypting payment terminals while useful in card present solutions, only simplify outbound acceptance channels. The inbound channels (e.g. calls, faxes, and letters) still need to be addressed.
  • Tokenization can help simplify requirements where you need to store card data; however, the inbound channels still need to be addressed.
  • There are also several solutions that claim to eliminate or remove card data in call center operations. We have evaluated several of these. Some work well. Others no so much. Do your homework on these.

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.

Learn More Within PCI Compliance

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.

What Is Cardholder Data In PCI Compliance?

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...

Read More
What Is Sensitive Authentication Data in PCI Compliance?

What Is Sensitive Authentication Data in PCI Compliance?

Sensitive authentication data, aka SAD, in PCI compliance is data used by the issuers of cards to authorize transactions. Similar to cardholder...

Read More
PCI Announces NESA - A Stepping Stone To P2PE

PCI Announces NESA - A Stepping Stone To P2PE

Earlier this month the PCI Security Standards Council published a new document as part of the Point-to-Point Encryption (P2PE) program. This initial...

Read More