Call centers, when it comes to PCI DSS compliance give the problem to someone else
I have been a PCI DSS QSA for seven years now, and involved in the information security industry for 15. In that time I have assessed and advised all manner of customers, large and small, across various sectors and in various aspects of their business. From e-commerce SMEs to global multi-channel retailers, it is fair to say that – like many QSAs – my experience has been broad, and I have seen all manner of payment channels and implementations. While all engagements are different there is one constant – if there is a call center, it is almost always the most difficult part of the project.
PCI DSS compliance in call centers is challenging
Why so? Well, in many ways the call center is a bit of a perfect storm for PCI DSS compliance, and fraud in general. Many call centers experience high staff turnover and are dealing with very sensitive customer data – including payment card data – in a time and resource pressured environment. Calls are often recorded, and in many cases sessions are recorded as well, meaning that not only must payment card data be controlled in the main line of business system, but additional measures must be put in place to make recording compliant.
So we have an environment in which the agent, their PC, the software, back end systems, network, call recording and session recording can very easily be in scope, requiring multiple (often non-integrated) solutions to achieve compliance. This can mean pause and resume or masking on the call record, redaction of session recording, and implementation of all the PCI DSS controls across the rest of the infrastructure. This is without the other steps that call centers take to reduce fraud (e.g. no mobile phones, “clean room” style environments, no pen and paper or extraneous software and so on).
Not only does this make for a potentially expensive environment to run (and this in a very cost sensitive industry), but it hardly makes for a feel-good work environment, where the many imposed controls can make employees feel untrusted, to say the least. It also highlights the difference between a potentially compliant control and one that will consistently pass audit. All these controls need to be fully integrated into BAU and maintained to a level that an annual audit will be passed. No simple task, especially when the person charged with running the call center can feel that these controls run counter to their primary task and targets (although, in fairness, most call center managers in my direct experience have been fully on board with the need to implement security controls in general, and PCI DSS compliance in particular).
Further complications are encountered in that the single customer, single location call center is far from the norm. Often, many individuals across the organization (both functionally and geographically) can take payments, and conversely many large call centers support more than one customer. No wonder then, that the call center is often the most controversial and slowest moving part of any PCI DSS project.
Simplifying PCI DSS compliance in call centers
You will note that in my opening paragraph, I say that the call center is almost always the most difficult part of the project. There are occasions when the call center is perfectly straightforward, and these occasions almost always involve the call center having nothing to do with credit card numbers at all. This usually means that the call center has implemented some sort of DTMF payment solution. A DTMF payment solution enables customers to key in their PAN, expiry and CVV2 via the telephone keypad (DTMF tones are usually masked or silenced so that the agent cannot extrapolate the data) and this is intercepted by the solution and sent to the PSP without the call center ever being involved.
Cloud-based PCI solutions
Ideally this is done as a service, or a cloud based solution, in order that the call center has no ‘technical’ PCI DSS scope at all (there will always be supplier management, incident management and policy responsibilities). Syntec’s CardEasy solution is a prime example of a reliable DTMF payment solution – full disclosure, I am their QSA (and personally really like the chaps) – but other reputable DTMF solutions do exist. The beauty of this is that not only does it reduce scope, it minimises risk, as call center staff need never have access to any card data at all.
There are challenges of course. Industries with non-integrated partner sales (where for example the same card number might be used by an agent on multiple partner websites – the travel sector can be a good example of this) can struggle (although this usually points out the need to better integrate partner sales!). And there is resistance in many environments on the grounds of customer experience. However, there is evidence to support the fact that customers actually feel safer not reading their card data across the phone; and certainly there is no report of catastrophic drops in sales where these solutions are integrated. Equally, there will always be exceptions where the customer simply cannot use the solution, but in my experience these are usually lower than anticipated (the customer did dial the phone number after all…) and it is in any case simpler to make a small exceptions process compliant that validate an entire call center.
Handling multiple payment channels
Of course, the challenge does not stop there for the call center environment. Increasingly call centers themselves are integrating into other payment channels (think web chat, SMS, co-browsing) and solutions are having to update to support this. However, I think it is clear that the overriding trend in call center payments will be towards moving the call center out of scope; mirroring the general trend in PCI DSS compliance to give the problem to someone else. If you don’t need the card data, don’t touch it (if you can help it…).
Visit the CNS Group website for more information on its PCI DSS Consultancy services.
