Saying that a third-party service provider is “PCI compliant” is not a conclusion; it is the starting point for further verification.
For many organisations, third-party assurance still amounts to obtaining an Attestation of Compliance (AOC), saving it in a repository and assuming that no further review is required. However PCI DSS requires more than evidence that a provider completed an assessment at some point.
You need to establish whether the provider is in scope, which services have been assessed, what responsibilities it has accepted, whether its validation remains current and whether the evidence actually supports the services your organisation consumes.
The PCI Security Standards Council has clarified how third-party service providers should be scoped, validated and documented during a PCI DSS assessment. The guidance highlights an important point: providers do not need to store, process or transmit account data to fall within scope. They may also be in scope because their services help meet PCI DSS requirements or could affect the security of the cardholder data environment.
This has significant implications for merchants, service providers and assessors.
For the purposes of a customer’s PCI DSS assessment, a third-party service provider relationship is relevant where the provider delivers services that:
The third point is where organisations frequently underestimate their scope.
A provider does not need to see a Primary Account Number, or PAN, to affect its security. A managed security service provider, cloud provider, identity provider, hosting company, application management provider or remote-support supplier may not handle payment data directly, but its access or services could still affectthe security of systems within scope.
This means the correct question is not simply:
Does this provider handle card data?
It is:
Could this provider’s systems, personnel, access or services affect the security of account data or help us meet a PCI DSS requirement?
When the answer is yes, the relevant services, access paths, system dependencies and provider-managed responsibilities must be considered in the customer’s PCI DSS scope and assessment.
PCI DSS compliance applies to a defined scope, service and period.
A provider may operate several products, platforms or service lines. Its Attestation of Compliance may cover one of them but not the service your organisation uses. The assessed scope may be limited to specified legal entities, services, environments, locations, regions or delivery models, as documented in the AOC and supporting assessment materials.
The statement “our provider is PCI compliant” tells you very little on its own.
You still need to determine:
Without that analysis, an AOC can create false confidence.
An organisation may possess a valid document while relying on a service that sits outside the provider’s assessed scope.
A third-party service provider generally has two routes for validating its PCI DSS responsibilities.
The provider can complete an annual PCI DSS assessment and supply customers with appropriate evidence, normally an AOC.
Depending on its validation requirements, the provider may complete:
This is usually the most straightforward route for customers because the provider has already identified its scope, assessed the applicable controls and documented the outcome.
However, the customer must still review the AOC carefully. Receiving the document does not remove the need to confirm that it covers the relevant service.
Where the provider has not completed its own annual assessment, it may participate in a customer’s PCI DSS assessment.
The provider must make sufficient evidence, personnel, systems and processes available for the customer’s assessor to perform the applicable PCI DSS testing procedures and reach a supported conclusion. The provider’s responsibilities are then evaluated as part of that customer’s Report on Compliance. This is not a simple declaration from the provider. It requires detailed evidence and assessor testing. It is also not an option available to every merchant.
A merchant cannot use its own SAQ to validate the internal PCI DSS compliance of an unvalidated service provider. The merchant’s SAQ covers the merchant’s eligible environment and the requirements applicable to that merchant.
The merchant should not be required to:
A provider serving an SAQ merchant is expected to validate its own compliance through an SAQ D for Service Providers or a ROC.
Therefore, when a provider without its own validation tells an SAQ merchant that it can simply be “covered by the customer’s assessment”, the merchant should challenge that position.
The route of incorporating the provider’s controls into the customer assessment applies to organisations completing a ROC and choosing to assess those provider responsibilities directly. It is not a universal alternative to service-provider validation.
An Attestation of Compliance is important evidence, but only when it is reviewed properly.
Checking the provider’s name and assessment completion date is not enough. Your due diligence should confirm that the AOC applies to the service, environment and relationship in question.
Check that the legal entity named on the AOC is the entity delivering your service.
Large groups may operate through several subsidiaries. A parent company’s assessment does not automatically cover every subsidiary or regional operation.
Review the description of the assessed services.
The provider may offer multiple cloud environments, hosting services, payment products or managed services. The AOC must cover the specific service you consume, not merely another service supplied by the same company.
PCI DSS validation is not permanent.
An AOC should not remain on file indefinitely without confirming whether the provider’s PCI DSS compliance status is still current and whether updated validation documentation is available.
Confirm which version of PCI DSS was used during the provider’s assessment.
This helps determine whether the provider’s validation is based on the applicable version of PCI DSS and is suitable for the customer’s assessment and reporting period.
The agreement and supporting documentation should make clear which PCI DSS requirements are:
An AOC does not transfer every responsibility to the provider. Customers remain accountable for understanding and operating their side of the control environment.
Every provider meeting the PCI DSS scoping criteria should be documented in Section 4.4 of the Report on Compliance.
This includes providers that:
Where relevant, the provider’s services, connections, access and dependencies should also be reflected in the ROC sections addressing scope, system components, network connections, segmentation, data flows and assessed locations.
The important point is consistency.
The providers listed in the ROC should align with:
A provider should not appear in one document but disappear from the others.
When a third-party provider is responsible for a PCI DSS requirement, the requirement may be reported as “In Place”.
But that conclusion requires supporting evidence.
The assessment documentation should identify:
“In Place” is not shorthand for “the supplier told us it was compliant”.
It is a documented assessment conclusion supported by contracts, validation evidence and testing.
Where those elements are absent, the finding may not be defensible.
PCI DSS Requirement 12.8 addresses how organisations manage third-party service providers that have access to account data or could affect its security.
It requires organisations to maintain oversight of the relationship rather than treating provider assurance as an annual document-gathering exercise.
Requirement 12.8.1 requires a list of relevant third-party service providers, including a description of the services each provider delivers.
That inventory should reflect the current cardholder data environment. It should be updated when services are introduced, changed or retired.
Requirement 12.8.2 requires written agreements with applicable providers.
These agreements should acknowledge the provider’s responsibility for protecting account data or for the PCI DSS requirements it manages on the customer’s behalf.
Vague contractual language can lead to uncertainty over who is responsible for particular controls.
Requirement 12.8.3 requires organisations to maintain a process for engaging service providers, including appropriate due diligence before the relationship begins.
PCI DSS considerations should therefore form part of procurement and onboarding, not be addressed only when the annual assessment starts.
Before signing a contract, organisations should understand:
The depth of due diligence should be proportionate to the service, access, data handled, technical dependencies and potential impact on the CDE.
Most third-party findings are not caused by organisations having no documentation at all.
They are caused by documentation that looks adequate until someone examines it closely.
An older AOC remains in the compliance repository, but nobody has checked whether the provider completed its latest assessment.
The document is valid, but it relates to another product, hosting model, location, region or legal entity.
The organisation’s third-party list no longer matches its current systems, integrations, payment flows or cloud services.
The customer assumes the provider manages a control, while the provider’s documentation states that the customer remains responsible.
Requirements are marked “In Place” based only on the provider’s reported status, without identifying the applicable service, responsibility allocation, validation evidence or testing supporting the conclusion.
The provider has no independent validation and expects the merchant to include its controls within an SAQ, despite the merchant not being responsible for assessing the provider’s environment.
These gaps often remain hidden until the formal assessment is underway. At that stage, resolving them can involve chasing suppliers, reviewing contracts, redefining scope and collecting evidence under considerable time pressure.
Effective third-party management requires a repeatable process that connects procurement, legal, information security, payments teams and compliance.
Start by building a complete inventory of providers that either handle account data or could affect its security. Map each provider to the service it supplies, the systems it can access and the relevant PCI DSS requirements.
For every in-scope provider, obtain current validation evidence and confirm that it covers the service you use. Document which controls the provider manages and which remain your responsibility.
That review should not happen once and then be forgotten. Provider services change. Contracts change. Platforms migrate. A provider may alter its assessed scope or replace one service with another.
A mature process therefore includes:
The objective is not merely to collect documents. It is to establish that the provider’s controls, responsibilities and validation support your own PCI DSS compliance.
Third-party service providers can significantly complicate PCI DSS scoping and assessment, particularly where responsibilities are shared across several suppliers, platforms and internal teams.
Integrity360’s Payments Compliance specialists can help organisations:
Integrity360 has delivered payment security assessment services since 2009 and supports organisations across PCI DSS, 3DS, P2PE, Secure Software Framework, Token Service Provider, PIN Security and Card Production and Provisioning requirements.
A provider’s PCI DSS status matters, but it cannot be accepted without context.
You need to know what was assessed, when it was assessed, which services were included and whether the provider’s responsibilities are clearly supported by contracts and evidence.
An AOC on file is useful.
An AOC that is current, relevant and applicable to the correct service can support a defensible PCI DSS assessment when it is considered together with the responsibility allocation, contractual commitments, customer-side controls and applicable testing evidence.
Speak to Integrity360 to review your third-party service provider scope, validate your evidence and prepare for your next PCI DSS assessment.