Is adopting a superior technical or business approach the right choice, even if that approach results in the loss of jobs for the company? Or, put another way: Is it justifiable to implement a less secure technology, if employees’ jobs are preserved in the process?
I bring this up because we have noticed a “protectionism” trend in our research results recently, when it comes to the outsourcing of payment management for the purpose of reducing PCI compliance scope. We're talking about companies opting to store and manage more credit card and other confidential data than necessary, and we suspect protecting jobs in technology, compliance and finance is the main reason for this. But is this “bad”? Let’s do some analysis.
Outsourcing is usually about taking jobs away from people who get paid relatively well (usually in so called “developed” countries) and giving them to people who will work for less (often in other countries). So, for most people (who don’t run companies), outsourcing is “bad.”
On the other hand, when it comes to the cost and the scope of a PCI compliance assessment, merchants are generally inclined to want to want to reduce cost and scope, often by eliminating cardholder data itself. When the data cannot be simply purged, many merchants consider approaches such as end-to-end encryption and/or tokenization. The hope is that by adopting such approaches and the process changes brought with them, they can remove their POS and/or their E-commerce website from PCI scope, reducing their risk of a security breach in the process.
But some of the companies that offer these types of approaches have found that they have to avoid the term “outsourcing,” even if it’s a payment processor offering to take on full responsibility for the dreaded PCI data. It’s not just the word that’s the problem.
I’m seeing two distinct trends when talking to merchants: Senior business and technical executives are strongly motivated to consider hosted payment approaches and tokenization. But the application managers, security managers and compliance managers are generally opposed to these approaches. Maybe they are simply trying to protect their jobs. After all, with fewer pieces of sensitive data to protect, and more monthly bills coming in from service providers, it would seem like somebody’s job will be in jeopardy. There is, however, more to it than that.
It’s not uncommon for a PCI assessment or self-assessment to go on for a period of 3-6 months and then, after all the controls have been documented and the ROC has been written, someone “discovers” an entire process, complete with full card numbers in DBs used by a key application that somehow was missed.
This happens in larger organizations especially because we manage by department, not process. In addition, a lot of procedures are poorly documented. Even when complex processes are documented, we’ve found that most data flow diagrams are so detailed that the only people who actually bother to read them are the people who created them, and these people tend not to be responsible for PCI compliance.
In contrast, the “pitch” for tokenization or end-to-end encryption seem to be almost magical in its touted ability to remove systems and processes from PCI scope. Both of these approaches have strong intuitive appeal to senior executives. But both are met with serious skepticism by many analysts.
Although it may be that these analysts see themselves as losing control, and potentially their jobs, as more confidential data management is moved to their payment processor or other service provider, my experience suggests that its due to a combination of negative experiences with other too-good-to-be-true approaches in the past, combined with the inability of some of the providers to provide a sufficiently detailed technical analysis of how tokenization and/or end-to-end encryption will work in the merchant’s environment.
By marketing and selling these approaches mainly at high levels, some of the payment service providers are paying too little attention to the managers and analysts in treasury, IT security and compliance management who are often asked by senior management, after the vendor has left the building, “do you think this will really work or is it just BS?”
My point in all of this is that the space called “beyond PCI” is growing rapidly. As payment processors, POS vendors, IT security companies and service providers seek to differentiate themselves and tap into the merchant executive’s desire to “get out of the PCI business,” the winner will be the company that can not only win over upper management with a simple message of scope reduction.
No, it will also have to be the one that can come in and explain to mid-level managers and analysts not only how the approach will work in technical detail with the company’s existing processes but where changes will be needed and how much cost and effort will be involved.
If the managers and analysts who actually make the payment process work and keep the data secure do not see a role for themselves in the “post PCI” environment, self-serving answers to the “will this work for us?” question are likely. As more payment security offerings address the space beyond-the-enterprise to protect and manage data across service providers, franchisees, and all the way to the card processor / bank, our understanding of payment security and processes must expand. In such an environment, the concept of outsourcing itself will change. Maybe, someday it will no longer be seen as “bad.”
I’m not suggesting here that outsourcing is “good,” but rather that in a complex, multi-enterprise ecosystem, the term has much less meaning than it used to. I’m also suggesting that we need to understand all potential magic bullet approaches at a level of technical detail that is still relatively rare in the current vernacular of the IT providers.
In short, I’m suggesting that rather than dismiss out of hand the “beyond PCI” approaches, we conduct the technical due diligence to compare their impact on our business processes and their ability to integrate with our technical infrastructure.
Mainly, I’ve found they are neither as good nor as bad as most people seem to think. If you would like to discuss these issues, please visit, register, then login to the PCI Knowledge Base, or just send an E-mail to [email protected].