This one is a little personal for me.
Back in late 2012, I founded the PCI Security Standards Council Third Party Security Assurance Special Interest Group (SIG), and led that work through 2013 and into 2014.
The problem we were trying to address was already becoming one of the most difficult areas of PCI DSS:
When an organisation outsources part of its payment environment to a third party, who is actually responsible for what?
That work ultimately resulted in the Third-Party Security Assurance Information Supplement, first published by the PCI SSC in August 2014 and subsequently expanded in 2016. [pcisecurit…ndards.org], [pcisecurit…ndards.org]
More than a decade later, the problem certainly hasn’t gone away.
In November 2026, the PCI SSC published a new information supplement, Understanding PCI DSS Service Providers, providing updated guidance for merchants, service providers, assessors and acquirers dealing with Third-Party Service Providers (TPSPs). [blog.pcise…ndards.org]
Having spent a very long time working in this area, my reaction is mixed.
The guidance is useful. It clarifies several areas that needed clarification.
But it also demonstrates that, twelve years later, there is still a gaping chasm between what PCI DSS expects merchants to understand about their service providers and what ordinary businesses can realistically be expected to understand.
The technology has changed. The problem hasn’t.
Back in 2013, our SIG was considering questions such as:
- What service is the third party actually providing?
- Which PCI DSS requirements are performed by the provider?
- Which remain the customer’s responsibility?
- Which responsibilities are shared?
- What evidence should customers obtain?
- How should due diligence be performed?
- What happens where the provider itself relies upon another service provider?
- How should all of this be monitored?
Those themes featured heavily in the subsequent guidance, including due diligence, risk assessment, contractual expectations, evidence, responsibility matrices, nested TPSPs and ongoing monitoring.
Sound familiar?
The technology landscape has changed enormously since then.
Cloud computing and SaaS have become ubiquitous. Payment platforms are increasingly outsourced. Businesses rely upon complex ecosystems of hosting providers, payment gateways, managed service providers, security providers and numerous other suppliers.
But the fundamental questions remain remarkably similar:
What are they doing?
What are they responsible for?
What am I still responsible for?
And what evidence do I have that any of it is actually happening?
What the new guidance gets right
There is plenty in the new guidance that I like.
It provides a decision flow to help organisations determine whether a supplier should be considered a TPSP. It explains the relationship between PCI DSS Requirements 12.8 and 12.9. It considers nested providers and multi-tenant service providers. It also provides additional guidance around services that can “impact security”.
That final point is particularly important.
Organisations can become far too preoccupied with whether a supplier actually stores, processes or transmits cardholder data.
A provider doesn’t necessarily have to be storing millions of card numbers to represent a significant dependency.
Managed networks, remote administration, hosting and backup are examples given by the Council of services capable of impacting the security of a customer’s environment.
So this is useful guidance.
The problem is who is expected to understand and implement it.
Guidance for whom?
This is where I’m going to be slightly more critical.
The new guidance isn’t particularly beginner-friendly.
And, if I am being blunt, that is fairly typical of documentation produced by the PCI SSC.
There sometimes seems to be an assumption that the huge population of merchants and service providers around the world understands PCI DSS terminology, scoping, applicability and evidence to roughly the same degree as the people writing the guidance.
They don’t.
And we shouldn’t expect them to.
The PCI SSC itself recognises this to some extent. It publishes separate simplified payment-security resources explicitly intended to help small businesses understand payment security and the questions they should be asking their vendors.
TPSP guidance needs the same treatment.
Because third-party relationships aren’t an unusual edge case anymore.
They are the normal way businesses operate.
Even the PCI SSC’s own guidance acknowledges that merchants and service providers will often engage multiple service providers and that those providers may themselves engage further, or nested, providers.
Against that background, consider one of the expectations highlighted in the new guidance.
A customer is expected to obtain evidence from its TPSP that the provider meets the PCI DSS requirements applicable to its service.
Fine.
But let’s imagine you’re a small merchant.
What exactly does “evidence” mean?
An Attestation of Compliance?
A Report on Compliance?
A responsibility matrix?
A contract?
Some screenshots?
A statement from the TPSP?
Something produced by its QSA?
Or is “evidence” the salesperson who sold you the solution saying:
“Don’t worry. We’re PCI compliant. Just sign here.”
Obviously, that shouldn’t be enough.
But that’s precisely the point.
If the person reading the guidance needs to already understand the PCI DSS assessment ecosystem in order to understand what acceptable evidence looks like, then simply telling them to “obtain evidence” doesn’t solve the problem.
It tells them what they need to establish without adequately explaining how to establish it.
An AoC is the beginning of the question, not the answer
One of my frustrations during PCI DSS assessments is seeing an Attestation of Compliance treated almost like a certificate.
The thinking becomes:
TPSP has AoC = TPSP is PCI DSS compliant = problem solved.
It doesn’t work like that.
The questions I want answered are:
What services were actually assessed?
Are those the services my client is using?
Which PCI DSS requirements does the TPSP meet on the customer’s behalf?
Which remain the customer’s responsibility?
Which are shared?
And increasingly:
Which controls depend upon another provider further down the chain?
That’s where things can get interesting.
I follow the chain
I generally go one step further during a PCI DSS assessment.
If somebody sends me a TPSP’s AoC and that AoC identifies other TPSPs upon which its service depends, I will normally ask to see their AoCs too.
And I want to understand the responsibility matrices applying between the different parties.
Not simply:
Merchant → TPSP
but:
Merchant → TPSP → Nested TPSP → potentially another TPSP.
Why?
Because the result can be extremely telling.
The merchant believes that TPSP A is responsible for a particular PCI DSS control.
You inspect TPSP A’s documentation and discover that it relies upon TPSP B for that control.
So you examine TPSP B.
And sometimes you discover that TPSP B isn’t responsible for it either.
Perhaps their documentation allocates it elsewhere.
Perhaps the responsibility is shared.
Perhaps they have marked the requirement Not Applicable.
Suddenly you have uncovered something much more important than whether everyone has a current AoC.
Everybody thought somebody else was performing the control.
Nobody actually was.
That, to me, is the real TPSP problem.
Follow the responsibility, not the certificate
This is also where responsibility matrices become extremely important.
A merchant might have one obvious TPSP.
That TPSP might depend upon five other providers.
Those providers may themselves depend upon further providers.
The security architecture the merchant is actually relying upon can therefore look very different from the contractual relationship the merchant thinks it has.
The PCI SSC has recognised the danger of nested providers for years.
Its guidance says customers should understand service providers, including nested service providers, that have the ability to connect to or access their networks.
And nested TPSPs were already being addressed within the original guidance we produced more than a decade ago.
The modern payment ecosystem has only made the problem more important.
Yet we’ve still not made the practical answer simple enough.
This isn’t an academic supply-chain problem
Recent UK cyber incidents should have put to bed the idea that understanding dependencies is some obscure governance exercise.
The 2025 cyberattack on Marks & Spencer caused weeks of serious operational disruption and enormous financial consequences, while subsequent discussion highlighted the wider questions organisations need to be asking about suppliers, contractors and third-party access.
The Jaguar Land Rover incident provides a different illustration of dependency.
The Cyber Monitoring Centre estimated its UK economic impact at around £1.9 billion, affecting more than 5,000 UK organisations, largely because disruption spread economically through JLR’s extensive manufacturing supply chain.
Neither incident is presented here as a PCI DSS case study.
The lesson is broader.
Modern businesses are extraordinarily dependent upon other businesses.
Payment environments are certainly no exception.
A company can outsource its payment platform.
It can outsource hosting.
It can outsource network management.
It can outsource software support.
It can outsource its identity platform.
It can outsource security operations.
But there is one thing it cannot outsource:
Reality.
If a security control needs to exist, somebody somewhere actually has to perform it.
Writing “TPSP” in a responsibility matrix doesn’t magically make that happen.
So let’s make TPSP assurance simpler
If this new information supplement is primarily aimed at QSAs, experienced PCI practitioners and sophisticated Level 1 organisations, it is useful.
Those people will understand what “applicable requirements”, “evidence”, “nested TPSPs” and “responsibility allocation” mean.
But if we genuinely expect the wider merchant community to manage TPSP risk properly, I think we need to go further.
The practical advice could be considerably simpler.
1. Ask for the TPSP’s current AoC
Don’t simply ask whether the company is “PCI compliant”.
Get the document.
2. Check the service you’re buying is actually covered
The name of a familiar service provider on an AoC doesn’t automatically mean the particular service you’re buying is within the assessed scope.
3. Obtain the responsibility matrix
Understand requirement by requirement what the TPSP performs and what remains your responsibility.
Pay particular attention to anything marked Shared or Not Applicable.
4. Identify other providers the TPSP depends upon
If your provider relies upon other TPSPs to provide the service, don’t stop at the first AoC.
Follow the chain.
5. Ask for evidence covering those dependencies
Where another TPSP is relied upon to satisfy PCI DSS requirements, establish what evidence supports that assertion.
That may mean obtaining another AoC and another responsibility matrix.
6. Keep following the control
Ultimately, for every applicable PCI DSS requirement, you should be able to answer a very simple question:
Who actually does this?
Not who everybody thinks does it.
Not whose name appears in the contract.
Not who the salesperson said takes care of it.
Who actually performs the control, and what demonstrates that they do?
If you follow the chain and eventually discover that everyone thinks somebody else is responsible, you’ve found the problem.
Twelve years later, we still haven’t closed the gap
When I founded the PCI SSC Third Party Security Assurance SIG in late 2012 and led the initiative through 2013 and into 2014, the problem we were trying to solve was fundamentally one of trust, dependencies and responsibility.
Twelve years later, many things are better.
The terminology has improved.
PCI DSS itself is considerably more mature.
The documentation is more detailed.
Our understanding of complex service-provider relationships has moved forward.
But I’m not convinced we’ve solved the practical problem.
There remains a gaping chasm between what the PCI world expects a merchant to understand about its supply chain and what a normal business can realistically be expected to understand from an 18-page technical information supplement.
An experienced QSA can read an AoC, examine the responsibility matrix, identify dependencies, spot a dubious Not Applicable response and start following the chain.
Can we realistically expect the owner of a small retailer, restaurant, hotel or online shop to do the same?
I don’t think we can.
And telling that merchant to “obtain evidence” isn’t enough.
If we genuinely want millions of merchants to manage their TPSPs properly, we need to start writing guidance for the people who actually have to use it, not just those of us who already understand it.
After more than a decade, perhaps the next step isn’t another information supplement.
Perhaps it’s making this stuff genuinely simple.
About Tim Holman
Tim Holman is CEO and co-founder of 2-sec, a cyber security consultancy and PCI SSC Qualified Security Assessor Company. Tim is an active Qualified Security Assessor (QSA) and has worked in cyber security since 1995.
He founded the PCI SSC Third Party Security Assurance Special Interest Group in late 2012 and led its work through 2013 and into 2014, helping develop early industry guidance around third-party PCI DSS assurance and service-provider responsibilities.