Is That Vendor a TPSP? A Decision Tree for 12.8 Scope

The decision you are facing

Every vendor in your payment stack raises the same question: does this provider fall under Requirement 12.8, and if so, how much evidence do you need from them? The PCI Security Standards Council's information supplement, Understanding PCI DSS Service Providers, includes a decision flow for determining whether a provider is a third-party service provider (TPSP). What it doesn't give you is a way to convert that answer into an operating model for your vendor program.

This guide does that. Classify first, then pick the management path the classification demands.

Key factors that affect your choice

Four questions drive the outcome. Answer them for each vendor before you choose a path.

1. Does the provider store, process, or transmit Cardholder Data on your behalf? If yes, you're almost certainly dealing with a TPSP.
2. Does the provider meet one or more PCI DSS requirements for you? Examples include managed logging, vulnerability scanning, or a hosted payment page.
3. Can the provider impact the security of your environment? This applies to services that operate within customer environments, such as managed network services, remote administration, hosting, or backup.
4. Who holds administrative control? For multi-tenant providers, administrative control is the deciding factor.

Run these in order. A "yes" to any of the first three puts the provider in TPSP territory. The fourth question shapes how you split responsibility once you're there.

Path A: The provider is a TPSP that meets requirements or impacts security

Choose this path when: the vendor handles Cardholder Data, performs a PCI DSS control for you, or has access that could affect your Cardholder Data Environment (CDE).

What drives it: Requirement 12.8 applies in full. You need to:

• Maintain a list of TPSPs (12.8.1)
• Hold a written agreement with each one (12.8.2)
• Perform and document due diligence before engagement (12.8.3)
• Monitor each TPSP's PCI DSS compliance status at least once every 12 months (12.8.4)
• Record which PCI DSS requirements the TPSP manages, which you manage, and which are shared (12.8.5)

On the other side, Requirement 12.9 obliges the TPSP to acknowledge its responsibility to you in writing and to support your requests for information. The two requirements are built to work together, so test the pairing: if your contract doesn't capture that written acknowledgment, your 12.8 agreement is incomplete.

Practical steps:

• Request the TPSP's Attestation of Compliance (AOC) and read the scope section, not just the pass/fail result. Confirm the services you actually consume are in the assessed scope.
• Build a responsibility matrix per vendor. Don't accept "the provider is compliant" as a substitute for requirement-level allocation.
• For services that impact security, expect evidence that the TPSP meets the requirements applicable to that service. Where an AOC doesn't cover it, ask for assessment evidence tied to your specific engagement.

Path B: The provider is not a TPSP, but you still need to decide what to do

Choose this path when: the decision flow concludes the vendor doesn't store, process, or transmit Cardholder Data, doesn't meet any requirement for you, and can't impact your environment's security. The guidance gives examples of services that generally don't impact security; use them as your calibration set.

What drives it: Requirement 12.8 obligations don't attach, but your reasoning does need to be defensible. Assessors and acquirers will want to see why the vendor was excluded.

Practical steps:

• Document the classification and the date you made it, with the decision-flow answers that led there.
• Revisit it when the service changes. A vendor added to a remote-access workflow or given a network connection has moved out of this path.
• Keep the vendor off your 12.8 list, but keep the classification record. An undocumented exclusion looks the same as an oversight.

Path C: Multi-tenant and nested providers

Choose this path when: your TPSP serves multiple customers on shared infrastructure, or relies on its own downstream TPSPs to deliver your service.

Multi-tenant: Ask who holds administrative control over the components in your scope. That determines whether you or the provider is responsible for the relevant controls. Confirm the AOC reflects the multi-tenant services you use, and document the boundary between provider-managed and customer-managed components in your 12.8.5 matrix.

Nested: When your TPSP depends on another TPSP, responsibility doesn't disappear into the chain. The guidance explains how responsibility flows through nested arrangements. Operationally, you should:

• Ask your TPSP to disclose which downstream providers touch your service
• Confirm the TPSP is applying its own 12.8 obligations to those providers
• Make sure your matrix identifies who ultimately owns each requirement, even when delivery is subcontracted

Don't let a nested provider become an unmapped gap. If you can't see who owns a requirement, it's functionally unowned.

Summary matrix

One caution: the information supplement doesn't replace or supersede any PCI SSC standard. If you're unsure how your acquirer or payment brand interprets a specific vendor's status, ask them directly before you finalize your list.