This is page 2 of:
Implications of Heartland’s Beyond PCI Strategy for Retailers
This doesn’t mean retailers should avoid such systems. Far from it. If you wait for emerging security technologies to be standardized, you’ll be the least secure company on the block.
Rather, I’m simply suggesting that retailers do their homework and develop detailed requirements for any technologies that link them to their processor or service provider.
Those requirements should ensure that the retailer can minimize the cost of any provider-specific investment (e.g., POS systems that only work with one processor) and ask lots of questions along the lines of “What other companies support this technology?” The more merchants ask questions like this, the less likely they are to be locked into an unsatisfactory long term relationship. (I’ve been married 3 times. I know what I’m talking about here.)
Beyond focusing on avoiding “Beyond PCI Lock-in,” retailers also need to focus on ensuring that these new security efforts don’t break their existing applications. Some of the tokenization and end-to-end encryption approaches currently (or soon to be) on the market don’t always play nice with existing ERP, CRM and other enterprise applications.
Retailers can wind up spending hundreds of thousands of dollars adapting their applications to work with particular security packages. Not only does this investment drive “lock-in,” but it also requires major concessions from in-house and third party developers, which can substantially delay the project.
Developing data management requirements by working together with the applications team (whether internal or external) is critical to ensuring the success of any Beyond PCI security project.
For example, when Heartland’s CEO described their end-to-end encryption offering, he used the term “Format-preserving encryption,” which is a term trademarked by Voltage Security. (Editor’s Note: Voltage said that it couldn’t confirm nor deny its involvement with Heartland, but Heartland’s Carr just confirmed that they are indeed working with Voltage. Heartland also said that it is working with multiple software companies on its proprietary package, which will include multiple sets of licensed packages plus a healthy dose of code that Heartland salaried programmers will create.)
In addition, tokenization vendors (such as MerchantLink and Paymetric) also proclaim that their tokenization approaches integrate well with enterprise applications. For merchants, it’s critical to be able to fully cost-out the impact of these more strategic packages on existing processor relationships and applications infrastructure. These are not bleeding edge products, but they are still very different from each other and require a thorough business process and technology understanding in order to evaluate them properly.
The land “beyond PCI” is all about strategy. It’s about admitting that PCI compliance will not prevent breaches and is well short of enterprise data security. The best way to approach the problem is to use the PCI mandates to justify the basics, and then use breaches to justify the rest. Essentially, “beyond PCI” is a layer of strategy on top of a layer of compliance. If you find this stuff interesting, you can see the research that drove our conclusions by visiting, the joining (for free) the PCI Knowledge Base so you can search our research database. In addition, if you want to discuss this topic, send an E-Mail to David.Taylor@KnowPCI.com.
-Marc
May 13th, 2009 at 7:31 pm
The biggest result will be the increase in the standard of care. The more companies that do PCI-plus the higher the standard of care is from a legal perspective (that is when it becomes “industry standard” and even if not, plaintiffs will argue it is).
May 14th, 2009 at 11:03 am
Since big processors and other enterprises with lots of sensitive data can’t afford to wait around for standards and/or interoperability, one ought to be in search of what the analysts characterize as automated, enterprise-wide encryption management solutions. They’re already out there folks.
May 14th, 2009 at 11:11 am
No one’s arguing the merits of encryption, but as the scale of cert and key objects increases, we’ve got to have a better way to manage all this–some way other than a spreadsheet and really smart engineer.
Suggestions?