Companies that rely on third-party service providers to handle their customers’ credit card data can rest a little easier. That is, if those providers play by the rules.
Earlier this month, the Payment Card Industry Security Standards Council issued new guidance on how to ensure that payment card data entrusted to third parties is securely maintained.
PCI Data Security Standards (PCI DSS) 3.0 requires that companies continue to protect customers’ credit card data even after outsourcing it to a third-party service provider (TPSP). The new guidance defines a 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.”
Bob Russo, general manager of the PCI Data Security Standards Council, an open global forum that developed the PCI Security Standards, says the guidance comes at a time when companies increasingly are using third parties to outsource certain services, which can put payment card data at risk. “It’s imperative that organizations understand how to ensure the security controls of the third party they’re engaging with are sufficient to protect card data,” he says.
The “Third-Party Security Assurance Information Supplement” draws from the expertise of more than 160 retailers, banks, and TPSPs that make up the PCI Data Security Standards Council, which was founded in 2006 by five global payment brands—American Express, Discover Financial Services, JCB International, MasterCard, and Visa. The supplement “offers real-world guidance on how organizations can sync up their payment card security goals with those of their third-party vendors,” Russo says.
Specifically, the guidance provides practical recommendations on how to:
Conduct due diligence and a risk assessment when engaging TPSPs.
Implement a consistent process for engaging TPSPs, such as setting expectations, establishing a communications plan, and mapping third-party services and responsibilities to PCI DSS requirements;
Develop appropriate agreements, policies, and procedures with TPSPs; and
Implement a process for maintaining and managing third-party relationships through the lifetime of the engagement.
The first part of the guidance focuses on how to thoroughly vet third-party candidates through careful due diligence prior to establishing a relationship, which is an area many companies are in the process of tackling right now. “We are getting a lot of questions from clients nowadays asking, ‘What do I need to do from a due diligence perspective before I contract with a vendor?’” says Todd McClelland, a partner with law firm Alston & Bird and a member of its security incident management and response team.
“It’s imperative that organizations understand how to ensure the security controls of the third party they’re engaging with are sufficient to protect card data.”
Bob Russo, General Manager, PCI Data Security Standards Council
When first engaging a TPSP, the guidance recommends that companies first determine the scope of the TPSP’s involvement in regard to storing, processing, or transmitting cardholder data. “Defining the level of involvement of a TPSP is crucial to understanding the overall risk assumed by the entity related to PCI DSS compliance,” the guidance stated.
Examples of questions that may help with this process include:
What technology and system components are used by the TPSP for the services provided?
Does the TPSP use other third parties?
What other core processes or services are housed in TPSP facilities that may affect the services provided? What technology is used for those core processes or services?
How many facilities does the TPSP have where cardholder data will be located?
Although an increasing number of companies are using third parties to outsource their services, they are “not necessarily vetting them,” Rob Nathan, chief technology officer at CardConnect, says. The guidance helps companies ensure that their TPSPs are PCI DSS compliant, he says.
Karl Sigler, threat intelligence manager for Trustwave, stresses that cyber-attacks are always going to find the weakest link, which for many large companies, he says, are TPSPs. “Although companies’ internal security might be very strong, their third-party vendors might not be,” he says.
The guidance further reminds companies that security can never be outsourced. “One of the leading mistakes organizations make when entrusting their data to a third-party vendor is not applying the same level of rigor to information security in vendor networks as they do in their own,” Russo says. “PCI stresses that security is always a shared responsibility.”
Getting third-party vendors to assume certain obligations, however, can sometimes prove difficult, McClelland says. The PCI guidance helps in this respect by including high-level suggestions and discussion points for determining how responsibilities for PCI DSS requirements may be shared between a company and its TPSP.
“It helps enable companies to have these conversations in advance with their third-party service providers,” McClelland says. “Having a better understanding upfront of what the third parties respective roles are going to be from a security perspective helps avoid issues from arising later on.”
The following excerpt from the PCI Guidance on Customer Credit Card Rules explains the basics of the new standards.
As entities work toward the goal of achieving and maintaining ongoing PCI DSS compliance, they may choose to leverage third-party service providers (TPSPs) to achieve their objectives. Entities can use a TPSP to store, process, or transmit cardholder data on the entity’s behalf, or to manage components of the entity’s cardholder data environment (CDE), such as routers, firewalls, databases, physical security, and/or servers. These TPSPs can become an integral part of the entity’s cardholder data environment and impact an entity’s PCI DSS compliance, as well as the security of the cardholder data environment.
The use of a TPSP, however, does not relieve the entity of ultimate responsibility for its own PCI DSS compliance, or exempt the entity from accountability and obligation for ensuring that its cardholder data (CHD) and CDE are secure. Clear policies and procedures should therefore be established between the entity and its TPSP(s) for all applicable security requirements ,and proper measures should be developed to manage and report on the requirements.
A robust and properly implemented third-party assurance program assists an entity in ensuring that the data and systems it entrusts to TPSPs are maintained in a secure and compliant manner. Proper due diligence and risk analysis are critical components in the selection of any TPSP.
This guidance focuses primarily on the following:
Third-Party Service Provider Due Diligence: Thorough vetting of candidates through careful due diligence, prior to establishing a relationship, assists entities in reviewing and selecting TPSPs with skills and experience appropriate for the engagement.
Service Correlation to PCI DSS Requirements: Understanding how the services provided by TPSPs correspond to the applicable PCI DSS requirements assists the entity in determining the potential security impact of utilizing TPSPs on the entity’s cardholder data environment. This information can also be used to determine and understand which of the PCI DSS requirements will apply to and be satisfied by the TPSP, and which will apply to and be met by the entity.
Note: Ultimate responsibility for compliance resides with the entity, regardless of how specific responsibilities may be allocated between an entity and its TPSP(s).
Written Agreements and Policies and Procedures: Detailed written agreements promote consistency and mutual understanding between the organization and its TPSP(s) concerning their respective responsibilities and obligations with respect to PCI DSS compliance requirements.
Monitor Third-Party Service Provider Compliance Status: Knowing the TPSP’s PCI DSS compliance status helps to provide the organization engaging a TPSP with assurance and awareness about whether the TPSP complies with the applicable requirements for the services provided. If the TPSP offers a variety of services, this knowledge will assist the entity in determining which TPSP services will be in scope for the entity’s PCI DSS assessment.
Source: PCI Guidance.
Many companies falsely assume that, because a TPSP is itself PCI compliant, all its services are PCI compliant, not realizing that the vendor is really only taking responsibility for a portion of its payment security. “Being able to verify that your third-party vendors are providing at least a minimum amount of security is really important to make sure that customers are safe and your business is safe,” Sigler says.
Another important aspect of the guidance discusses how to establish and maintain a program to monitor the compliance status of the TPSP, and determine whether a change in status requires a change in the relationship. “Your job is not done as a company once you sign the contract with your vendor,” McClelland says.
As part of the company’s monitoring program, the guidance states, an on-boarding process for new TPSPs should be developed and maintained and fully documented. This includes providing any new TPSPs with information attained by the risk analysis, contract details, responsibility matrix, and more.
Beyond the PCI guidance, however, it’s important that senior leaders give their risk, compliance, or IT teams the visibility and authority they need to address cyber-risks effectively, Christopher Kronenthal, chief technology officer of FreedomPay, says. The guidance will mean nothing if those who are interpreting it are “not given the proper empowerment at their organizations,” he says.
The good news is that breaches like the one that happened at Target have helped bring the issue of cyber-risk to the board level, McClelland says. “We’ve heard from many CISOs that they are starting to get the attention and support that they need,” he says.
Compliance with the PCI Data Security Standards should only be a starting point. “Nobody should really be stopping there,” Sigler says. It’s really important to not just check the boxes, he says, but to take a step back and think about their technology systems and business processes as a whole.