Non-Merchant/Service Provider Entity...PCI On-Site Audit Required?

[mpr131]

Hello,

My client is a non-merchant entity but has a large card program with over 6 million txns a year and uses multiple charge-card providers who act as issuing banks. My client is now looking to store all their transaction information into a single data warehouse for a program-wide view of its data. This information will include items such as PAN, Name, etc. Since my client is not processing transactions and is not classified as a merchant or service provider, will they still need to abide by the VISA and MC merchant/service provider level validation requirements (i.e. merchant/service provider levels 1/2/3/4) for a yearly on-site audit? Or can they follow the PCI standards v1.1 and be compliant?

Basically, do the VISA/MC level validations apply to issuing bank side of the transaction, ultimately impacting my client.

Thanks

[lyalc]

This is a good question to ask your friendly banker!

There is nothing in PCI that limits it only to the payments side of the credit card lifecycle.

In short, PCI compliance applies unless all the individuals issuers say otherwise.

Remember, PCI is a tool to manage risk of cards compromise through out the lifecycle - issuing, acquiring and eventual settlement of the card statement.

Lyal

[jbhall56]

Based on my interactions with similar companies, the answer is an emphatic YES, they need to be PCI compliant.

Regardless of whether or not their data sources are asking them to be PCI compliant, they are still storing data covered by the PCI DSS and therefore need to be compliant.

They can wait for these external entities to ask, but that's not the smart way to handle this situation. It's much better to be proactive before a incident occurs and everyone ends up looking bad. Their executive management needs to answer the questions, "Can we implicitly trust our users and IT personnel to protect this data at all times?" and "Are we willing to risk our company and its reputation by not being PCI compliant?"

Most executives will not be able to comfortably answer these questions and will get behind PCI compliance in a hurry.

[mdahn]

This is a great question and involves a very long answer with multiple cavieats. But here's the short version...

Issuers have certain security obligations for their issuing side of the business (i.e. creating and storing track data for authenication, embossing of cards, etc.) There are many service providers involved in this and if your client is not an issuer themselves, then they are a service provider to one.

If they are providing services that support the issuing side of the house then they will fall under those security requirements. For example, if they need to receive track data to encode the cards then they have an exception for this. Otherwise, they need to be compliant with PCI DSS for all other cardholder data storage, processing, or tranismission.

The big question is, even though they need to be compliant, do they need to validate their compliance? If they are a serivce provider then yes.

[Sergey_Shustikov]

The big question is, even though they need to be compliant, do they need to validate their compliance? If they are a serivce provider then yes.

Excuse me, I have some questions about issuer validation:

1. Does the issuer bank itself, that has all infrastructure for card issue, that process and store all CHD during it, need PCI DSS validation? Can it be considered to appear as a service provider for itself?

2. The bank makes in-house processing, has both acquire and issue part of it's infrastructure. Does QSA-auditor have to validate PCI compliance on both parts?

3. If I, as a QSA-auditor, during audit have noticed a non-compliance in card issue part of bank's infrastructure, have I to write about it in the ROC?

[jonassono]

Excuse me, I have some questions about issuer validation:

1. Does the issuer bank itself, that has all infrastructure for card issue, that process and store all CHD during it, need PCI DSS validation? Can it be considered to appear as a service provider for itself? No, the issuing side of a bank is not subject to PCI-DSS requirements. However, if the same bank is operating in the capacity of an acquirer or service provider, that entity is subject to PCI-DSS.

2. The bank makes in-house processing, has both acquire and issue part of it's infrastructure. Does QSA-auditor have to validate PCI compliance on both parts? Acquire only

3. If I, as a QSA-auditor, during audit have noticed a non-compliance in card issue part of bank's infrastructure, have I to write about it in the ROC? No, as the issuer does not have a requirement to comply with PCI-DSS and, is, therefore exempted or ultra vires. Issuers are closely regulated by a gaggle of other legal & statutory requirements plus a host of contractual obligations with the card brands. Trust me, the issuers have more watchdogs than the U.S. Bullion Depository in Fort Knox.

[ADail]

No, as the issuer does not have a requirement to comply with PCI-DSS and, is, therefore exempted or ultra vires. Issuers are closely regulated by a gaggle of other legal & statutory requirements plus a host of contractual obligations with the card brands. Trust me, the issuers have more watchdogs than the U.S. Bullion Depository in Fort Knox.


IIRC the one exception is if an issuer is issuing BINS from another registered issuer (rent-a-bin). The theory also being that the issue actually is the entity carrying the fraud liability for breaches, although Acquirers and Merchants would call B.S. as they'll be fined & sued, but at the end if the day, if they can't pay, the issuer eats the fraud.

[Sergey_Shustikov]

Thank you very much! :)