Category: PCI DSS Compliance

Third-Party Service Provider

Also known as: TPSP, Service Provider (in certain PCI contexts)

Simply put

A Third-Party Service Provider (TPSP) is an outside company that a merchant or other organization hires to help handle or protect payment card data, or to support card-processing activities. Because these vendors can touch or affect the security of cardholder data, their practices can influence the hiring organization's own compliance obligations. Not every vendor an organization uses is a TPSP that falls within payment security scope; that depends on the services provided and how they relate to card data.

Formal definition

Within PCI contexts, a TPSP is a third-party entity acting as a service provider that supports another party in card-processing activities or in securing cardholder data, and whose services may affect the security of the cardholder data environment (CDE) or the outcome of a PCI DSS assessment. In ACH contexts (per Nacha), the term denotes an entity that provides services related to ACH processing on behalf of another party and may or may not transmit entries directly; this is a distinct usage and should not be conflated with the PCI meaning. Scope determination is service-specific: an organization may engage many vendors, but only those whose services can impact cardholder data or its security are treated as in-scope TPSPs. The specific responsibilities, validation obligations, and division of PCI DSS requirements between a TPSP and its customer depend on the services rendered and should be confirmed against the current published PCI DSS standard and relevant PCI SSC guidance rather than assumed.

Why it matters

Most organizations that accept payment cards do not build and operate every part of their payment environment in-house. They engage outside companies for functions such as payment processing, hosting, data storage, or security services. When those vendors can touch cardholder data or otherwise affect the security of the cardholder data environment (CDE), their practices become directly relevant to the hiring organization's own PCI DSS obligations. In other words, outsourcing an activity does not automatically outsource responsibility for its security or for demonstrating compliance.

The practical significance is that a merchant's compliance posture can depend in part on service providers it does not directly control. If a TPSP's controls are weak or its scope responsibilities are unclear, the customer organization may carry compliance and risk exposure it did not intend. This is why the division of PCI DSS responsibilities between a TPSP and its customer needs to be documented and confirmed rather than assumed, and why not every vendor relationship is treated the same: scope is service-specific, and only vendors whose services can impact cardholder data or its security are in-scope TPSPs.

A further complication is terminology. The same acronym is used differently across industries. In PCI contexts, a TPSP is a service provider that supports card-processing activities or the securing of card data. In ACH contexts, Nacha uses TPSP to mean an entity that provides ACH processing services on behalf of another party, whether or not it transmits entries directly. These are distinct usages, and conflating them can lead to misapplied controls and obligations.

Who it's relevant to

Merchants and Merchant Risk Teams

Merchants that outsource payment functions need to identify which vendors are in-scope TPSPs and understand how compliance responsibilities are split. Outsourcing an activity does not remove the merchant's obligation to ensure the relevant controls are met, so risk teams should document responsibility allocation and confirm it against current PCI DSS guidance.

Compliance Officers and QSAs

Those preparing or assessing PCI DSS validation must determine which vendors can affect the CDE or the assessment outcome, and how requirements are divided between the assessed entity and its TPSPs. Because requirement wording and responsibility guidance vary by version, these determinations should be checked against the current published standard rather than assumed.

Service Providers and Payment Processors

Companies that provide card-processing support or help secure card data on behalf of others may themselves be TPSPs and should understand which PCI DSS obligations they carry versus those retained by their customers. Clear documentation of the shared and delegated responsibilities helps both parties avoid gaps.

Vendor Risk and Procurement Teams

Teams evaluating vendors should distinguish which relationships fall within payment security scope, since not every vendor is an in-scope TPSP. This scoping decision depends on the specific services provided and their relationship to cardholder data.

ACH and Payments Operations Staff

Practitioners working with ACH should be aware that Nacha uses TPSP to describe an entity providing ACH processing services on behalf of another party, which is distinct from the PCI usage. Using the correct definition for the relevant context avoids misapplied obligations.

Inside TPSP

Definition and Scope

A Third-Party Service Provider is a business entity that is not a payment card brand and that is directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity, or that can affect the security of that entity's cardholder data environment. This can include managed service providers, hosting providers, payment gateways, tokenization or P2PE solution operators, and similar vendors.

Impact on Cardholder Data Environment (CDE)

A TPSP may handle cardholder data such as PAN, cardholder name, expiration date, and service code, or may influence CDE security even without directly touching cardholder data (for example, by managing firewalls or infrastructure). Sensitive authentication data such as full track data, CAV2/CVC2/CVV2/CID, and PINs or PIN blocks must not be stored after authorization by any party, including a TPSP, even when encrypted.

Shared Responsibility and Documentation

Responsibility for PCI DSS requirements is typically divided between the customer entity and the TPSP. Clear documentation of which party is responsible for which controls helps both parties understand and validate their respective obligations. The specific requirements addressing service providers and responsibility documentation differ in numbering and wording across PCI DSS versions, so confirm against the current published standard.

Validation Options

A TPSP may demonstrate PCI DSS compliance either by undergoing its own assessment and providing evidence to its customers, or by having its services reviewed as part of each customer's assessment. The chosen approach affects how a customer validates the portion of scope covered by the provider.

Relationship to Other PCI Standards

A TPSP's services may also fall under separate standards depending on what it provides, such as PCI P2PE for point-to-point encryption solutions, PCI PIN for PIN handling, or the PCI Software Security Framework for software. These are distinct from PCI DSS, and a term or control may belong to a different standard than the one governing the customer relationship.

Common questions

Answers to the questions practitioners most commonly ask about TPSP.

If we use a PCI DSS compliant service provider, does that make our own environment compliant automatically?

No. Using a compliant TPSP does not by itself make your environment compliant. A TPSP's validated compliance covers only the services and responsibilities within that provider's own defined scope. Your organization remains responsible for validating the controls under your control and for the portions of any requirement that fall to you. Confirm exactly which responsibilities the TPSP assumes versus which remain yours, rather than assuming their status transfers to you.

Does outsourcing our payment processing to a TPSP take us completely out of PCI DSS scope?

Not necessarily. Outsourcing may reduce your scope, but the effect depends on how the service is implemented and validated, not on the label of outsourcing alone. Depending on how you interact with the TPSP, how payment pages are served, and how cardholder data flows, some scope may remain with you. Assess your actual data flows and the specific integration method to determine what remains in scope, and confirm this against the current published standard.

How should responsibilities be documented between us and a TPSP?

Responsibilities are commonly documented through a responsibility matrix that maps each applicable requirement, or portion of a requirement, to the party accountable for it, and through written agreements that address the TPSP's handling of cardholder data. The intent is to leave no requirement ambiguous. Confirm the specific documentation expectations against the current published standard, as wording and structure can differ between versions.

What should we obtain from a TPSP to support our own assessment?

Organizations typically request evidence of the TPSP's PCI DSS validation status, a clear statement of which services and requirements that validation covers, and a responsibility matrix clarifying shared and separate duties. You may also request supporting attestation documentation. The goal is to verify that the services you rely on are actually covered by the provider's validation, rather than assuming coverage from a general claim of compliance.

How do we handle a TPSP that itself relies on additional subservice providers?

A TPSP may in turn depend on its own downstream service providers, sometimes described as nested or subservice providers. In such cases, clarify how the primary TPSP's validation accounts for those downstream services and which responsibilities are passed further down the chain. Ensure that responsibility mapping accounts for every party that handles or can affect the security of cardholder data, so that no portion of the chain is left unassessed.

How often should we review a TPSP's compliance status and responsibility assignments?

Monitoring a TPSP's status is intended to be an ongoing activity rather than a one-time check, because validation status, service scope, and responsibility assignments can change over time. Establish a process to periodically confirm current validation, review the responsibility matrix for accuracy, and reassess when services change. Confirm any specific monitoring frequency or documentation expectations against the current published standard.

Common misconceptions

Outsourcing to a PCI DSS compliant TPSP transfers all compliance responsibility, so the customer no longer has PCI DSS obligations.

Engaging a compliant TPSP does not eliminate the customer's own responsibilities. Compliance is typically shared, and the customer generally remains accountable for the controls it retains and for managing and monitoring the provider relationship. Documenting which party handles which requirement helps clarify these boundaries.

A TPSP is only in scope if it directly stores, processes, or transmits cardholder data.

A provider can also be a TPSP if it can affect the security of the customer's cardholder data environment, even without directly touching cardholder data. Examples can include managing security controls or supporting infrastructure that influences CDE security.

A TPSP's PCI DSS compliance covers every standard relevant to its services.

PCI DSS is separate from other PCI standards. Depending on what the provider offers, its services may also be governed by standards such as PCI P2PE, PCI PIN, or the PCI Software Security Framework. Confirm which standard applies to a given service rather than assuming PCI DSS covers everything.

Best practices

Maintain an inventory of all TPSPs, recording the services each provides and how each can process, store, or transmit cardholder data or otherwise affect the security of your cardholder data environment.

Document a clear allocation of responsibilities between your organization and each TPSP, identifying which party is responsible for which PCI DSS requirements, and confirm the requirement references against the current published version of the standard.

Obtain and review evidence of each TPSP's PCI DSS validation status, and determine for each provider whether its services are covered by its own assessment or must be reviewed within your assessment.

Verify that no TPSP stores sensitive authentication data such as full track data, CAV2/CVC2/CVV2/CID, or PINs and PIN blocks after authorization, even in encrypted form.

Confirm whether a TPSP's services fall under additional PCI standards such as PCI P2PE, PCI PIN, or the PCI Software Security Framework, and validate accordingly rather than relying on PCI DSS compliance alone.

Monitor TPSP compliance on an ongoing basis through periodic review of validation evidence and contractual security commitments, since a provider's status and the applicable network and standard requirements can change over time.