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_withimage5="/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:
- 12.8.1: Maintains a list of all TPSPs
- 12.8.2: Maintaining written agreements for TPSPs
- 12.8.3: Conducting pre-engagement due diligence for TPSPs
- 12.8.4: Conducting annual assessments of TPSPs
- 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_simple17="/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:
- Your organization’s
- The TPSP’s
- 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"}}
Regulatory compliance and industry standards
A guide to meeting the third-party risk requirements of PCI DSS
Regulatory compliance and industry standards
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_withimage5="/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:
- 12.8.1: Maintains a list of all TPSPs
- 12.8.2: Maintaining written agreements for TPSPs
- 12.8.3: Conducting pre-engagement due diligence for TPSPs
- 12.8.4: Conducting annual assessments of TPSPs
- 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_simple17="/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:
- Your organization’s
- The TPSP’s
- 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"}}
Explore more TPRM articles
Introduction to TPRM
Vendor lifecycle management
Vendor risk assessment
Running a VRM program
Get started with TPRM
Start your TPRM journey with these related resources.
How to minimize third-party risk with vendor management
Get insights and best practices from security & compliance experts on how to manage third-party vendor risk in this free guide.
.svg)
Vanta in Action: Vendor Risk Management
Vendor security reviews can be manual and time-consuming, draining security teams of precious hours. Vanta’s Vendor Risk Management solution changes that, automating and streamlining security reviews so that you can spend less time on repetitive work and more time strengthening your security posture. Curious to see what it looks like?
10 important questions to add to your security questionnaire
We’ve identified 10 critical questions to include in your security questionnaire and why each answer is vital for informed decision-making.
