Service Providers and PCI Compliance, Part 2 – Third-Party Risk Management

In the first blog post in this series, we discussed the need for organizations with infrastructure in the cloud, as well as those using cloud-based platforms and applications (collectively, IAAS, PAAS, and SAAS), to understand the division of labor for the sustainment of PCI controls. To recap: organizations are not absolved of responsibilities when moving to cloud-based services of any type, but instead, it is essential to determine which parties are responsible for which controls.

Here, we'll look more closely at the relationships between organizations that need to be PCI compliant and the service providers with which they have outsourced portions of their technology. We will primarily be looking at the third-party risk management (TPRM) life cycle as it applies specifically to PCI.

Up Front Due Diligence

Before an organization signs an agreement with a third-party service provider, that will be supporting credit card payments and related activities it should first conduct some due diligence to determine whether any specific third party can adequately perform the service and whether it can do so while being compliant to PCI-DSS.

We’ll skip the majority of mainstream service provider discovery, analysis, and decision making in processes such as RFPs, RFIs, and RFQs. However, within the process of discovering details about a service provider's operation, the organization must obtain artifacts that attest to the service provider's PCI compliance. Primarily, this will be an attestation of compliance (AOC), a formal document that the service provider will sign, and perhaps also a Qualified Security Assessor (QSA) company that may have performed an assessment. If the service provider has submitted its AOC to a card brand organization, then the service provider should also appear in one of the card brand’s list of qualified service providers (Visa's list is here.)

As a part of due diligence, the organization should also send a security and privacy questionnaire to each third party under consideration and request that they complete and return it. There are several good standard questionnaires out there; our favorite one is the Cloud Controls Matrix or the Consensus Assessments Initiative Questionnaire. The results of the completed questionnaires should be analyzed, and any risks identified. Do note that larger providers such as Microsoft Azure and Amazon AWS will, in most cases, not answer individual questionnaires, but instead will provide a canned list of responses to typical questions, as well as a completed Responsibility Matrix.

No service provider is going to be perfect. Instead, security and business leaders need to make an informed choice about which service provider to select, and to obtain assurances of performance related to security and privacy, discussed in the next section.

Contracts with Service Providers

In requirement 12.8.2¹, PCI-DSS requires any organization subject to PCI to contractually require any relevant service provider also to be PCI compliant. However, it doesn't stop there – it starts there. Additionally, the agreement with a service provider should also contain legal language on the following topics:

In addition to these topics, there will possibly be additional items that specifically address results from the questionnaire. For instance, if the service provider stated that it never expires its administrative passwords, then there might be a clause that obligates the service provider to change its business process to one that is acceptable by both parties by a specific date.

If the service provider undergoes an annual PCI-DSS report on compliance (ROC), then the organization should request a copy of the updated AOC annually. The agreement with the service provider should specifically obligate the service provider to provide this annually. If the service provider does not undergo an annual ROC but instead completed a self-assessment questionnaire (SAQ), there will still be an AOC that they should deliver each year.

The service provider may have other types of external audits, such as a SOC1, SOC2, or ISO 27001 certification. The organization should contractually require the service provider to continue to undertake those external audits and to provide the audit results to the organization when they are available. Further, the service provider should be conducting external penetration tests at least annually; the service provider should be required to continue those and make the reports available. Other means for the organization to derive comfort through external attestations should be identified and obtained. If there are none, the organization may lack objective knowledge of the effectiveness of the service provider's security program and its attempts to protect sensitive information. This lack of objective knowledge should signal to the organization that it may need to perform some aspects of these audits on its own.

¹PCI-DSS version 3.2.1, requirement 12.8.2 reads, “Maintain a written agreement that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess or otherwise store, process or transmit on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment.”

These audits are potentially a costly undertaking. However, just as an organization assesses itself to identify risks, so too should the organization attempt to do the same with its service providers, especially those that affect the security of the organization’s cardholder environment.

Be on the lookout for Part 3 of this series where we will explore existing third party relationships where legal agreements are already in place.