Use of Credit Card Data as reference for identification

[Doug]

As part of our PCI remediation program we have been notified of a system that records the following credit card details as part of a ‘100 point’ personal identification process:
- Last six digits of credit card number
- Expiry Date
- Type of credit card
- Place of issue
These details are recorded unencrypted on an SQL database.

Is anyone able to advise if they have come across a similar situation and what their resolution was? In fact is the collection of this information subject to the PCI DSS?

Thanks in advance...

[jbhall56]

Because this application is collecting cardholder data, regardless of the reason or purpose, this application is covered by the PCI DSS and must comply with it.

Based on what you have described, this application will be compliant if you perform the following.


The PCI DSS states that you are only allowed to have the first 6 digits and/or the last 4 digits of the primary account number (PAN). So your application keeping the last 6 digits is not compliant and you need to reduce this to 4 digits.

I'm assuming that your statement regarding 'place of issue' is related to the fact that the application is retaining the first four digits of the PAN which is allowed. However, you will have to confirm this fact.

Because you are maintaining only masked data, you are not required to encrypt this data.


If any of my assumptions/statements do not accurately portray your situation, let us know so that we can modify our response.

[AllanPoll]

Beg to differ. The standard only states that, as a maximum, only the first six and last four digits of a PAN can be 'displayed'.

As you're not harvesting complete PAN numbers I can't see what potential there is for fraudulent activity if this data is compromised.

[jbhall56]

Remember, data can be displayed straight out of a database or file through a SQL query or opening a file in WordPad or other program. So, if the PAN is NOT stored encrypted then it must comply with the display rule if it's stored in clear text in the database or file.

[cmark]

the PCI DSS only applies to Cardholder Data. That being said, if your system receives only the last 6 of the card, then technically it would not be considered CHD and PCI would not apply.

Here is an example....

Suppose I am providing marketing services where I recieve teh full PAN from a merchant. PCI DSS Applies. Now suppose I change my process so that every week, I receive a CD in the mail with only first six and last 4 displayed. PCI does not apply as the data I now have is not considered CHD and thus is not subject to teh PCI DSS.

It depends upon how you receive the data, the definition of the data, and the type of segmentation.

You can call me direclty if you want more information. 435-513-0484

[J.D. Oder II]

In addition, when they make the statement of "display" this normally relates to display of the number on a device or instrument that could be viewed or released into the public domain. Like for instance a cardholder copy of a receipt where of course the truncation requirement is even greater in that one can only display the last four of the PAN

[Doug]

Just to clarify, the conundrum we have is that because we store the type of card and place of issue, the first numbers of the PAN can be deduced. As this is the case then in conjunction with the last six digits we collect, we are effectively storing more than is allowed under the PCI DSS... The problem is that this is not explicitly spelt out within the standard so is open to some interpretation.

In summary we're going to treat this as a PCI DSS related issue and will ultimately seek acceptance from our acquirer / processor.

Thanks for the feedback provided.

[J.D. Oder II]

From a security standpoint I get what you are saying. From a PCI DSS standpoint the Issuer name would not be considered CHD. Issuers have countless BIN ranges for all sorts of card schemes (debit, credit, gift, ATM, switch, etc.) So a bad guy would have to guess right multiple times. Do you have to use the actual issuer name, or could you not store a value and then derive it programmatically?

[cmark]

JD is correct.

THe name, expir, and service code are only considered CHD if stored in conjunction with a PAN. THat is a PAN that is not sufficiently truncated or hashed. If the PAN is only showing the last six, then the cardholder name stored with it would not be considered CHD.

What it sounds like you are doing is what the card brands and industry wants. When companies can remove the burden of PCI by removing the data, everyone wins. Ultimately the goal is not to have companies build huge security infrastructures rather to minimize the risk to CHD.

AS I know JD will not get on his bully pulpit regarding this subject, his company Shift4 has created a service that accomplishes this goal. Check with JD and Shift4 about their Tokenization product and ForeGo. They remove the data from teh merchant...very compelling services and I believe it is indicative of where hte market is heading.