Skip to main content

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

October 01, 2019

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.21, 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:

  • Ownership of data
  • Responsibilities for data protection
  • Effective management-driven cybersecurity program
  • Penetration testing
  • PCI compliance
  • Right to audit
  • Notice of breach
  • Cyber insurance

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.

1PCI-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.

    Sean Smith

By: Sean Smith

See More

    Peter Gregory

By: Peter Gregory

Director, Information Security

See More

Related Blogs

September 04, 2014

Establishing A Zero-Trust Infrastructure

When looking at a security posture, the main concern is usually about blocking a potential attacker who sits outside our network from getting inside o...

See Details

May 10, 2017

PCI Compliance Every Day

The title of this post sounds daunting, does it not? However, achieving PCI compliance every day is not as daunting as you might think. With the relea...

See Details

October 29, 2018

Leveraging Risk Strategy to Move Beyond Check-Box PCI Compliance

Merchants often put compliance spending at the top of their list for budgeting purposes because the consequences of non-compliance can be expensive. F...

See Details

How Can We Help?

Let us know what you need, and we will have an Optiv professional contact you shortly.

Privacy Policy

Stay in the Know

For all the latest cybersecurity and Optiv news, subscribe to our blog and connect with us on Social.


Join our Email List

We take your privacy seriously and promise never to share your email with anyone.

Stay Connected

Find cybersecurity Events in your area.