Category: Payment Ecosystem

Service Provider

Also known as: SP, Third-Party Service Provider, TPSP

Simply put

In payment security, a service provider is a business that handles cardholder data on behalf of another company, or that could otherwise affect the security of that data, without itself being one of the payment card brands. Examples include companies that store, process, or transmit card data for merchants, as well as vendors whose services touch the systems that handle such data. A general service provider in other contexts simply means any person or organization that supplies services to another party under a contract, but the payment-industry meaning is narrower and more specific.

Formal definition

Under PCI DSS, a Service Provider is a business entity (not a payment brand) that is directly involved in storing, processing, or transmitting cardholder data on behalf of another entity, or that can otherwise affect the security of cardholder data. This includes entities providing services that control or could impact the security of cardholder data, such as managed hosting, tokenization, or transaction processing. Notably, exclusions apply: for example, a telecommunications company that provides only the public network link (and does not access the cardholder data traversing it) is not, for that service alone, considered a service provider. This term is distinct from the broader, general usage in which a service provider is any individual or entity supplying services under a service agreement; the PCI DSS definition is limited to business entities and tied to cardholder data handling or its security. Service providers typically carry PCI DSS validation obligations and may be required to demonstrate compliance (for example, via an Attestation of Compliance). Practitioners should confirm the exact definitional wording, scope, and any associated validation requirements against the current published PCI DSS glossary and standard, as terminology and requirements differ between versions.

Why it matters

The service provider designation matters because responsibility for cardholder data does not end at a merchant's own perimeter. When a business entity stores, processes, or transmits cardholder data on another company's behalf, or can otherwise affect the security of that data, weaknesses in that entity's environment can expose data belonging to many downstream merchants at once. Getting the classification right determines who carries which PCI DSS validation obligations and where controls must be demonstrated, rather than assumed.

The precision of the definition also affects scope decisions. Because a service provider under PCI DSS must be a business entity (not one of the payment card brands) that is directly involved in handling cardholder data or able to affect its security, the label cannot be applied casually. Exclusions are equally consequential: a telecommunications company that provides only the public network link and does not access the cardholder data traversing it is not, for that service alone, treated as a service provider. Misclassifying such a relationship in either direction can lead to gaps in coverage or to validation effort spent where it is not required.

Because definitional wording, scope, and associated validation requirements differ between PCI DSS versions, practitioners should confirm classifications against the current published PCI DSS glossary and standard rather than relying on a prior version's language. Exact obligations depend on the service delivered and how it touches cardholder data, so classification is a fact-specific exercise.

Who it's relevant to

Compliance officers

Responsible for determining whether a vendor meets the PCI DSS definition of a service provider—a business entity, not a payment brand, that handles cardholder data or can affect its security—and for tracking the resulting validation obligations, such as obtaining and reviewing an Attestation of Compliance. They should confirm wording and requirements against the current published standard, since these differ between versions.

Merchant risk and vendor management teams

Rely on accurate classification to decide which vendors introduce cardholder data risk and must demonstrate compliance, versus those excluded from the definition for a given service (for example, a telco providing only network transport without accessing the data). This informs contractual security requirements and ongoing oversight.

Payment processors and managed hosting or tokenization vendors

Entities that store, process, or transmit cardholder data on behalf of others—or whose services could impact its security—typically fall within the PCI DSS service provider definition and carry their own validation obligations. They need to understand which of their services bring them into scope and how to evidence compliance to the merchants they serve.

Acquirers

Have an interest in confirming that the merchants and service providers in their portfolios are correctly classified and validated, since a service provider's environment can affect cardholder data across many downstream merchants. Classification and validation expectations should be checked against the current PCI DSS standard.

Inside SP

Business entity requirement

Under PCI DSS, a service provider is a business entity, not an individual and not a payment brand. The definition is scoped to organizations rather than persons, and payment brands themselves are expressly outside this definition.

Direct involvement in cardholder data

A service provider is directly involved in storing, processing, or transmitting cardholder data on behalf of another entity. Cardholder data here means PAN and associated elements such as cardholder name, expiration date, and service code; sensitive authentication data (full track data, CAV2/CVC2/CVV2/CID, PINs and PIN blocks) must not be stored after authorization even when encrypted.

Ability to affect security of cardholder data

The definition also covers entities that can affect the security of cardholder data even if they do not directly store, process, or transmit it. This captures providers whose services touch the cardholder data environment or its controls.

Exclusions from the definition

A provider that supplies only a discrete service is not automatically a service provider for unrelated services. For example, a telecommunications company that provides only public network transport (a link that carries data) is not considered a service provider for that service, because it is not involved in storing, processing, or transmitting cardholder data and does not affect its security in that role.

PCI validation responsibilities

Service providers typically have their own PCI DSS validation obligations, which may result in an Attestation of Compliance (AOC) and, depending on the entity and its acquirer or card brand program, a Report on Compliance. Specific validation levels, thresholds, and reporting requirements are set by card brand and acquirer programs, which vary by region and change over time; confirm against the current program requirements.

Shared responsibility with clients

Because a service provider performs functions on behalf of merchants or other entities, the allocation of PCI DSS responsibilities between the provider and its clients must be defined. Requirement wording and numbering for third-party and service provider management differ between PCI DSS versions; confirm the applicable requirement against the current published standard.

Common questions

Answers to the questions practitioners most commonly ask about SP.

Can an individual person be a service provider under PCI DSS?

No. The PCI DSS definition of a service provider is limited to a business entity, not an individual. The entity must be one that is directly involved in the storage, processing, or transmission of cardholder data on behalf of another entity, or that could otherwise affect the security of cardholder data. A single person acting outside of a business entity does not meet this definition, though individuals may of course work for a service provider.

Is a telecommunications company that only provides network connectivity considered a service provider?

Not for that service alone. A telecommunications provider that supplies only public network access, such as a common carrier providing communication links, is not treated as a service provider for that service under the PCI DSS definition. The distinction turns on whether the entity stores, processes, or transmits cardholder data, or can affect the security of that data, rather than merely carrying general public traffic. The same company could still be a service provider for a different, in-scope service it offers.

How do we determine whether a vendor should be treated as a service provider for our environment?

Assess whether the vendor is a business entity that stores, processes, or transmits cardholder data on your behalf, or that could affect the security of your cardholder data even if it does not directly handle it. Managed service or hosting providers, for example, can fall in scope where they could affect security. Document the assessment and confirm the determination against the definition in the current published PCI DSS standard, since wording can differ between versions.

What PCI DSS validation documentation should we expect from a service provider?

Expect evidence that the service provider validates its own PCI DSS compliance for the services it delivers, which is commonly conveyed through an Attestation of Compliance (AOC) and supporting reporting. Confirm that the scope of that documentation actually covers the specific services you use, since an AOC may cover only certain services or locations. Validation applicability and thresholds depend on the current standard and on your acquirer or card brand program requirements.

How should responsibilities be divided between our organization and a service provider?

Clearly define, in writing, which PCI DSS controls each party is responsible for, which are shared, and which the service provider manages entirely. A responsibility matrix helps prevent gaps where each side assumes the other owns a control. Confirm the split aligns with the service provider's validation documentation and with the specific services in scope, and revisit it when services change.

Does using a compliant service provider make our own environment compliant?

No. A service provider's validation covers only the services and controls within that provider's own defined scope. Your organization remains responsible for the controls that apply to your environment and for confirming that responsibilities are correctly allocated and evidenced. Using a compliant provider may reduce your control burden for the outsourced portion, but it does not by itself establish your own compliance.

Common misconceptions

An individual contractor who handles payment data can be a PCI DSS service provider.

The PCI DSS definition is limited to a business entity. It does not extend to individuals, and it does not include payment brands themselves.

Any vendor a merchant uses is automatically a service provider for PCI purposes.

The status depends on whether the entity stores, processes, or transmits cardholder data, or can affect its security. A provider supplying only public network transport, for instance, is not a service provider for that service. Scope is determined by the actual function performed, not by the vendor relationship alone.

A service provider's own PCI DSS validation covers its clients' compliance too.

A service provider's validation and AOC document its own responsibilities. Clients remain accountable for their portion of the environment, and responsibilities must be allocated explicitly. The provider's compliance does not, by itself, make a client compliant.

Best practices

Determine service provider status by evaluating the specific function performed—whether the entity stores, processes, or transmits cardholder data or can affect its security—rather than relying on the vendor label.

Confirm and retain each service provider's current Attestation of Compliance and document which PCI DSS responsibilities the provider covers versus which remain with your organization.

Maintain a written allocation of responsibilities between your organization and each service provider, and revisit it against the requirement wording in the current published PCI DSS version, since numbering and text differ between versions.

Ensure providers handling authorization flows do not retain sensitive authentication data (full track data, CAV2/CVC2/CVV2/CID, PINs or PIN blocks) after authorization, even in encrypted form.

Exclude from service provider treatment those vendors that only provide public network transport and neither handle cardholder data nor affect its security in that role, and document the basis for that exclusion.

Reassess service provider status and validation evidence on a defined cadence and whenever the provider's services, scope, or your card brand and acquirer program requirements change.