We tend to focus a lot of attention on third-party payment applications and e-commerce websites due to the increased risks and recent data breaches, but what about those third-party vendors that are physically residing on your campus?
Requirement 12.8 states that organizations must maintain and implement policies and procedures to manage third-party service providers. A service provider is defined by the PCI SSC as a:
“Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity. This also includes companies that provide services that control or could impact the security of cardholder data.”
There are many variances in how different relationships are configured, so your organization will want to review each third-party vendor on a case-by-case basis to ensure they are not creating unnecessary risk or additional compliance requirements for your organization. Take advantage of your CampusGuard QSA (little secret…the Security Advisors may seem nice, but they are very used to being the “bad guy” when it comes to requiring third-party compliance!).
Below are some of the more common service provider relationships we come across during our PCI Assessments, along with a high level summary of your organization’s PCI compliance responsibilities.
- Relationship
- PCI Compliance Responsibilities
- Your Organization owns the Merchant Identification Number (MID)
For those service providers that are operating under one of your organization’s bank-issued MID, you are responsible for attesting PCI compliance. Before any contracts are signed, the vendor should go through your due diligence process to verify their PCI compliance status (verify all requirements are being met from DSS requirement 12.8).
Request the AOC for the SAQ D-SP. AOCs are required to be updated and collected annually so you want to verify the completion date on the provided documentation.
You will also want to work with Procurement to ensure all agreements have the necessary PCI language included and all responsibilities are defined between the vendor and your organization.
Service Provider Owns the MID
If the vendor holds the MID and just issues funds to your organization or merchant(s), they own the PCI compliance responsibilities and attestation, but it is still recommended that you request their AOC. In this situation, they can provide a merchant SAQ/AOC based on their payment methods (SAQ A for e-commerce, SAQ B-IP for network connected devices, etc.).
Service providers that supply their own network and equipment, and are the merchant of record
In this scenario, your organization is solely providing space on campus and an electrical connection so you do not have to attest compliance for this account. However, we recommend having a contract in place that covers their potential impact on cardholder security and requesting their compliance documentation as there is still the risk of reputational damage to your organization if they were to experience a breach.
Service provider is the merchant of record and provides their own equipment, but may be connecting to your organization’s network
Ideally the vendor brings in their own network connection so that they are fully responsible for their entire solution. But in situations where they use your network, we can work to decrease the risk/liability for your organization.
Start by verifying the solution and equipment the vendor is using. If the vendor is using a PCI-listed P2PE solution that would take the network out of scope, so the agreement would just need to define who is responsible for the equipment, performing inspections, etc.
If the solution isn’t P2PE then you will want to ensure that contract language is in-place clearly stating that your IT Team is doing nothing for that network connection. There is a provision within the PCI DSS that allows your organization to act as an ISP, in which you are only providing Internet connectivity. In this scenario, your organization is not providing any additional services beyond infrastructure – no managed ACLs, firewalls, no assertions of security, etc.
Service provider is the merchant of record, but your organization provides equipment and connectivity
If a third-party is using your organization’s equipment (e.g. terminals, computers, etc.) when entering cardholder information and that equipment resides on your network, this can place your organization in the service provider role and you are fully responsible for the PCI compliance of the system. This setup requires significant business and technical controls to ensure adequate network segmentation, dedicated workstations, logging, pen testing, file-integrity monitoring, and so on. Your organization will want to avoid this scenario if possible.
Vending machines – generally connected to a cellular network
The vendor owns the majority of the PCI compliance responsibilities, but there can still be pitfalls in these scenarios. We recommend that within the contract you identify who is checking those devices for tampering/substitution, and ensure any responsibilities for your organization are clearly defined.
Temporary vendors (i.e. food trucks that may be connecting to the public wireless while on campus)
Verify that your wireless network language/disclaimer is in place for anyone who connects to it. Alternatively, have the vendor sign a contract acknowledging that the network is not secured by your organization and they are “using at their own risk”. You may also want to review the equipment they are using as an information security best practice.
How can you get ahead of situations like these, ensure new vendors on campus are compliant from the onset, instead of spending time and resources after the fact to correct them?
Your Procurement team can be a great resource and should know to contact you when new proposals or requests related to payments come in. Their procedures should specify that anytime they receive a contract that mentions payment card information in any way, they need to involve the PCI Team or appropriate office. That way you can review what is being proposed, assist in the determination of the vendor’s compliance status, and provide the necessary contract language regarding PCI compliance responsibilities, required documentation, etc.
You can also include procurement in your general PCI awareness training each year so they are up to date on the importance of compliance and more educated about potential PCI red flags that may come across in contracts. Ensuring staff are also participating in this training will also go a long ways in preventing them from signing a new third-party contract without following the official due diligence process outlined in your payment card policy.
Some additional guidance from CampusGuard’s Security Advisor Team:
[Hobby]: Colleges and universities often use third-party service providers to handle aspects of their payment card processing. As mentioned above, the PCI DSS requires merchants to oversee the compliance of those third-parties. There are three areas key to performing this oversight:
Due Diligence: Third-party service providers should be vetted for PCI compliance. This vetting should ensure third-parties appropriately manage security threats and risks. Also, be sure to understand if your third-parties have contracted other third-parties themselves.
Written Agreements: Organizations should have written agreements with all Service Providers ensuring that those Service Providers understand and formally agree to their responsibilities and obligations. CampusGuard does have examples of sample contract language for many of the outlined scenarios and can work with your teams on these agreements.
Regular Review: Organizations should have a monitoring program in place for tracking their Service Providers’ PCI DSS compliance status ongoing.
I’ll end by emphasizing that while Service Providers are often both beneficial and essential to your payment card processing, they represent significant risk. The Ponemon Institute reports that almost 60% of companies have experienced a data breach caused by a third-party, and that third-party involvement is the single most expensive factor in the cost of breaches (Data Risk in the Third-Party Ecosystem, 2018). The PCI SSC has also issued its own guidance: Third-Party Security Assurance.
