A discussion came up on the last PCI Dream Team session regarding situations at universities that have bookstores and cafeterias operated by third parties on their networks and those vendors processing payment card transactions. QSAs encounter this situation not only at universities and colleges, but also with hospitals, health clinics and large corporations.
The Situation
As organizations focus on customer and employee perks, QSAs encounter third parties operating business outlets within a variety of organizations. These businesses include coffee shops, convenience stores, dry cleaners, bookstores, restaurants, cafeterias, parking ramps, travel agencies, pharmacies, health clubs and a whole host of other businesses. Of course, all of these third parties accept payment cards for their services and need a way to process those cards. Organizations offering these perks have existing wired and wireless infrastructure that get leveraged to connect these third parties to the internet and their payment processors. Thus, bringing that network and everything attached to that network into scope for PCI compliance.
As a result, this situation creates a PCI compliance problem because the organization is now a service provider as well as a merchant. The organization thought by outsourcing these businesses it was reducing PCI scope not increasing scope. But scope increases because since they are now considered a service provider, they must provide each of these third parties with a Service Provider Attestation Of Compliance (AOC) for that network connectivity.
But it can and does get worse. I have encountered situations where the outsourcing organization provides help desk, firewalls and other support services for these third parties, further complicating their PCI compliance responsibilities.
What Do You Do? Option 1 – Get Out Of Scope
There are some ways to get out of scope, but these can be complex and/or expensive.
The first way to get out of scope is to force all of your third parties to get their own network connectivity from their own internet service provider (ISP). The problem with this is that an ISP will likely have to run wire into your facilities to make those connections. That can be disruptive as well as expensive and complicated due to locations within existing buildings. And what if each business wants their own ISP because of a contract relationship? That will mean multiple ISPs tearing up your facilities. Not necessarily the best situation.
The most extreme solution to get out of scope is for the outsourcing organization to implement carrier equipment and become a “carrier” to these third parties. I have had a few clients go down this road, but it is not cheap and can also be more trouble than it is worth. However, for a university or large hospital/clinic complex with lots of third parties, this solution can actually be a cheaper route to implement and operate.
But the beauty of these solutions is that your organization is totally out of scope so there are no service provider PCI assessment requirements.
What Do You Do? Option 2 – Reduce Scope
There are also a couple of ways to reduce scope. But reducing scope requires at a minimum the creation of a Service Provider SAQ D and AOC.
The quickest and easiest way to reduce scope is that the outsourcing organization can implement end-to-end encryption between the third party’s connection and the internet. However, this adds the requirements in section 4 to the assessment as well as keeps the endpoints in scope for PCI compliance.
Another option to reduce scope is to require these third parties to implement encryption from their operation to anyone outside of the outsourcing organization. While this seems simple, it usually never is simple. Never mind the fact that if that encryption is ever stopped (most times without your knowledge), the outsourcing organization’s network is back in scope. Typically, when this gets brought up as a solution, a lot of the third parties balk or say they do not know how to encrypt their connections. Never mind the fact of the complexity of proving that the outsourcing organization does not have encryption keys and that every third party connection is encrypted becomes problematic. It ends up more trouble than it is worth.
The only good news about reduced scope is that you only need to fill out a Service Provider SAQ D and AOC because you have no idea the transaction volumes being processed by any of these third parties. That said though, it is additional paperwork that needs to be filled out annually and given to all your third parties.
Heaven help you though if you offer firewall, help desk and other support services in addition to connectivity. Those just complicate your compliance and reporting efforts. All I can say is, if you can stop offering those services, stop. If you cannot stop those services, then be prepared to document and report on the PCI compliance of each of those services. That can be done in a single assessment, but the AOC must cover each of those services provided individually in a separate section 2g.
Never mind the fact that if some of those services offered give your organization insight into the number of transactions processed by your third parties such as you provide payment processing under one or more of your merchant identifiers, you may end up having to conduct a Service Provider Report On Compliance (ROC) because the transaction volume exceeds one of the card brands’ annual service provider transaction volumes.
There you have it on third parties and their payments on your network.
PCI Guru 
I work for a major University and have heard this before, but it perplexes me. These third-party entities that use the campus network have their merchant contracts, which are almost always with a different acquiring bank. It is my understanding the credit card brands fine the acquirer, who then fine the merchant. These acquiring banks follow guidelines established by the card brands, such as requiring a compliance documentation. I am curious if you can provide an example of when such fines have been levied on a third-party who is only providing Internet as a service?
I know the fines imposed by the credit card brands are not publicly disclosed. They are contested in court. I would think these types of fines would be contested in court.
Overall, I am a fan of your blog and read it frequently.
If a third party is not part of the payment process, if that third party is found to have been the cause or created a situation that caused a breach, they would be likely taken to court by the parties actually fined/penalized by the banks/brands for recovery of losses.
Where this would likely come into play is in a situation where the third party did not properly control/manage/monitor network segmentation and an attacker gained access to a merchant’s POS solution and then leaked CHD/SAD. Under this scenario, the merchant and its bank(s) would likely sue the third party for failing to properly secure the network to protect the merchant.
I have encountered such a situation in a university setting where the computer science department inadvertently released malware they were studying into the university’s network infecting students’, faculty and visitors’ equipment. The lawsuit filed recovered damages from that attack and resulted in the computer science department to segment a portion of their network away from the general network of the university.
The PCI SSC under their glossary of terms for a “Service Provider” states “If an entity provides a service that involves only the provision of public network access—such as a telecommunications company providing just the communication link—the entity would not be considered a service provider for that service (although they may be considered a service provider for other services).” https://www.pcisecuritystandards.org/pci_security/glossary
This implies that if an organization has third parties operating business outlets within their IT purview, the organization can descope by isolating this third-party traffic and implementing a contract with the third-party that stipulates each third-party is fully responsible for their own PCI DSS compliance and that the organization is not considered a service provider.
The Council has been VERY clear when they have defined the service provider definition. Basically, only a common carrier for telephone service is out of scope for a service provider. Everyone else is a service provider and needs to be assessed.
What if the 3rd party is only using a P2PE pinpad and gets a confirmation from his acquirer that the traffic is encrypted? Would the University still be considered a service provider as they couldn’t impact the security of CHD in this case?
You are absolutely correct UNTIL … The merchant in question makes a change to their POS or you get a new merchant and the entity does not know that the change occurred until their next assessment.
My apologies, not sure I’m following here. So if the 3rd party IS using P2PE hardware are they out of scope from the organizations (university) perspective – despite piggybacking on the network?
If they are using P2PE and are out of scope for PCI I’m assuming the organization would still have to have very robust agreements in place to ensure the 3rd party notifies them of when and if their terminals are changed, how they are connecting to the network, provision of P2PE validation, etc.?
Does the 3rd party have to complete a P2PE SAQ and provide to the university?
Just trying to understand the proper approach to take.
Thank you, your blog is excellent!
The problem is that the merchant TODAY is using P2PE. Then the entity changes from Barnes & Noble to Al’s College Books and Al’s is NOT using P2PE but no one from the University checks on that fact. That is the problem we constantly run into at hospitals, clinics and universities. Everything is great until something changes.
Yes, the entity will need good contracts that outline responsibilities regarding compliance with all relevant laws and regulations such as PCI, HIPAA, etc.
You can try to obtain the outsourcers’ AOC, but that is not going to provide you assurance that what is running over your network keeps your organization out of scope. It just means that the outsourcer is PCI compliant.
In my experience, many of the validated P2PE solutions scoping guidance documentation mandate both the POI device and the firewall are in scope. If this is the case and organization also provides firewalling services to the third-party, they would be considered a Service Provider under the PCI DSS.
With P2PE though, the firewall should be out of scope because it should not be able to decrypt the packets.
What I’ve seen is similar to this, using your example: The bookstore/cafe had been running for years and previously only took cash but had a university network connection for browsing the internet etc/hosting their website. Then, years later they just introduce card payments for convenience. In these cases, they haven’t sought any agreement with the university and have just started taking payments. I assume in these cases, responsibility is solely on the third party business as the fact that the cardholder data running over their network was never agreed upon and therefore how can the university be considered a service provider, they just provide Internet connectivity?
I’ve just advised them to tell the third parties that they are not a PCI service provider and then if the third party continues, it’s not anything to do with the university and it’s the third party’s non-compliance.
A number of these third parties have then moved to an iZettle type product where they use the mobile network/wi-fi to connect their tablet to the Internet to manage transactions or have used the phone line for the chip and pin machines, rather than the network.
If the access to the internet is provided through the university’s network (wired or Wi-Fi), the university is a service provider under the PCI DSS. In almost all cases, there is more than just an internet connection being provided such as firewalls, IDS/IPS, content filtering, and other infrastructure. Under the PCI DSS, all of that infrastructure is in scope as are all of the administrators that manage it. Legally, this all gets covered by the merchant agreements signed by the university and the third parties with their respective acquiring banks. All of them in your scenarios are violating their merchant agreements and can be fined and assigned penalties.
If only access to the Internet is provided to the third-party and that access is isolated from the organization, I think it’s possible to take a defensible position that the organization is not a service provider based on the PCI SSC definition “If an entity provides a service that involves only the provision of public network access—such as a telecommunications company providing just the communication link—the entity would not be considered a service provider for that service (although they may be considered a service provider for other services).” Also, as an example, many ISPs use ACLs to prohibit access to ports 25 and 80 and these same ISPs are not considered service providers even though they are firewalling these ports. If the organization isolates third-party traffic and is not in violation of their merchant services agreement, as a QSA, I would accept the idea that the organization can remove the “Service Provider” label and transfer PCI responsibility and risk back to the third-party using contractual agreements.
The trouble is that 9 times out of 10, there is a firewall, load balancer and other devices in that path so there are people managing and maintaining that connectivity beyond just providing “connectivity”.