Must PCI Compliance Conflict With Customer Service?
Written by Walter ConwayA 403 Labs QSA, PCI Columnist Walt Conway has worked in payments and technology for more than 30 years, 10 of them with Visa.
I recently had a client ask: “Why is PCI making me stupid?” By that the client meant she was considering reversing a number of technology innovations her company had implemented over the last couple of years. Basically, those innovations had the unintended consequence of expanding her company’s PCI scope, and the resulting cost of compliance was too much.
The issue is not unique to PCI. Innovations in retail technology happen everyday, but standards adapt to these changes much more slowly.
Every retailer lives in this situation. A mobile app works great, but it is not PCI compliant. Web orders get outsourced nicely, but processing mail order and telephone order (MOTO) transactions on a workstation either means lots of network reengineering, separate devices or lots of increased PCI scope (or all of the above). Sometimes, PCI compliance and security even seem to be at odds with each other. What is a merchant to do?
I wish I had the answers. But my conclusion is that maintaining PCI compliance can require retailers to make tradeoffs between having the latest, slickest customer experience and being compliant. Here are a few examples.
I know an E-Commerce merchant that has a small call center to handle customer service questions and process MOTO transactions. The merchant’s staff used to process these payment-card purchases using their workstations, accessing the Web site just like a customer would. Unfortunately, that practice makes the workstations payment devices, and it brings the workstations and anything connected to them into PCI scope. Because the merchant wanted to keep its inventory
and other systems out of PCI scope, it has started using POS terminals for processing MOTO transactions. The result is that the merchant is compliant again, but it has more back-office work reconciling the MOTO transactions with the online purchases.
From this merchant’s perspective, PCI DSS made him scrap an integrated, efficient system and replace it with a two-step process that requires additional back-office work (not counting the POS terminals cluttering up the call center’s desks).
The merchant could, of course, have added a second computer at each call center desk, one dedicated to processing payments and housed on a separate network segment. Both the new computers and the network segment would be in PCI scope. The POS devices, though, were cheaper, so the merchant is living with its newly dis-integrated arrangement.
Another case arose when I spoke at a conference where a university used a laptop to process payments at an offsite alumni event. Naturally, the practice raised a lot of PCI scoping questions about everything from the device to any wireless network used to process the card transactions. Another PCI expert was on the podium with me. That expert suggested that the university instead write the payment-card details on a paper form and process the transactions manually when university employees returned to their office (and, presumably, a POS device). The expert should have added that the university should hope there were neither declines nor transcription errors on those paper forms.
I have to agree that this approach simplifies PCI compliance. But it also dumbs down both the experience and the progressive, tech-savvy image the university—or any retailer—wants to project. Who would not think that Square (2011 technology) is sexier than an imprinter (a.k.a., “knuckle buster,” a 1960’s technology), which itself is probably sexier than pen and paper (let’s go back to papyrus, say 2000 BCE)?
The biggest area where PCI is behind the curve is in mobile commerce. And, interestingly, this appears to be one case where the march of technology is unimpeded by compliance concerns.
The PCI Council has excluded mobile payment applications from its PA-DSS program for the last two years. In that time, mobile commerce has grown anyway. Ultimately, MasterCard and then Visa both published best practices for implementing mobile commerce using attached card readers (a.k.a., dongles). Both card brands recognized that using mobile devices with card readers might not be PCI compliant, but the practice was unavoidable.
So let’s get back to the question of whether PCI, in the words of my client, “makes you dumb.” It seems the answer is: It can, but it doesn’t have to. Paper may not be sexy, but it is really difficult to hack from another continent. In some cases, PCI compliance will cause retailers and other merchants to go backward a bit in technology to minimize PCI compliance cost and effort. It’s a tradeoff that seems to have a business case, and one where a merchant can make a decision based on the plusses and minuses. Blaming PCI compliance may be convenient and, in come cases, appropriate, but you still need to recognize that there are tradeoffs between security and convenience.
Maybe that’s why we have QSAs—qualified security assessors—and not QCAs—qualified convenience assessors.
What do you think? I’d like to hear your thoughts. Either leave a comment or E-mail me.
November 27th, 2012 at 4:46 pm
While it can’t yet address PCI compliance questions associated with customer-owned mobile apps, client virtualization (VDI or SBC) can deliver on PCI compliance requirements across in-branch POS, back-office processing, outsourced customer service call-centers and other tasks where customer data is collected, accessed or processed.
Added benefits of enhanced up-time, PC client management and disaster recovery will be welcomed as well.
November 29th, 2012 at 10:40 am
In reality this is a very good and strong security solution. It keeps the workstations wide open, and if a CSR gets phished by an evil key-logging virus, it’s still not a big compliance deal.
It only sounds bad when you phrase it this way: “Oh poor me, I have to have an unintegrated POS device here!” It places the emphasis on the notion that integrated solutions are always the best no matter what. But nothing is ever ‘one size fits all’, not even a good idea. The reason integration is not the best solution here is that cardholder data is both a liability and an asset.
Instead of holding on to this notion, consider cardholder information as if it were radioactive gold. It’s toxic, something to keep a long ways away from everything, and handle as little as possible. Sticking it in the digital equivalent of a lead-lined vault keeps us a little safer, but we’d still rather have something completely different.
But since that’s still how we get paid, we’re stuck with it.