PCI DSS 12.8.1: A list of all third-party service providers (TPSPs) with which account data is shared

PCI DSS v4.0.1 control 12.8.1: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 12.8.

Requirement 12: Support Information Security with Organizational Policies and Programs › Section 12.8

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.

Summary

Keep a list of every third party that touches account data or could affect its security, saying what each one does for you.

What the assessor will examine

These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.

Procedure
12.8.1.a Examine policies and procedures to verify that processes are defined to maintain a list of TPSPs, including a description for each of the services provided, for all TPSPs with whom account data is shared or that could affect the security of account data.
12.8.1.b Examine documentation to verify that a list of all TPSPs is maintained that includes a description of the services provided.

The list the rest of section 12.8 is measured against: 12.8.2 wants an agreement per entry, 12.8.4 wants their compliance monitored, 12.8.5 wants a responsibility matrix. An incomplete list makes all three look complete, which is why this is the one to get right first. Note the scope: not only providers who touch account data, but any that "could affect the security of account data": which is what pulls in hosting, DNS, CDNs, tag managers and support tooling. 12.8.1.a examines the policy, 12.8.1.b examines the list itself.

What to prepare

  • The list, with a description of the service each provider performs.
  • The process that adds a provider to it, ideally at procurement rather than afterwards.
  • Evidence it is reviewed, so an ex-provider does not sit on it and a new one is not missing.

How to implement it

1. Build it from spend and DNS, not from memory. Accounts payable finds the providers nobody in IT engaged, and your DNS records find the ones pointed at your payment pages. Both surface entries an interview will not.

2. Include the ones that never see a card number. A CDN serving your payment page, a tag manager able to inject into it, and a hosting provider all affect the security of account data without processing it, and each is a named category of the requirement.

3. Describe the service, not the vendor. "Analytics" tells an assessor nothing; "loads a script on the checkout page" tells them why it is on the list and what to look at next.

4. Make procurement the gate. A list maintained by periodic sweep is always behind; a list maintained at contract signature is current by construction.

Where this commonly fails

  • A list of payment providers only, when the requirement is broader.
  • Subcontractors of your providers unconsidered, though they can be in scope.
  • Descriptions absent, which the requirement names explicitly.
  • The list built once for the last assessment and not since, so it fails alongside 12.8.2 and 12.8.4 together.

Others in section 12.8:

Control What it requires
12.8.2 Written agreements with TPSPs are maintained…
12.8.3 An established process is implemented for engaging TPSPs…
12.8.4 A program is implemented to monitor TPSPs’ PCI DSS compliance status at least once every 12…
12.8.5 Information is maintained about which PCI DSS requirements are managed by each TPSP…

12.7.1 · All controls · 12.8.2

Source

The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.

The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.