Checklist for Third-Party Service Providers

Article Third-Party Service Providers
Third-Party Service Providers


The PCI SSC defines a third-party service provider (TPSP) 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.”

All TPSPs must meet the requirements of the PCI DSS and they must be able to provide appropriate documentation that attests to that. As you are evaluating potential third-party vendors, you may want to reference this quick checklist to make sure you have all of your PCI “ducks in a row”.

Who owns the Merchant ID?

If a third-party business entity processes cardholder data on behalf of a Merchant, and the transactions are processed using a Merchant ID (MID) obtained by the Merchant from the Merchant’s acquiring bank, that entity is a PCI Service Provider for the Merchant and falls within the Merchant’s scope of PCI DSS compliance.

  • If the TPSP owns the MID, then they own the responsibility for adherence to the PCI DSS and there is no impact on your organization’s PCI compliance status. You may choose to request proof of compliance annually from these vendors, but it is not required for your PCI compliance. Note: a breach of this vendor could still cause negative impact to your organization through reputation (the fact that you were working with them) but the compliance failure would not be your responsibility.
  • If your organization holds the MID, then there is an impact to your PCI compliance and you will need to continue on with this checklist.

Tracking Service Providers

In order to make sure you are asking for the right things from your TPSPs, you must first ensure that you are tracking them. PCI DSS Requirement 12.8.1 requires that you maintain a list of service providers. Document the location of this list and make sure that every new vendor is added and those that are terminated are removed. The format of the list is not defined by the PCI DSS but should include at least the name and description of services in order to be able to complete Part 2f of your AOC/SAQ.

PCI Language in the Contract

Any service provider that you bring in will be working with your Legal team to complete a contract that includes terms from both parties. All payment-related contracts must include an acknowledgement that the service provider understands and accepts their responsibility for the security of the cardholder data that they handle on your behalf, or at least to the extent that they could impact the security of your cardholder data environment. PCI DSS Requirement 12.8.2 does not dictate the specific wording that must be included in the contract as that will vary depending on the relationship between your organization and the TPSP, the service(s) being delivered, etc. A templated copy of draft language that can be included is available through your CampusGuard Team.

Approval Process

Before implementing any new vendor solution, the vendor and proposed solution must be reviewed and approved by the PCI Team or other department as directed by policy. PCI DSS Requirement 12.8.3 asks if there is an established process, including due diligence, that occurs before any new payment-related solution is rolled out. The robust review should not only include processes to obtain assertions from the service provider that it meets compliance regulations, but also include a thorough understanding of what payment channels will be handled by the new product (e.g. in-person, online only, via telephone, etc.) both now and any future plans, and a review of the TPSPs current PCI-compliance status. This conversation is also when you can begin to document exactly who is going to do what and begin to build out the matrix discussed further down (Requirement 12.8.5) as this will help you to understand the resource requirements for your organization.

Verification of Compliance – Option 1

In order for you to be compliant with PCI DSS Requirement 12.8.4, you must have a documented program in place that allows you to gain an understanding of the PCI-compliance status of your TPSPs at least annually. One way to do that is to collect a properly completed and scoped AOC from the service provider that is 12 months or less old. TPSPs that are eligible to self-assess should provide the AOC from an SAQ D for Service Providers. TPSPs that are classified as a PCI Level 1 Service Provider will need to provide an AOC from an Onsite Assessment (also known as a Report on Compliance or ROC). Unfortunately, many TPSPs may attempt to provide an AOC from the merchant-level SAQ A or SAQ A-EP or assert that since they’ve outsourced payment handling to a PCI-compliant third-party that they don’t need to be PCI compliant or provide an AOC at all.

Obtaining AOCs from TPSPs has proven to be much easier said than done, especially with smaller vendors who are less familiar with the PCI DSS. You can avoid some of this by having the TPSP agree to provide an accurate, updated, and appropriate AOC annually through the term of contract.

Verification of Compliance – Option 2

If your internal policies list checking the Visa Global Registry of Service Providers as an approved method by which to validate TPSP compliance, you can use the Visa registry to obtain evidence that the TPSP is compliant with the PCI DSS. Only the larger TPSPs and those that elect to validate as a level 1 service providers will be on the Visa registry, as Visa will not accept or publish AOCs of TPSPs that self-assess. Your procedures should include the annual process for confirming the TPSP’s status (e.g. saving a screenshot of the Visa registry page) as documentation for your adherence to the requirement.

Document PCI Responsibilities

Do you understand what PCI DSS requirements are being met by the service provider, and which requirements are the merchant/organization’s responsibility? This requirement was added to the PCI DSS because many data breaches were occurring due to the fact that each party thought that the other was maintaining the security controls. Common scenarios that cause questions are those where equipment is provided but it is not clear who is responsible for inspecting the devices periodically for tampering/substitution. PCI DSS Requirement 12.8.5 dictates that you maintain information as to which requirements the TPSP is responsible for, which ones you are responsible for, and which ones where you share that responsibility. Ideally, you will work with the vendor to complete a matrix of responsibility for each applicable requirement but, even if they won’t participate, you are still responsible to have done the analysis and documented those requirements that apply to you.

The use of third-party solutions often provide opportunities to bring new technology and services to your organization and your customers. This checklist can help ensure the use of a third-party solution does not negatively affect your PCI compliance status and allow you to properly monitor their compliance ongoing.


About the Author
Katie Johnson

Katie Johnson


Manager, Operations Support

As the manager of Operations Support, Katie leads the team responsible for supporting and delivering CampusGuard services including online training, vulnerability scanning, and the CampusGuard Central® portal. With over 15 years of experience in information security awareness training, Katie is also the Product Lead for CampusGuard’s online training services. As a Senior Customer Relationship Manager for a limited number of customers, Katie assists organizations with their information security and compliance programs and is responsible for coordinating the various teams involved.