PCI-DSS

Once you know what the Payment Card Industry Data Security Standard is, you will wonder how we got along without it before. 

Companies that handle credit card or debit card transactions take the long card numbers of their customers. That's a necessary step in completing any kind of payment. 

But wait a minute, these numbers are a massive security risk.  What if someone gets hold of one of those card numbers?

In the industry by the way, one of these numbers is called a Primary Account Number, known to all as a PAN.

The point of PCI-DSS is to make sure retailers and their suppliers in turn, do all they can to make sure PANs are dealt with as securely as possible. 

If  a company has not looked at this question systematically, then it might be holding PANs unencrypted and be sending them around its own computer systems. They might feature in management reports. Staff might be able to get hold of them. 

To deal with all of these there are a couple of standard approaches. By the way, I am describing the problem as if it is simple. In fact, in essence it is simple. However if you look at the PCI-DSS standard itself you might conclude it is massively complicated. The document is huge and not easy to read. 

But, getting back to approaches. They can be classified like this: 

ONE None-IT

None-IT approaches mean making sure that facilities are appropriately constructed, that doors have locks where they are needed, that work areas that have access to PANs are secured, and that staff do not carelessly write them down, perhaps as an innocent note write at the desk. 

The none-IT steps might seem potentially simple, but implementing them is potentially a very large piece of work. 

TWO Tokenization

One trick is to convert the PAN to some number that represents that PAN, and to only use that in internal IT systems. This crafty trick means the IT systems can do what they need to do, but don't handle the radioactive PAN.  If you don't have the PAN, you can't lose it. 

THREE Payment Gateway

Another approach is to delegate the PAN handling (did you see what I did there?) to another company. The PAN has to be present in order to be sent to the card company for the transaction to work, but one option is to have the customer enter it on a web page or via a device, that does not belong to the retailer.  This is a nice lateral thinking solution. 

So here's an issue: if there is some kind of a data breech involving card data, who pays? Most often it is the card issuer, the Visa, Mastercard etc.  Paradoxically, this can mean the expense of implementing PCI-DSS pays to reduce the risk on someone else. Still good practice though. 

TW