Contracted Vendors and 12.8

[BrianR]

We contract with multiple vendors to provide food service to individuals on our campuses. The contracted services include accepting credit cards for payment at the various dining establishments. The vendors own the terminals used to process CC transactions. Transactions are transmitted to their respective acquiring banks/processors over network connections maintained by the vendor. None of the CC information is resent to us or stored within our systems. I am having trouble understanding if this arrangement puts us into the cross hairs of PCI DSS 12.8 by considering the vendors as third-party "service providers". Specifically, I am trying to understand if our contracts with the vendors should include provisions they operate within the requirements of PCI DSS. Any help I can get with this is greatly appreciated.

[lyalc]

Who is the merchant of record?
If yourselves, then 12.8 would apply and the vendor has a compliance obligation to you and or an acquirer/card brand.

If its the vendor/contractor, then you probably don't have any PCI obligation in respect of the described situation, while the vendor would have a compliance and a reporting obligation.

lyalc

[BrianR]

The vendor has a contract to conduct business on the property and collect CC's as a payment method. They maintain merchant status with the organization they use to clear payments and are responsible for their own SAQ to that entity. If this condition exempts us from PCI DSS compliance under 12.8 - are we responsible for ensuring they (the vendor) are PCI compliant in our contracts under any other sections of PCI?

[lyalc]

So the vendor is the merchant of record, and thus responsible for compliance.
You may have a PCI responsibility in terms of premises/physical security.

Generally, that vendor's Acquirer will manage and track their PCI DSS compliance.

lyalc

[BrianR]

Thanks for the reply. So the key point is who holds the "merchant" status in these type of arrangements. The vendor in question does not process transactions via any of our merchant accounts so they are not considered a "service provider" and therefore our organization does not need to meet 12.8 requirements in this situation.

Have you seen similar situations/contracts were the contracting entity at least stipulated the vendor maintain PCI DSS/PA DSS/PED compliance even if it is not a PCI requirement to do so? I fully understand it is the "merchant" status that triggers 12.8 compliance when dealing with third parties. It just seems like it would be to our advantage in this particular situation to include PCI DSS provisions to protect us from a legal standpoint.

[wconway]

Have you seen similar situations/contracts were the contracting entity at least stipulated the vendor maintain PCI DSS/PA DSS/PED compliance even if it is not a PCI requirement to do so? I fully understand it is the "merchant" status that triggers 12.8 compliance when dealing with third parties. It just seems like it would be to our advantage in this particular situation to include PCI DSS provisions to protect us from a legal standpoint.

As you point out, I have seen many schools that have outside vendors for food service and other things. The outsiders are their own merchants, use their own systems, and do not use the school's network. (BTW, make sure they are NOT on your network.) While I haven't seen requiring PCI compliant for a campus merchant, I agree it is a good idea since it protects the brand of the school. Think about it: if there is a breach, which makes the better headline, some small burger joint or the school?

[BrianR]

Thanks Walt! I wish I could attend the Treasury conference in May (have to blame the lack of budget). The last conference I was able to make was a couple of years ago in Chicago. It was a great learning/networking experience.

[djnavetta]

Thanks for the reply. So the key point is who holds the "merchant" status in these type of arrangements. The vendor in question does not process transactions via any of our merchant accounts so they are not considered a "service provider" and therefore our organization does not need to meet 12.8 requirements in this situation.

Have you seen similar situations/contracts were the contracting entity at least stipulated the vendor maintain PCI DSS/PA DSS/PED compliance even if it is not a PCI requirement to do so? I fully understand it is the "merchant" status that triggers 12.8 compliance when dealing with third parties. It just seems like it would be to our advantage in this particular situation to include PCI DSS provisions to protect us from a legal standpoint.

Brian I think your analysis is on the right track. It is always best to go back to the language of PCI and even the PCI glossary. In this case the key questions are: (1) are these entities "service providers"; and (2) if so, is cardholder data "shared" with those service providers (see wording of section 12.8).

These questions unfortunately are trickier than they should be. The PCI Glossary defines "service provider" as:

Business entity that is not a payment card brand member or a merchant directly involved in the processing, storage, transmission, and switching or transaction data and cardholder information or both. This also includes companies that provide services to merchants, services providers or members that control or could impact the security of cardholder data. Examples include managed service providers that provide managed firewalls, IDS and other services as well as hosting providers and other entities. Entities such as telecommunications companies that only provide communication links without access to the application layer of the communication link are excluded

Frankly, this is a horrible definition. Not to mention that the card brands have their own definitons of "service provider."

Be that as it may, it appears that by the PCI Glossary defintion an entity that is a merchant cannot be a service provider. However, the PCI Council's own FAQs contradict this and indicate that a merchant can act in a service provider role:

What is the definition of "merchant"?

For the purposes of the PCI DSS, a merchant is defined as any entity that accepts payment cards bearing the logos of any of the five members of PCI SSC (American Express, Discover, JCB, MasterCard or Visa) as payment for goods and/or services. Note that a merchant that accepts payment cards as payment for goods and/or services can also be a service provider, if the services sold result in storing, processing, or transmitting cardholder data on behalf of other merchants or service providers. For example, an ISP is a merchant that accepts payment cards for monthly billing, but also is a service provider if it hosts merchants as customers.

Note that none of these definitions reference "merchant ID" and are fairly broad. Nonetheless, I think the merchant ID issue is relevant (I would love some back up documentation on this), and that certainly your vendors on some level are acting as merchants. The question is, are they also somehow acting as "service providers" to your organization?

Questions: Are these vendors selling their own goods (e.g. food) or are they selling your organization's goods on your behalf? What does it mean to "store, transmit or process" cardholder data "on behalf of" a merchant?

On the 12.8 question, is there "sharing" of cardholder data in this context? Again, depends on how you define "share." Does providing them physical access to a location where they collect cardholder data constitute sharing? Probably, especially if they were using your organization's merchant ID. Some could argue that the definition of share (at least in every day life) is more narrow -- e.g. I possess something and then share it with you. These appear to be issues of semantics, but I have had real life situations where the concept of sharing was not so clear in the PCI context.

Anyway, on the whole I think you are on the right track with this. My point is to be careful. Always go back to the written source documents. If you obtain advice (like it is the merchant ID that determines status) try to ask for the source of that advice (it is better if you can point to something in writing).

On your second question, whether you should include some language in your contracts around PCI, I agree with Walt. The university is the one who is going to get the heat (and potentially sued) if one of your campus vendors gets hit with a security breach. Requiring them to adhere to PCI is something to consider. More importantly, put iindemnification language in the contract that requires them to indemnify you if they suffer a security breach and you get sued. Also, for purposes of breach notice laws, make sure you require them to take on the expenses of providing notice if they suffer a breach.

[BrianR]

David - I appreciate your insight on this topic. My report observation for this item will include the contract language you suggested. Looks "spot-on" to me.

[jonassono]

I am assisting a large university with their PCI-DSS validation via SAQ D and merchant AOC. We have dozens of private sector companies (merchants) on campus that process all manner of payment card brands for food, beverages, clothing, etc. However, they are entirely independent of the U and therefore lie outside our scope of review.

To put it more crudely, we don't care a rodent's posterior to know whether they are PCI-DSS compliant or not. Nor do we care to know if they are SOX compliant or file annual corporate tax returns.

In contrast, we have hundreds of merchants that also process all manner of payment cards in the form of faculties and service/support departments that eventually report up through to the U Board of Directors. Their PCI-DSS compliance status concern us immensely.