‍

The sharing of cardholder data (CHD) for goods and services is extremely common in any industry, so customers have to rely on businesses to fully safeguard their payment card information.

‍

The Payment Card Industry Data Security Standard (PCI DSS) aims to protect cardholder data and reduce credit card fraud by providing a set of security standards designed to ensure that all companies that accept, process, store, or transmit credit card information maintain a secure environment.

‍

The goal of the standard is to protect cardholder data and reduce credit card fraud. The PCI DSS is overseen by the Payment Card Industry Security Standards Council (PCI SSC), which was established by the five major credit card brands—Visa, MasterCard, American Express, JCB, and Discover.

‍

The standard has specific requirements for working with third-party service providers, which we’ll outline in this guide. You’ll also learn about the systems and processes you should implement to comply with PCI DSS and manage related third-party risk requirements effectively.

‍

How PCI DSS impacts third-party risk management

PCI DSS allows organizations to outsource credit card processes—particularly those related to CHD sharing—to third-party service providers (TPSPs).

‍

A TPSP can be any entity that isn’t necessarily a payment brand but is directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity. Examples include:

‍

• Payment gateway service provider
• Hosting providers
• Managed service providers
• SaaS providers
• Credit reporting service

‍

Since these TPSPs have access to highly sensitive data, the goal of PCI DSS compliance is to ensure the integrity of CHD remains intact. As a result, you need to adopt certain security practices within your third-party risk management (TPRM) program that lets your organization demonstrate a solid security posture to its stakeholders.

‍

While PCI DSS isn’t mandated by any law, compliance is required if your business processes credit or debit card transactions. Adhering to the standard also helps bolster customer trust.

‍

{{cta_withimage20="/cta-modules"}}

‍

PCI DSS: 5 key third-party risk requirements

The third-party risk management guidelines of PCI DSS are outlined in Requirement 12.8:

‍

“Establish and implement policies and procedures to manage service providers where cardholder data is shared or may affect cardholder data security."

‍

The requirement is quite elaborate and has five sub-requirements:

‍

1. 12.8.1: Maintains a list of all TPSPs
2. 12.8.2: Maintaining written agreements for TPSPs
3. 12.8.3: Conducting pre-engagement due diligence for TPSPs
4. 12.8.4: Conducting annual assessments of TPSPs
5. 12.8.5: Establishing accountability of TPSPs

‍

We’ll go over the practical implications of each sub-requirement below: 

‍

1. Sub-requirement 12.8.1: Maintaining a list of all TPSPs

‍

PCI DSS sub-requirement 12.8.1 outlines the need to list all TPSPs that manage or can affect the security of your organization’s CHD. The list must include:

‍

• All TPSPs with which account data is shared or TPSPs that could affect the security of account data
• A description of each of the services provided

‍

It also requires organizations to develop dedicated processes for maintaining the list so that they can stay on top of all relevant risks to CHD.

‍

The TPSP list described in this sub-requirement is similar to a vendor inventory, and creating one is already a popular TPRM best practice. However, you may not want to use spreadsheets here as the records can be tedious to keep track of. It’s better to leverage a software solution to create a TPSP inventory that’s easy to access and update on the go.

‍

2. Sub-requirement 12.8.2: Maintaining written agreements for TPSPs

According to sub-requirement 12.8.2, you must maintain written agreements with all TPSPs that can impact your CDE security (or any TPSP you share CHD with).

‍

Its immediate practical implication is that your agreements should contain acknowledgments that the TPSP is responsible for the security of the account data it possesses, stores, processes, or transmits on behalf of the entity. It’s better to clearly lay out the acknowledgement terms in the agreement—for instance, by detailing all the necessary controls a TPSP is expected to implement.

‍

You must then take steps to verify if the agreement is being honored over time. However, the verification processes can be time-consuming due to the need for extensive evidence collection and analysis across TPSPs.

‍

The good news is that you can streamline these processes using a vendor risk management (VRM) platform with automation functionalities. The idea is to gather relevant information without extensive manual assessments and data entry.

‍

{{cta_webinar4="/cta-modules"}}

‍

3. Sub-requirement 12.8.3: Conducting pre-engagement due diligence for TPSPs

Under sub-requirement 12.8.3, your organization is obligated to have an established process for engaging TPSPs with a particular focus on pre-engagement due diligence. Your TPSPs need to be verified through comprehensive evidence collection and reviews that highlight critical areas in their risk profile, such as:

‍

• Financial standing
• Cybersecurity posture
• Operational dependencies
• Legal and compliance posture

‍

Meeting this requirement shouldn't be a problem as most TPRM teams are used to conducting thorough pre-onboarding risk analysis for proactive risk identification and mitigation. Still, it would be beneficial if you tailored a risk assessment keeping PCI DSS provisions in mind.

‍

You can draw from standard security questionnaires to understand what to ask during TPSP reviews. If you use a risk assessment template, you may want to customize it to cover a particular TPSP’s operations and security practices and how they can impact the CDE.

‍

4. Sub-requirement 12.8.4: Conducting annual assessments of TPSPs

As per sub-requirement 12.8.4, your organization is obligated to monitor each TPSP’s PCI DSS compliance standing at least once a year. Considering that a TPSP’s compliance posture directly impacts yours, the goal is to ensure they provide the services in a compliant way and there is a trail of evidence to demonstrate compliance.

‍

The purpose of these annual assessments is to reduce the likelihood of undetected risks, which can trigger incidents that are costly and difficult to remediate. While an annual review will help you maintain your PCI compliance, if you want to get a better overview of risks in your CDE, you can also consider half-yearly or quarterly monitoring of all TPSPs.

‍

In practice, many organizations may simply prefer to collect an Attestation of Compliance (AOC) or Report on Compliance (ROC) from their TPSPs annually.

‍

5. Sub-requirement 12.8.5: Establishing accountability of TPSPs

Sub-requirement 12.8.5 aims to foster accountability and task clarity. It’s described as follows:

‍

“Information is maintained about which PCI DSS requirements are managed by each TPSP, which are managed by the entity, and any that are shared between the TPSP and the entity.”

‍

To put it simply, this requirement recommends the use of a responsibility matrix. It’s a table that lists all the standard’s requirements with dedicated columns for three levels of responsibility:

‍

1. Your organization’s
2. The TPSP’s
3. Shared

‍

Besides assigning responsibility for different requirements and tasks, you can also address how the responsibility will be fulfilled. This makes it easier to understand what each party should do to ensure PCI DSS compliance, and it helps identify the source of any complications more efficiently.

‍

Many organizations make their responsibility matrix publicly available to foster greater stakeholder trust through transparency. Customers and other relevant parties can access the matrix to understand how CHD is handled between the organization and TPSPs. You can see an example of how this is done on the Genesys Cloud website.

‍

Due to the complexity of TPSP relationships, clear communication is essential to meeting this sub-requirement. The best way forward is to establish an open communication channel with regular touchpoints to ensure both parties are on the same page about compliance requirements.

‍

{{cta_withimage5="/cta-modules"}}

Simplify PCI DSS compliance with Vanta

You’ve likely noticed that virtually all PCI DSS requirements we’ve discussed can be met more efficiently with a robust software solution—and Vanta can be the perfect tool for you here. It’s a trust management platform products designed to help you establish a strong compliance and security posture.

‍

Vanta automates PCI DSS compliance and supports readiness for several SAQs OOTB including SAQ A, A-EP, and D for Merchants, SAQ D for Service Providers, and ROCs setups for both Merchants and Service Providers.

‍

You can also leverage the Vendor Risk Management product to simplify compliance and TPRM processes through features like:

‍

• Centralized vendor inventory for TPSP management
• Real-time vendor dashboard with insightful metrics
• Risk auto-scoring based on predetermined or custom parameters
• Shadow IT discovery for a better overview of your tech stack
• Streamlined security reviews with AI-enabled data processing

‍

For an in-depth product walkthrough, watch our webinar or schedule a custom Vanta demo today.

‍

{{cta_simple17="/cta-modules"}}

‍