Category: PCI DSS Compliance

Multi-Tenant Service Provider

Also known as: Multi-Tenant Provider, Shared Hosting Provider

Simply put

A multi-tenant service provider is a company that uses one shared system or platform to serve many different customers at the same time, with each customer kept logically separate as a 'tenant.' Because multiple businesses rely on the same underlying infrastructure, the provider takes on added responsibility to keep each customer's data and environment isolated from the others. In the payment security world, these providers face specific expectations designed to address the risks of sharing infrastructure across many clients.

Formal definition

A multi-tenant service provider operates a shared infrastructure or single instance of an application in which multiple customers (tenants) operate independently within logically isolated environments. Under PCI DSS, multi-tenant service providers are addressed by a dedicated appendix (Appendix A1), which sets out additional requirements intended to help ensure separation and appropriate isolation between tenant environments and to protect each customer's hosted data. Practitioners should note that the specific controls, requirement numbering, and wording differ between PCI DSS versions and should be confirmed against the current published standard; the applicability and scope of these requirements depend on the provider's architecture and validated implementation, not on the multi-tenant label alone.

Why it matters

Multi-tenant service providers concentrate risk: because many independent customers rely on the same underlying infrastructure or a single application instance, a weakness in tenant isolation can potentially affect multiple businesses at once rather than a single environment. This shared model is why PCI DSS addresses these providers through a dedicated appendix (Appendix A1), which sets out additional expectations intended to help ensure appropriate separation between tenant environments and to protect each customer's hosted data.

The compliance implications extend beyond the provider itself. A merchant or other customer that hosts its cardholder data environment with a multi-tenant provider inherits dependencies on that provider's controls, and responsibility for specific requirements is typically divided between the provider and its customers. Misunderstandings about who is accountable for which control can leave gaps, so the boundaries of that shared responsibility need to be documented and validated rather than assumed.

Practitioners should note that the specific controls, requirement numbering, and wording associated with multi-tenant service providers differ between PCI DSS versions and should be confirmed against the current published standard. The applicability and scope of these requirements depend on the provider's actual architecture and validated implementation, not on the multi-tenant label alone; being described as multi-tenant does not by itself establish whether a given control applies or how it must be met.

Who it's relevant to

Service providers operating shared platforms

Hosting companies, SaaS payment platforms, and managed service providers that serve multiple customers from shared infrastructure are the primary parties addressed by the PCI DSS multi-tenant service provider appendix. They carry added responsibility for maintaining logical isolation between tenants and for protecting each customer's hosted data, and should confirm the applicable controls against the current published standard for their architecture.

Merchants and customers hosting with multi-tenant providers

Businesses that place their cardholder data environment on a shared platform inherit dependencies on the provider's isolation and protection controls. They should understand how responsibility for specific requirements is divided between themselves and the provider, and obtain documentation clarifying which controls the provider validates versus which remain the customer's obligation.

Compliance officers and QSAs

Those assessing or overseeing PCI DSS compliance need to determine whether the multi-tenant appendix requirements apply based on the provider's actual architecture and validated implementation. Because requirement numbering and wording differ between PCI DSS versions, assessors should work from the current published standard rather than assuming a fixed requirement reference.

Security and infrastructure engineers

Engineers who design and operate shared platforms are responsible for the tenant isolation mechanisms at the heart of the multi-tenant model. Their decisions about how a single instance and its shared resources segregate tenants directly affect whether the isolation and data protection expectations can be met and demonstrated.

Inside Multi-Tenant Service Provider

Shared Environment and Logical Segmentation

A multi-tenant service provider hosts multiple customers (tenants) on shared infrastructure, relying on logical controls to isolate each tenant's data and processes. The effectiveness of this separation depends on how it is implemented and validated, not on the mere claim that segmentation exists.

Shared Responsibility for Controls

Responsibility for PCI DSS controls is divided between the provider and its customers. Clear documentation of which controls the provider manages, which the customer manages, and which are shared is needed so no control is assumed to be covered by the other party.

Scope of Stored, Processed, or Transmitted Data

The provider's environment may handle cardholder data (such as PAN, cardholder name, expiration date, service code) on behalf of tenants. Sensitive authentication data (full track data, CAV2/CVC2/CVV2/CID, PINs and PIN blocks) must not be stored after authorization even when encrypted, and this applies to shared environments as well.

Validation and Attestation Artifacts

Multi-tenant providers typically provide evidence of their own PCI DSS validation and materials that help customers understand coverage. Requirement numbering and wording differ between PCI DSS versions, so both parties should confirm applicable requirements against the current published standard.

Tenant Isolation Mechanisms

Techniques may include separate credentials, access controls, network or compute isolation, and per-tenant logging. Their contribution to reducing scope or risk depends on correct implementation and testing rather than on the label applied to them.

Common questions

Answers to the questions practitioners most commonly ask about Multi-Tenant Service Provider.

Does using a PCI DSS compliant multi-tenant service provider make my environment automatically compliant?

No. A service provider's compliance covers only the services and components the provider is responsible for, as defined in a responsibility matrix. As a customer, you remain responsible for the controls that fall to you, and you must validate your own environment against the applicable PCI DSS requirements. The provider's Attestation of Compliance does not transfer compliance to your organization; it is evidence you use to support the portions of scope the provider manages. Confirm the exact division of responsibilities in writing and against the current published standard.

Because tenants share the same underlying infrastructure, does that mean every tenant can potentially see other tenants' data?

Not if the environment is properly segmented and access is controlled. In a multi-tenant model, logical separation between tenants is intended to isolate each customer's data and administrative access so that one tenant cannot reach another tenant's cardholder data or resources. The effectiveness of that isolation depends on implementation and validation, not on the multi-tenant label alone. Providers are generally expected to demonstrate the separation controls and to make evidence of that separation available to customers. Shared infrastructure does not inherently mean shared visibility, but weak or misconfigured segmentation can undermine the intended isolation.

How should responsibilities be documented between a multi-tenant service provider and its customers?

Use a written responsibility matrix that maps each applicable PCI DSS requirement to the party accountable for it, distinguishing controls owned solely by the provider, solely by the customer, or shared between them. For shared items, describe how the responsibility is split. Confirm the matrix reflects the services actually purchased, keep it current as services change, and verify requirement mappings against the current published version of the standard, since requirement numbering and wording differ between versions.

What evidence should a customer request from a multi-tenant service provider to support its own assessment?

Request the provider's current Attestation of Compliance, confirmation of which services and components were in scope for that assessment, and the responsibility matrix defining who handles which controls. You may also ask for evidence supporting the segmentation or logical separation between tenants and for documentation of any controls you rely on. Confirm that the evidence covers the specific services you consume, because a provider's assessment may not include every service it offers.

How can a multi-tenant service provider demonstrate separation between tenants?

A provider is generally expected to show that logical separation controls restrict each tenant's access to only its own data and resources, and to make relevant evidence available to customers. This can include documentation and testing of access controls, network or logical segmentation, and administrative separation between tenant environments. Because effectiveness depends on implementation and validation, the separation should be verified through testing rather than assumed from the architecture description. Confirm the specific validation expectations against the current published standard.

What should a customer do when a control is marked as shared in the responsibility matrix?

Treat shared controls as requiring explicit coordination. Clarify precisely which portion the provider performs and which portion you must perform, document that split, and ensure your own procedures cover your part. Validate your side during your assessment and rely on the provider's evidence for the provider's side. Do not assume a shared control is fully handled by either party; gaps in shared responsibilities are a common source of unaddressed requirements. Reconfirm the division whenever services or the standard's version change.

Common misconceptions

Using a PCI DSS validated multi-tenant provider automatically makes the customer compliant.

A provider's validation covers only the controls the provider is responsible for. The customer remains responsible for the portions of the environment and processes under its control, and shared responsibilities must be explicitly documented and confirmed against the current standard.

Logical segmentation in a shared environment guarantees that one tenant cannot affect another.

Segmentation is intended to reduce the risk of cross-tenant exposure, but its effectiveness depends on implementation and validation. It should be tested rather than assumed, and it does not by itself eliminate all risk.

Because data is encrypted in a shared environment, any data type may be retained.

Some cardholder data may be stored under defined controls, but sensitive authentication data must not be stored after authorization even when encrypted. Encryption does not permit retention of prohibited data types.

Best practices

Document a clear shared responsibility matrix that identifies which PCI DSS controls the provider manages, which the customer manages, and which are shared, and review it against the current published standard.

Confirm that sensitive authentication data is not retained after authorization anywhere in the shared environment, and verify that any stored cardholder data is protected under defined controls.

Test and validate tenant isolation and segmentation rather than assuming it works, and re-test after significant changes to the environment.

Request and review the provider's validation artifacts and coverage documentation, confirming the version and scope they apply to rather than assuming full coverage.

Implement per-tenant access controls, credentials, and logging so that activity can be attributed and monitored on a tenant-by-tenant basis.

Establish ongoing communication with the provider about control changes, version updates, and responsibility boundaries so gaps are identified before they become exposures.