Today, almost every organization is engaged with a third-party vendor at some level when offering products or services. Take, for instance, an e-commerce business that may not be able to function properly unless multiple third-party integrations are involved, such as CRMs, payment gateways, live chat APIs, or a shipping gateway, to name a few. Though third-party vendors are a necessary cog in the wheel for streamlining operations, they may pose a significant risk as potential gateways for cyber incidents. To put things into perspective, according to one study, 15% of system intrusion incidents involve adversaries exploiting partners.
Here, the Payment Card Industry Data Security Standard (PCI DSS) comes into play as a standard aimed at regulating credit card entities or merchants. The standard provides a set of frameworks and security practices that credit card entities must comply with to ensure secure transactions. As part of PCI DSS, third-party vendors that store, process, and transmit the data of cardholders on behalf of the entities should equally uphold the security standards.
As an organization that deals with cardholder data (CHD), it is imperative to understand PCI DSS vendor requirements when collaborating with third-party service providers. Read on to learn more about PCI DSS and the applicable requirements for third-party services.
PCI DSS for Third-Party Vendors
The Payment Card Industry Security Standards Council (PCI SSC) discussed the role and shared responsibilities of third-party vendors in its information supplement titled Third-Party Security Assurance. However, the latest PCI DSS version 4.0 provides more detailed and updated provisions regarding third-party responsibilities. To understand a third-party vendor, let’s first quickly discuss what an entity is. As per the definition of the PCI DSS, an entity is an organization that deals with cardholder data, and it is also liable for protecting the data and the Cardholder Data Environment (CDE). The entity may use the assistance of third-party providers for credit card data processing activities.
Whereas Third-Party Service Providers (TPSPs) are concerned, they are “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.”
The information supplement goes on to list some common examples of TPSPs. These include call center services, fraud verification services, and payment processors.
PCI DSS Third-Party Compliance Requirements 12.8
Essentially, PCI DSS compliance has six primary objectives, which include the following:
- Build and maintain a secure network and systems.
- Protect account data.
- Maintain a vulnerability management program.
- Implement strong access control measures.
- Regularly monitor and test networks.
- Maintain an information security policy.
All these objectives are further divided into 12 requirements that PCI DSS-regulated entities must fulfill to ensure compliance. PCI Requirement 12.8 focuses specifically on the management of third-party vendors, proposing policies and controls for services with whom entities share cardholder data or the services that may affect cardholders’ data security.
PCI DSS Sub-Requirement 12.8.1
A list of all third-party service providers (TPSPs) with which account data is shared or that could affect the security of account data is maintained, including a description for each of the services provided.
As the requirement suggests, merchants are required to keep an updated list of all the companies they deem as service providers, such as payment processors, anti-malware services, web hosting service providers, IT services, and with whom account data is shared. The list will also be used for other assessments and PCI 12.8 requirements.
The list provides a great way for merchants to evaluate and monitor all the service providers who may have access to account data or the CDE. The list may further allow the merchants to assess the security posture and determine the level of risks associated with the cardholder data.
PCI DSS Sub-Requirement 12.8.2
Written agreements are maintained with all TPSPs with which account data is shared, or that could affect the security of the CDE. Written agreements include acknowledgments from TPSPs that they are responsible for the security of account data the TPSPs possess or otherwise store, process, or transmit on behalf of the entity or to the extent that they could impact the security of the entity’s CDE.
The sub-requirement mainly focuses on the relationship between the merchant and the service provider. It gives a detailed description acknowledging that the service provider will be liable for the security of cardholder data shared by the merchant. The contract between the parties acts as evidence, displaying the commitment of the service provider to protecting the data. Here, it is further important to note that the written agreement isn’t the same as PCI DSS Attestation of Compliance (AOC).
The written agreement acknowledges that the TPSP will maintain proper security controls for data protection. The entity may also want to understand whether the TPSP relies on a secondary TPSP for data processing. Hence, the agreement should inform the entity about any “nested” relationship with a secondary TPSP.
PCI DSS Sub-Requirement 12.8.3
An established process is implemented for engaging TPSPs, including proper due diligence prior to engagement.
The sub-requirement involves a thorough risk analysis of the service provider. The analysis should be conducted before establishing a formal relationship with the service provider or closing an agreement. The process involves “proper due diligence.” It is no surprise that most organizations still don’t understand the meaning and context of due diligence. The conduct includes analyzing various components and aspects of the service provider to ensure that the service indeed does what it says. These critical assessments can be carried out by sharing a questionnaire with the service provider or via a site visit. These assessments are usually conducted annually for newer projects or agreements, but exceptions can be made for sensitive agreements.
PCI DSS Sub-Requirement 12.8.4
A program is implemented to monitor TPSPs’ PCI DSS compliance status at least once every 12 months.
The sub-requirement is aimed at the merchant as they are liable for monitoring the PCI DSS compliance status of all the third-party vendors they are engaged with. The sub-requirement is more like an assurance for the merchant, providing them the relief that the service provider is compliant with PCI DSS. The merchant should inquire about the compliance status of the service provider at least annually. It is the responsibility of the service provider to undergo its own assessment and obtain an Attestation of Compliance (AOC). The Standard also allows for a variance of this requirement:
“If the TPSP did not undergo a PCI DSS assessment, it may be able to provide other sufficient evidence to demonstrate that it has met the applicable requirements without undergoing a formal compliance validation.”
PCI DSS Sub-Requirement 12.8.5
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.
The concerned information can be maintained in a document, which is referred to as a “responsibility matrix” in the PCI DSS 4.0 provisions. The sub-requirement allows the merchants to learn about the compliance requirements managed by the entity itself and the service provider.
Final Thoughts
When the PCI DSS compliance requirements bind the merchant, they won’t have to wonder about the compliance of their service providers. It is imperative for merchants to have a streamlined process in place to identify and catalog all their service providers, assess their risks, and ensure their compliance status with PCI DSS. This will protect the business and, most importantly, the customers.
About the Author:
With a strong background in the SaaS and IaaS industry, Syed Sayem Mustufa has extensive experience in Marketing. Over the years, Sayem has served some of the top data intelligence and cybersecurity brands, including Securiti.ai. He loves nothing more than breaking down and simplifying highly complex product details into easy-to-understand benefits for end users.
Editor’s Note: The opinions expressed in this and other guest author articles are solely those of the contributor and do not necessarily reflect those of Tripwire.
Insider Insights for the PCI DSS 4.0 Transition
Gain valuable insights from cybersecurity experts on transitioning to PCI DSS 4.0. Tripwire's comprehensive guide provides strategic advice, making the compliance process more streamlined and efficient. Understand the challenges and solutions for meeting PCI DSS requirements with expert guidance.
