Any third-party service provider (TPSP) that stores, processes, or transmits cardholder data on behalf of your organization or could impact the security of your customers’ cardholder data, must meet the requirements of the PCI DSS. They must also be able to provide documentation that attests to that. Easy, right? After all, they say they are PCI compliant right on their website, so it must be true…
Before we dive into the common scenarios we run into with service providers, let’s talk first about what the PCI DSS states in terms of third-party service provider relationships.
PCI DSS Requirement 12.8
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 follows:
“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.”
Common service providers will include:
- Call center solution providers
- E-commerce payment providers
- Transaction processors
- Payment gateways
- Hosting companies
- Managed security services providers (MSSP)
- Companies providing secure media destruction services
- Third party marketing firms
- Vendors that perform POS maintenance
You are required by PCI DSS Requirement 12.8.4 to establish a clearly defined program to monitor service providers’ compliance and verify their status. During your discussions with a potential service provider, inform them that you have an organizational policy for all third-party service providers to provide annual evidence of PCI DSS compliance. The best form of evidence is a signed Attestation of Compliance (AOC) that has been properly completed and is less than twelve months old. Alternatively, you can choose to accept their status as it appears on the Visa Global Service Provider Listing. Service Providers who are eligible to self-assess should provide an AOC based on the results of a completed SAQ D for Service Providers. This SAQ would ideally be supported by a QSA signature, but is not required.
Also, as part of tracking your service providers’ compliance, per requirement 12.8.5, you must document which PCI DSS requirements are being met by the service provider, and which requirements are your organization’s responsibility. Keep a matrix of this information readily available.
You must also maintain a list of all service providers (Requirement 12.8.1) and check their PCI status at least annually. Per Requirement 12.8.3, proper due diligence is required for every PCI-related third-party service provider that your organization considers. We suggest that you work with your procurement department so they understand that any new service provider that will be handling cardholder information must first be evaluated and approved by the PCI Team.
In your contract agreements, include language that states that the service provider accepts responsibility for the security of the cardholder data they possess or otherwise store, process, or transmit on behalf of your organization (Requirement 12.8.2). Verify that the liabilities and responsibilities of the service provider are clearly stated and agreed to, in writing, so that you are not held solely responsible in the event of a data breach.
The Service Provider Response
These clearly articulated requirements should make it easy for a merchant to get the necessary information from their payment-related vendors, right? Unfortunately, when making a request to a third-party service provider for their AOC, you may not always get a positive response. They may respond with the requested documentation or an email showing their product on the Visa Global Listing.
Or…you will find that they go through different stages of compliance denial. First, they may ignore your request or delay answering you for many days. Then, they may sidestep the request by saying they are not required to comply because of some invalid reason. Common reasons given include “we don’t store cardholder information” or “we don’t process the payments; we use PayPal/Auth.Net/etc.” These responses should raise some concern as to their level of understanding of PCI, and cause you to question how comfortable you should be sharing your cardholder information with them. This may also indicate a preference to absolve themselves of responsibility in the event of a data breach.
As you continue to educate them on what you need, they may provide some form of documentation, however, it is often a merchant-level SAQ. Because of their status as a service provider, they are only eligible to complete the SAQ D for Service Providers (if their volume is under 300,000 Visa or 300,000 MasterCard transactions, making them a Level 2) or the Report on Compliance (Level 1 service provider which requires the ROC to be performed by Qualified Security Assessor). These are the appropriate analysis documents for them to complete, and from that analysis the service provider will have the information needed to complete their Attestation of Compliance; it is that AOC document that they should then deliver to you.
Another PCI document that may appear valid but is insufficient for Requirement 12.8.4 is the Attestation of Scan Compliance (AoSC). This document is used to indicate the service provider’s adherence to the requirement for quarterly vulnerability scans. While this is important, the AoSC is simply proof that they are meeting one of the PCI DSS Requirements, but not proof that they are fully compliant.
Recommended Next Steps
If the scenario above occurs when you are evaluating a new service provider, you may want to reconsider your options. Alternatively, you can work with them to determine what gaps they must address and identify the related risks for your organization. Depending on your overall compliance status, your relationship with your bank/acquirer, and the level of risk you are willing to accept, you may choose to continue moving forward. You should require that the third-party service provider establish a clear and effective plan to remediate the issues, and provide project timelines and milestones on a regular basis. Documenting the agreement terms, identified issues, and defined timelines will ensure that they can be held accountable and, if necessary, you can terminate the agreement.
If this is a service provider you are currently working with, and you are just now working to verify the compliance status of all of your TPSPs, you will want to ensure that they understand their obligations. Make sure your contract language states who is responsible for which components of PCI, and insist on receiving a valid, current AOC on an annual basis. Possibly include language that allows for your QSA or audit team to review their compliance progress.
Implement a defined organizational policy outlining if the organization will work with only Level 1 service providers, Level 2, or both. You can also determine what documentation will be acceptable, the appropriate due diligence that must be performed, how many days after a service provider’s expiration you can choose to opt out of contractual agreements, and the acceptable risk level.
Ultimately, your goal is to find a partner who has the same approach to PCI compliance and information security as you do, and one who understands the importance of both to your organization. Consult with your us if you have questions about a service provider your organization is contracting with.
Some additional guidance from our Security Advisor team below:
[Henninger]: There are several scenarios where service provider compliance can affect an organization. A common higher education example is when the institution’s IT department supports the systems and infrastructure of the Foundation or Alumni Office, which, for public institutions, is usually a separate 501(c)3 organizations with separate banking relationships. In this case, the IT department is a Service Provider and must attest compliance to the Foundation. This realization can prompt a lot of changes to the relationship and impact how support is provided by IT.
Another example is the third party service provider with a website that involves interaction with the organization’s customers, but doesn’t directly process cardholder data. The service provider states that they redirect the customer to a PCI-compliant payment processor but, as they do not touch cardholder data, they do not need to be compliant. Any redirection of a customer to a payment site can affect the integrity and security of cardholder data, therefore, the service provider must attest compliance.
Lastly, consider those third parties that have their own merchant ID’s but are accepting payment cards on your campus. Should they have a breach, they would be responsible for fines, but your institution would bear the brunt of the reputational damage. Contracts are the key here.
