Evan Schuman's StorefrontBacktalk

A 403 Labs QSA, PCI Columnist Walt Conway has worked in payments and technology for more than 30 years, 10 of them with Visa.

Is an entity that suffered a cardholder data breach in the past but has since validated its PCI compliance actually safer than one that was never breached? A friend recently asked me whether I thought a breach victim that had been forced to go through a forensic investigation and an outside PCI DSS compliance assessment by a QSA would be more likely to handle payment-card information more securely than those merchants that have not had that lovely experience. My answer is, that might be the case. But there is a little more to consider.

Of all the things that might go wrong in planning a company’s holiday party, I didn’t expect a cardholder data breach to be near the top of anybody’s list. I was wrong. A friend of mine was planning to take her staff to a certain restaurant as a holiday treat. But when I mentioned to her that the establishment had suffered a very public data breach a few years ago, she paused. After thinking about that fact for a while, she responded that in her mind, because the restaurant had been through the PCI wringer, it should be not only safe but actually safer than any other restaurant on the planet.

I ended the speculation by pointing out that as a consumer, the liability was zero, so she should go ahead and enjoy the party. But her pause got me thinking about other situations where the liability may not be zero.

For example, should a retailer feel more secure if it uses a card processor that suffered a data breach in the past but has fully remediated and is now validated (or revalidated) as PCI compliant today? Conversely, should a processor feel increased confidence in signing a merchant that has emerged from a data breach and has now validated its PCI compliance?

There is a certain logic to the argument that having met and satisfied a stringent review of all its practices by an outside expert, the entity—be it merchant or processor—might actually be stronger despite its problems in the past. This argument makes sense on the surface, but experience tells us that we may want to investigate further. That is, although it may be the case, you should not automatically assume that things have changed for the better.

The first thing is to understand what caused the data breach. Was it a malicious insider, a lost or stolen laptop, skimming, intercepted E-mail, storing unencrypted data, using an insecure payment application or a hack of the organization’s networks or systems? Was the breach a result of the failure of a single control or a systematic failure to maintain security controls? We’ve seen that some data breaches are due to simple mistakes, while others result from very determined, well-funded and competent hackers who target a specific organization.

After that, you should know what steps the entity took to remediate. For example, has it implemented more stringent training and hiring standards, re-segmented and protected its network or eliminated the storage of cardholder data entirely through something like tokenization or point-to-point encryption?

You are unlikely to find the answers in a Report on Compliance (ROC) or similar document.