TL;DR
Requirement 12.8 is the boring-looking vendor control that still shows up on SAQ A. Inventory your TPSPs, get a real written security acknowledgment (an AOC on a drive is not that), do due diligence before you go live, check their PCI status at least yearly, and write down who owns which requirements. Using a "PCI compliant" processor does not make you compliant — the standard says so out loud.
You know the sentence. Every founder says it once:
"We're on Stripe / Adyen / Shopify Payments, so PCI is basically their problem."
Half true. Half how you fail an attestation quietly.
I keep seeing the same pattern — on SAQ A merchants especially. The payment form is outsourced (good). The gateway has an Attestation of Compliance somewhere in a Notion page from 2023 (less good). Nobody has a current list of who can actually affect account-data security. The contract never says the vendor acknowledges security responsibility. And when the acquirer asks for the SAQ package, everyone scrambles to invent a vendor file that should have existed all year.
That scramble is what PCI DSS v4.0.1 Requirement 12.8 is trying to prevent.
This is not a product pitch dressed up as a requirement post. It's the control I wish people took seriously before they open the wizard — because 12.8 is one of those things that looks administrative until it isn't.
For the A vs A-EP fork, see SAQ A vs SAQ A-EP. For payment-page scripts (different topic), see SAQ A for hosted checkouts. For the full SAQ map: PCI DSS v4.0.1 SAQ types explained.
What 12.8 actually is
In v4.0.1 wording: risk to information assets associated with third-party service provider (TPSP) relationships is managed.
In human wording: if someone else can touch your card data story — process it, host a piece of it, or knock over the systems around it — you own managing that relationship. Not "hope their logo is on a PCI list." Manage it.
The requirement breaks into five parts: 12.8.1 through 12.8.5. Same family on SAQ A and on the bigger questionnaires. The difference is usually how long your vendor list is — not whether 12.8 applies.
Who counts as a TPSP (spoiler: more people than you think)
A TPSP here is any third party you share account data with, or that could affect the security of account data.
So yes:
- Payment processors and gateways
- Hosted checkout / iframe providers
- Platforms that sit in the payment path
And also, often:
- Hosting / cloud / CDN that can affect in-scope pages
- Remote-access support vendors, MSPs, "the agency that still has staging credentials"
If they store, process, or transmit account data for you — or they could impact that security — they go on the list under Requirement 12.8.1.
Still unsure which SAQ you're even on? Which SAQ Am I? is a starting point. Your acquirer still gets the final say.
The five controls, without the consultant voice
12.8.1 — Make a list that isn't a lie
Requirement 12.8.1: Maintain a list of all TPSPs with which account data is shared or that could affect the security of account data, including a description of the services each provides.
This is the spreadsheet that should exist and somehow never does.
Name, what they do, why they're in scope, last reviewed. That's it. If your "vendor list" is a vague memory of who you pay in Stripe Billing, you don't have 12.8.1 yet.
12.8.2 — Written agreement with a real acknowledgment
Requirement 12.8.2: Maintain written agreements with those TPSPs. The agreement must include an acknowledgment that the TPSP is responsible for the security of account data they possess or otherwise store, process, or transmit on your behalf — or to the extent they could impact the security of your cardholder data and/or sensitive authentication data.
Here's the part people hate, because it ruins a comforting myth:
An AOC is not this.
A website that says "we're PCI compliant" is not this.
A responsibility matrix sitting outside the contract is not this.
PCI SSC's own notes on 12.8.2 are blunt about that. The acknowledgment has to live in the written agreement (or a signed addendum tied to it). Collecting PDFs in a folder is 12.8.4 energy. It is not 12.8.2.
If your MSA is silent, fix the paper — don't invent a story in the SAQ.
12.8.3 — Due diligence before go-live (not after the audit email)
Requirement 12.8.3: An established process for engaging TPSPs, including proper due diligence prior to engagement.
Translation: you don't add a processor on a company card on Tuesday and invent vendor review on Thursday because the bank asked.
A short written process is enough for most SAQ A shops. What matters is that diligence happened before engagement, and you can show something dated — questionnaire, AOC request, scope notes, whoever signed off.
12.8.4 — Check their PCI status at least every 12 months
Requirement 12.8.4: A program to monitor TPSPs' PCI DSS compliance status at least once every 12 months.
Annual AOC chase. Calendar reminder. Ticket. Whatever you'll actually do.
And the applicability note that should be tattooed on every "but they're compliant" Slack thread:
Using a PCI DSS–compliant TPSP does not make your entity PCI DSS compliant. It also doesn't remove your responsibility for your own compliance. If they're meeting requirements on your behalf and they aren't meeting them, those requirements aren't in place for you either.
Their good AOC helps your 12.8.4 file. It is not a hall pass for the rest of 12.8 — and it is not your Attestation of Compliance.
12.8.5 — Write down who owns what
Requirement 12.8.5: Maintain information about which PCI DSS requirements are managed by each TPSP, which are managed by you, and any that are shared.
This is the responsibility matrix people skip until a QSA (or a stubborn acquirer) asks a simple question: "For logging / patching / access — is that you or them?"
"They handle security" is not a row.
Prefer something boring and specific: requirement (or control activity), owner = TPSP / you / shared, and if shared — who does the work vs who keeps evidence. Example: they produce logs; you review them. They patch the base platform; you patch what you deploy.
Silent gaps live in 12.8.5. That's why it's there.
What "good enough evidence" looks like
| Sub-req | What you're proving | What I want in the folder |
|---|---|---|
| 12.8.1 | We know our TPSPs | Inventory + service descriptions |
| 12.8.2 | They acknowledged security responsibility in writing | Signed agreement / addendum |
| 12.8.3 | We vetted them before go-live | Process + dated diligence notes |
| 12.8.4 | We checked PCI status within 12 months | Current AOC (or equivalent) + review date |
| 12.8.5 | We know the requirement split | Matrix: TPSP / us / shared |
If someone asks "show me your third parties," you should open one place — not reconstruct history from email.
SAQ A vs the bigger questionnaires
On SAQ A (including the Jan 2025 r1 questionnaire): 12.8.1–12.8.5 are in. That surprises people who think SAQ A means "vendors did everything." No — SAQ A means you outsourced the payment form. You still manage the relationships.
Scripts / eligibility for payment-page attacks are a separate movie. Don't mash them into 12.8. Use the hosted-checkout post for that.
On SAQ A-EP and larger merchant SAQs: Same five sub-requirements. Longer vendor list. Denser 12.8.5 matrix. More hosting, CDN, remote-access, and "tooling that can touch the payment page" entries. Intent doesn't change. Blast radius does.
Level 1: Same control family, different validation path. If you're Level 1, you're in ROC / QSA territory — not "download an SAQ and self-attest." Don't let a blog post tell you otherwise; your acquirer / brand program does.
Mistakes I see on repeat
"Gateway is PCI compliant → 12.8 done."
Helps 12.8.4. Does nothing for inventory, contract language, diligence, or the matrix.
"We have AOCs, so we're fine."
Useful. Still not 12.8.2.
"Marketing pixels aren't TPSPs."
Maybe. If an integration can affect account-data security on a payment-initiating page, revisit scope — and read the scripts post before you argue with yourself.
"We'll build the matrix after we finish the SAQ."
12.8.5 is part of finishing the SAQ honestly.
Finish the artefact (when the vendor file isn't fiction)
12.8 is organizational overhead with teeth. Once the TPSP folder is real, you still need the right questionnaire completed and signed for your channel — the thing your acquirer actually files.
- SAQ A — guided wizard, plain-English answers, signed PDF when you're ready (€99 report; fill first, pay on download).
- SAQ A-EP — same motion for the larger questionnaire (€699 report).
Confirm the SAQ type with your acquirer before you attest. Which SAQ Am I? helps you think; it doesn't override the bank.
If you want a second pair of eyes on whether your vendor file would survive a bored reviewer, write sales@pcidss-dashboard.com — happier to look at a messy folder early than a rejected PDF late.
