Decoding PCI

You’ve heard a lot of talk about PCI compliance lately, and for good reason.

With the increasing use of software to manage payment and settlement for credit cards, vulnerabilities in credit card usage have been at the forefront of the industry conversation. And with good reason. Credit card data is amazingly easy to find. Because the sensitive data, such as the name of the cardholder and card number, is imprinted upon credit cards’ magnetic strip in an unencrypted format, stealing this information is easy for even an intermediate computer user.

While, in a perfect world, the credit card companies would simply find a way to encrypt this data, the credit card issuers have chosen to place the onus of security on you, the merchant. Because of the inherent vulnerability of card data, measures must be taken on the merchant end, and, thus, we have the birth of the PCI DSS (or Payment Card Industry Data Security Standards).
Let’s run through a quick history, and I promise we’ll keep it simple and as entertaining as possible.

Way back in December of 2004, PCI DSS 1.0 debuts. This was the first time the five major credit card companies agreed upon necessary security standards for merchants. Essentially, the credit card companies put together some basic security protocols and told the merchants (you), “This is what you need to do to keep the credit card data safe.”

In September of 2006, PCI DSS 1.1 was released. The big addition is that the big five credit card companies now required every merchant to be tested by a professional company for possible security vulnerabilities. These companies are licensed by the PCI SSC (PCI Security Standards Council), which was established at the same time. So, essentially, the credit card companies create a standard of security, then create the council which licenses companies to test merchants’ security risks. Handy, right?

In October of 2008, PCI DSS 1.2 appears, which adds wireless standards, among other things. As a rule, wireless networks and credit card software do not mix.

October of 2010 & November of 2013 both brought new versions of PCI DSS, but were mostly focused on streamlining. Nonetheless, each iteration of the compliance standards brings new adjustments to the day-to-day management of security. That’s great if you’re a giant company with an IT department whose job it is to follow and implement all these new rules, but most businesses, and certainly most of our partners, are smaller businesses run by owner/operators.

Essentially, what PCI compliance means for you is that you need to properly secure the unsecured data on a credit card. It’s important for you not only to be compliant, but to understand why you need to be compliant.

Because all this loose data is available on a credit card, and credit card data is increasingly used for internet purchases and more, sometimes in risky places, the chances of a cardholder’s data being swiped at some point is fairly high. The trick for you is to not be that point of failure.

If a company like Target can be breached, and that story continues to unfold, how can you, as a small business owner, expect to be safe? The short answer is that you want to be more secure than the next guy or gal, to not be the low-hanging fruit. Not only can a credit card data breach mean a loss of reputation, it can result in fines that can cripple a small business. Yes, it would be great if the big five credit companies made a safer product, but the reality of the situation is that it has become your responsibility to protect the personal data of your customers. It’s complicated, it’s a headache and it’s absolutely essential.

In our next article, A Few Tips on PCI Compliance, we’ll offer some tips on finding information on PCI DSS and how to be more in control of your security. If you haven’t yet checked the PCI DSS website, give it a look here: