PCI DSS third-party requirements are the rules in Requirement 12.8 of the Payment Card Industry Data Security Standard that make a merchant responsible for managing every outside provider that stores, processes or transmits cardholder data, or that could affect its security. Using a payment processor, a hosted checkout or a managed IT provider does not move that responsibility off your books. Under PCI DSS version 4.0.1, the standard’s current release, you must keep a list of those providers, hold written agreements in which they acknowledge their security duties, perform due diligence before engaging them, check their compliance status at least once a year, and document which PCI DSS requirements each provider handles and which you handle. Requirement 12.9 sets the matching duties on the provider side. This article explains what each part asks for, where small businesses usually fall short, and how to build the documentation in an afternoon.
Overview: Five Points on Managing PCI Service Providers
The PCI Security Standards Council calls these vendors third-party service providers, or TPSPs. Five points frame the rest of this article.
- Outsourcing reduces scope, not accountability. A hosted payment page can shrink the systems in scope, but you still must manage the provider that runs it.
- The provider list is broader than the processor. IT providers with remote access, hosting companies, call centers and software vendors that touch the payment flow can all count.
- Agreements must name security duties. A generic contract is not enough; the provider has to acknowledge responsibility for protecting the cardholder data it handles.
- Compliance is checked every year. You need current evidence, usually an Attestation of Compliance, for each provider.
- The responsibility matrix is the most common gap. Auditors and acquiring banks increasingly ask who owns each requirement, and many SMBs cannot answer in writing.
Why PCI DSS Third-Party Requirements Still Apply When You Outsource Payments
PCI DSS third-party requirements still apply when you outsource payments because your business remains the merchant of record, and your acquiring bank holds you accountable for card data security across your whole payment flow. A breach at a provider you never vetted becomes your problem with the card brands. Our PCI DSS 4.0 compliance guide covers the broader standard; this article focuses on the provider pieces.
Which providers count as a TPSP
A provider is in scope when it stores, processes or transmits cardholder data for you, or when it can affect the security of your cardholder data environment. That second clause pulls in more vendors than many owners expect. A managed IT provider with administrator access to a point-of-sale network counts. So does a web developer who can change the code on the page where your hosted payment form loads, a risk our article on PCI DSS payment page security explains in detail.
What happens when a provider is breached
If a provider in your payment flow suffers a compromise, card brands and your bank will ask what due diligence you did and what the agreement said. Without documentation, the merchant often absorbs forensic costs, card replacement fees and possible penalties passed through by the acquirer, even when the provider’s systems were the source.
Why acquirers are asking more questions
Acquiring banks and payment facilitators have tightened their review of small merchants’ Self-Assessment Questionnaires. A yes answer on Requirement 12.8 now increasingly comes with a request to see the provider list or the responsibility matrix behind it.
How Requirement 12.8 Breaks Into Five Concrete Tasks
Requirement 12.8 breaks into five tasks, numbered 12.8.1 through 12.8.5, and each produces a document you can show an assessor. None requires special software. A spreadsheet and a folder of signed agreements will satisfy most small merchants.
12.8.1 and 12.8.2: the list and the agreements
Requirement 12.8.1 asks for a list of all TPSPs with which account data is shared or that could affect its security, including a description of the services each provides. Requirement 12.8.2 asks for written agreements in which each provider acknowledges responsibility for the security of the account data it handles or could affect. Review your contracts for that acknowledgment. Many standard processor terms include it, but IT and web vendors often do not.
12.8.3: due diligence before you sign
Requirement 12.8.3 asks for an established process for engaging providers, including proper due diligence before the engagement. In practice, that means asking for the provider’s PCI status, reviewing their Attestation of Compliance where they have one, and recording what you checked and when. Our article on how to manage third-party cyber security risks offers a broader vendor review framework that fits alongside this.
12.8.4 and 12.8.5: annual monitoring and the matrix
Requirement 12.8.4 asks you to monitor each provider’s PCI DSS compliance status at least once every twelve months. Requirement 12.8.5 asks you to maintain information about which requirements are managed by each provider, which by your business, and which are shared. This responsibility matrix is the piece most often missing, and it is the one that turns a vague relationship into something an assessor can verify.
What a PCI Responsibility Matrix Should Contain
A PCI responsibility matrix is a table that lists each relevant PCI DSS requirement and states whether your business, the provider, or both are responsible for meeting it. Requirement 12.9.2 obliges service providers to supply information to support this, so you can ask them for their version.
Start from the provider’s own documents
Large processors and hosting providers publish responsibility summaries or include them in their Attestation of Compliance. Ask each provider for theirs, then adjust it to match how your business uses their service. A hosted payment page provider may own most technical requirements, while you still own the security of the website that loads it.
Cover the shared controls explicitly
Shared requirements cause the most confusion. Access control, logging and change management often split between you and an IT provider. Write down who does what for each, such as who reviews user accounts, who keeps logs and who approves changes to payment-related systems. Our guide on managing third-party vendor access to your systems covers the access side.
Keep it current when services change
Update the matrix when you add a provider, change payment methods or move to a new platform. An outdated matrix is almost as unhelpful as none, because it describes a payment flow that no longer exists.
How to Build Your Third-Party Service Provider Program This Month
A third-party service provider program for a small merchant can be built in a few working sessions with a spreadsheet, the contracts you already have, and a handful of emails to vendors. The goal is a set of documents that answer every 12.8 question without scrambling.
Map the payment flow first
Draw how a card payment moves through your business, from the customer’s device to your processor, and note every vendor that touches or can affect each step. Include IT support, web hosting, website developers, point-of-sale vendors and any call center. This map becomes the source for your provider list.
Collect evidence and agreements
For each provider, file the signed agreement, the current Attestation of Compliance or other evidence of PCI status, and a note of what you reviewed and when. Set a calendar reminder to request new evidence every year. Vendors with remote access deserve extra attention; our article on securing third-party vendor access with ShieldHQ describes one way to control it.
Get help where the gaps are large
If agreements lack security language or a key vendor cannot show PCI status, decide whether to renegotiate, add compensating controls or replace the provider. Our cybersecurity compliance team helps merchants work through these decisions, and our emergency cybersecurity compliance service supports businesses facing an urgent deadline from their acquirer.
Frequently Asked Questions
Do PCI DSS third-party requirements apply to small merchants?
Yes, Requirement 12.8 applies to every merchant that shares cardholder data with a provider or relies on one that could affect its security. The documentation can be simple, but it must exist.
Is my managed IT provider a PCI third-party service provider?
If your IT provider can access or change systems in your cardholder data environment, it can affect card data security and should be treated as a TPSP. That means a written agreement, due diligence and annual monitoring.
What is an Attestation of Compliance?
An Attestation of Compliance is a formal document a service provider completes to declare its PCI DSS compliance status after an assessment. Merchants commonly use it as evidence for Requirement 12.8.4.
How often do I need to check a provider’s PCI status?
At least once every twelve months under Requirement 12.8.4, and whenever the provider’s services to you change.
What if a provider will not share PCI documentation?
Record the request and the response, assess the risk, and consider compensating controls or a different provider. A provider that cannot show its status is a gap your acquirer may question.
Who Is Behind This Guidance
Mindcore Technologies helps small and midsize businesses meet PCI DSS, HIPAA, CMMC and other compliance requirements, including the vendor documentation that assessors and acquiring banks ask for. Our team builds provider inventories, reviews agreements and helps merchants answer Self-Assessment Questionnaire questions with evidence rather than guesswork. Mindcore is led by CEO Matt Rosenthal, who focuses on helping organizations reduce compliance and cyber risk with practical controls that leadership and auditors can verify.
Put Your PCI Provider Documentation in Order
PCI DSS third-party requirements make one point clear: outsourcing payments and IT reduces your workload but not your accountability. Requirement 12.8 asks for five things you can produce with ordinary tools: a list of every provider that touches or can affect card data, written agreements that name their security duties, due diligence before engagement, an annual check of each provider’s compliance status, and a responsibility matrix showing who owns each requirement. The matrix is where most small merchants fall short, and it is also the document that makes every conversation with an assessor or acquirer easier. Map your payment flow, gather the agreements and evidence, fill in the matrix and set an annual reminder. If you are unsure which vendors count or what your contracts actually say, our team can help. Book a free strategy call and we will walk through your payment flow, identify your service providers and build the documentation Requirement 12.8 expects.
