12.8 TPSP risk management: PCI DSS requirements and evidence

What 12.8 third-party service provider risk management asks of your organization

Requirement 12.8 asks your organization to manage the risk that comes with every third-party service provider (TPSP) that can affect your cardholder data environment. In practice that means keeping a current list of each TPSP, obtaining written agreements in which the provider acknowledges its security responsibility for account data, performing due diligence before engagement, monitoring each provider's PCI DSS compliance status at least every 12 months, and keeping a record of which requirements each provider manages, which you manage and which are shared. Outsourcing a function does not outsource accountability. The SAQ D note to 12.8.1 is explicit that using a PCI DSS compliant TPSP does not make your organization compliant or remove its responsibility for its own compliance. Requirement 12.8 also does not require providers to be PCI DSS compliant. PCI SSC FAQ 1312 makes clear that the obligation is for you to monitor their compliance status as specified.

The hard part is usually the inventory and the owner, not the contract. Hosting providers, payment processors, support desks, remote access tools, log platforms and managed services often reach the cardholder data environment through paths nobody mapped, and a vendor that was never recorded cannot be monitored. Ask each business unit and the finance and procurement teams which suppliers hold credentials, transmit data, manage systems or can change configurations in scope. Then check the list against your network and data-flow diagrams. Each entry should name an accountable internal owner, because the 12-month monitoring cycle fails quietly when no one is assigned to it.

Before you sign, confirm three things with each provider: whether its written terms include the security acknowledgment that 12.8.2 expects, which party performs each requirement according to its responsibility matrix, and what evidence it will supply each year, such as its current Attestation of Compliance or the responsibility information it owes you under 12.9. Treat a certificate or a marketing statement as insufficient, because PCI SSC FAQ 1220 states that compliance certificates are not acceptable evidence for 12.8 or 12.9. Where a provider cannot give you current official documentation, record the gap and the compensating action you are taking. Your assessor will expect to see that gap managed, not ignored.

Which third parties fall under 12.8 and which do not

Requirement 12.8 applies to third-party service providers that store, process, transmit or could affect the security of cardholder data or the cardholder data environment. The cards below group the relationships that most often change the work, with the scoping question to answer for each before you build the TPSP list.

Hosting and cloud providers

Infrastructure, colocation and cloud platforms that host systems inside or connected to the cardholder data environment usually fall under 12.8, because the provider can affect the security of stored or transmitted account data. Ask whether the provider runs any component of the CDE, holds encryption keys, or can reach systems that store account data. Shared responsibility documents from the provider help you record which requirements they manage, which you manage and which are shared.

Payment processors and gateways

Processors, gateways and payment facilitators that store, process or transmit account data on your behalf are the clearest TPSPs in scope. Ask which parts of the payment flow they handle, whether card data passes through your servers, and whether they return tokens or full account numbers. Their written agreement should acknowledge responsibility for the account data they handle, and you should record which payment flow requirements they cover.

Managed security and IT providers with CDE access

Managed security services, managed firewall operators, log monitoring firms and IT administrators with access to CDE systems are in scope even when they never see card numbers, because they can change the security of the environment. Ask what accounts they hold, whether access is remote, and who approves and reviews their sessions. Due diligence before engagement should cover their own security practices and their staffing for your account.

Software vendors in the payment flow

Software products that sit in the payment flow, such as checkout libraries, payment applications or remote management agents that run inside your environment, can affect account data even if the vendor never hosts it. Ask whether the software runs in your CDE, whether updates or support sessions reach it, and whether the vendor can change how it handles data. Keep the vendor on the TPSP list where its product or access touches the CDE.

Support and consulting firms with remote access

Consultants, support desks and contractors who log in remotely to troubleshoot CDE systems fall under 12.8 whenever they can reach those systems, regardless of how short the engagement is. Ask whether access is persistent or granted per ticket, whether it is logged, and whether the firm holds credentials you cannot revoke. Remote access is often the easiest scoping gap to miss, so review access logs against the list each year.

Non-payment script providers and assessors

Providers of scripts that cannot affect account data, and Approved Scanning Vendors and Qualified Security Assessors acting in the roles they hold for the assessment, are not TPSPs for 12.8 in the cases PCI SSC describes in FAQs 1592 and 1598. Confirm each exclusion against the FAQ wording and your own data flows before removing a provider from the list. A script that can read or alter payment pages in the browser is not a non-payment script, so check its technical behavior, not its label.

How an assessor tests 12.8.1 to 12.8.5

This table sets out, for each sub-requirement of 12.8, how an assessor typically tests it, what evidence to have ready, and the findings that appear most often. Read each row as a checklist of what to prepare before the assessment starts. Assessors record their work on official PCI SSC templates, and the main takeaway is that every row depends on a current, dated record.

Sub-requirement	How the assessor tests it	Evidence requested	Common findings
12.8.1 TPSP list	Compares the TPSP list against network diagrams, data-flow diagrams and payment system records to check that every provider with access to account data or the CDE is named, with a description of the service.	Current TPSP list with service descriptions, reconciled to data-flow and network diagrams and vendor contract register.	A provider with CDE access missing from the list, or a list that names services but not the data or systems each provider touches.
12.8.2 Written agreements	Samples contracts and reads the security language to confirm each TPSP acknowledges in writing that it is responsible for the cardholder data it stores, processes or transmits, or that could affect the CDE.	Signed agreements or addenda with security acknowledgment language, and the date each was executed.	An agreement that covers service levels or fees but says nothing about cardholder data security, or a contract that has lapsed without renewal.
12.8.3 Due diligence before engagement	Selects a sample of providers added during the period and reviews the onboarding file to confirm due diligence happened before the contract took effect.	Onboarding records showing the due diligence performed, who approved it, and its date relative to contract signature.	Due diligence completed after go-live, or onboarding files that contain no record of the review at all.
12.8.4 Monitoring every 12 months	Checks that each TPSP's PCI DSS compliance status was monitored at least every 12 months, using the dated monitoring record and the source the entity used, such as an AOC or a responsibility summary.	Dated monitoring log for each TPSP, with the compliance evidence reviewed and the reviewer's name. Compliance certificates do not count as evidence.	Monitoring review older than 12 months, reviews recorded without the status evidence, or reliance on a provider's marketing certificate.
12.8.5 Responsibility matrix	Reviews the matrix for each TPSP service and checks that every applicable requirement is assigned to the provider, to the entity, or shared, and that the split matches the contract and the service actually delivered.	Responsibility matrix per TPSP service, aligned with the contract and reviewed when the service changes.	A matrix that is generic and not tied to the service, shared requirements with no owner, or a matrix that contradicts what the contract says.

Building a 12.8 program in order, with the output of each step

This sequence turns Requirement 12.8 from a list of obligations into a working program, where each step produces a document or record that the next step depends on and that an assessor can inspect.

Build the TPSP inventory from data flows and asset records
Start from the cardholder data environment data-flow diagram and the system component inventory, then list every third-party service provider that stores, processes or transmits account data, or that could affect the security of the CDE. Include hosting, payment gateways, managed security services, remote support tools and software vendors with remote access. Ask each business owner to confirm the services their teams buy, because contracts often sit outside IT procurement. The output is an approved TPSP list that records the provider name, the service delivered and the systems involved, and it is signed off by the owner of the payment environment.
Classify each provider by access and data exposure
For each provider on the list, record what it can reach: account data, systems in the CDE, administrative access, or only connectivity that could affect CDE security. Assign a risk tier based on that exposure so that reviews and due diligence scale with the impact of a failure. Document the reasoning in the same record so an assessor can follow it. Confirm borderline cases against the PCI SSC FAQ guidance on which providers are not treated as TPSPs for Requirements 12.8 and 12.9. The output is a classified register with a tier, an access summary and a short rationale for each provider.
Update contract templates with security responsibility wording
Review the standard contract, data processing and services templates used with each tier, then add clauses in which the provider acknowledges in writing that it is responsible for the security of the account data it stores, processes or transmits, or that could affect the CDE. Have legal counsel confirm the wording and how it sits with existing liability and indemnity terms. Existing contracts usually need amendments or renewal language, so list which agreements must be revisited. The output is an approved clause set and a tracker showing which live contracts carry the acknowledgment.
Set a pre-engagement due diligence checklist
Create a checklist that the procurement and security teams complete before any new provider gets access to the CDE or account data. Typical items include the provider's current PCI DSS status and the evidence supplied for it, the scope of its services, its incident notification process, its use of subcontractors, and its responsibility for each requirement. Specify which evidence must be official PCI SSC documents, because compliance certificates are not accepted for this purpose. The output is a standard checklist and a completed due diligence file for each provider, stored with the approval record.
Assign a monitoring owner and calendar
Name one accountable owner for TPSP monitoring and record their deputies. Build a calendar that tracks, for every provider, the date its compliance status was last confirmed and the date the next confirmation is due, with monitoring at least every 12 months as the standard requires. Add triggers for earlier review, such as a new service, a security incident at the provider, or a material change in its environment. The output is a documented ownership record and a monitoring calendar that the compliance team can check during its own reviews.
Draft the responsibility matrix for each requirement
For each provider and service, map every PCI DSS requirement to one of three parties: the provider, your organization, or shared. Use the provider's own responsibility documentation as a starting point, then test each assignment against the systems and processes it covers. Gaps usually appear in shared items such as log review, access reviews and vulnerability scanning, so assign a named owner to each one. Your organization remains responsible for its own compliance whatever the provider does. The output is a draft matrix per provider, reviewed by the security team and the business owner.
Run the first monitoring cycle and sign the matrix
Work through the inventory, collecting current compliance evidence from each provider, checking it against the contract clauses, the due diligence file and the responsibility matrix, and logging any gaps with owners and dates. Ask the provider to confirm the matrix in writing, then have the program owner approve it. Record the results so that the next cycle can show what changed. Confirm with your QSA or internal assessor which evidence they will accept before the assessment starts. The output is a completed first monitoring record and a signed responsibility matrix for each provider.

Evidence that passes 12.8, and how to keep it current between audits

Requirement 12.8 is judged on records, not intentions. An assessor will expect a dated register, signed agreements, completed due diligence, monitoring records and a responsibility matrix, and each must still be accurate when the assessment happens. The cards below cover what each artifact contains and how to keep it current between assessments.

Dated TPSP register

This is the list of every third-party service provider that stores, processes or transmits account data for you, or that could affect the security of your cardholder data environment. Record the provider name, the service delivered, the date of the last review and the owner inside your organization. Review the register whenever a contract starts, ends or changes scope, and confirm that providers reached through a sub-contract or a shared platform are captured. Missing entries are a common reason the rest of the file fails to hold together.

Executed agreements with acknowledgments

Keep signed contracts that state the provider's responsibility for the security of the account data it handles or can affect. Check that the wording of each acknowledgment is in the executed contract, not only in a sales document or a web terms page. Store the signed copy with the register entry and flag renewals, so an expired agreement does not stay in the file. Ask counsel or procurement to confirm the acknowledgment language satisfies the requirement for each contract type you use.

Due diligence files before engagement

For each provider, keep a dated file showing the checks performed before the engagement began. Typical contents include the provider's most recent official PCI SSC attestation or report, a description of its security controls for the services you buy, the people or teams who reviewed it, and the decision taken. Update the file when the service changes materially. Note that a compliance certificate on its own is not acceptable evidence for 12.8, so the file must rest on official PCI SSC documentation or your own review.

Twelve-month monitoring records

Requirement 12.8.4 expects you to monitor each provider's PCI DSS compliance status at least every 12 months. Record the date of each review, the source you checked, the compliance status found, the person who reviewed it and any follow-up actions with due dates. Where a provider's status has lapsed or changed, record the risk decision and the compensating steps taken. Set a recurring calendar reminder, and confirm the review date falls inside each 12-month window.

Responsibility matrix

The matrix shows, for each requirement, whether the provider manages it, you manage it, or responsibility is shared. Review it whenever a provider changes its service, and when your own controls change. Assessors will compare the matrix with the other evidence, so each entry should match the agreement and the provider's official documentation. A matrix that assigns a requirement to nobody is a finding waiting to happen.

Change history for the file

Version control shows how each record changed over time, which supports the signed records but does not replace them. XWiki (LGPL-2.1-or-later) keeps every page change with what changed, when and by whom, and lets you compare versions and roll back. BookStack (MIT) assigns abilities through roles and allows permissions to be overridden at shelf, book, chapter or page level, so only designated reviewers can approve entries. CISO Assistant (AGPL-3.0-only) can run assessments against PCI DSS and map evidence to other frameworks. Confirm each tool fits your register and your retention rules before you rely on it.

Why a compliant vendor still leaves the monitoring duty with you

A provider's PCI DSS validation does not make your organization compliant. The SAQ D note to 12.8.1 is explicit that using a PCI DSS compliant TPSP does not remove your responsibility for your own compliance. Requirement 12.8 also does not require the provider to be PCI DSS compliant at all, only that you monitor its compliance status as the requirement specifies (PCI SSC FAQ 1312). Your duty is to know which provider touches your cardholder data environment, hold a signed agreement that acknowledges its security responsibility, check it before engagement, and review its status at least every 12 months. A provider's validation covers the provider's own environment and services as assessed. It does not prove that the configuration, access paths and data flows in your environment are covered, so the assessor will still ask what you did to confirm that.

The responsibility matrix required by 12.8.5 is where most gaps appear. It must record which requirements the provider manages, which you manage and which are shared, and it has to match what the provider actually does for your scope. Check the matrix against the provider's own attestation, the service description in your contract and the way your team uses the service. For example, if a hosted payment platform handles log retention for its own infrastructure but your team exports logs to your SIEM, the retention and review of those exported copies belong to you and should appear that way in the matrix. Confirm each line with the provider in writing before you rely on it.

The annual monitoring record also needs your own review. Under 12.8.4, the record of monitoring TPSP compliance status must be kept current, and a copied vendor file does not show that anyone on your side read it, questioned it or acted on exceptions. Your review should note the attestation date and scope, any changes to the service since the last check, open findings that affect your data, and the decision you made. Assessors commonly ask who performed the review and what they concluded, so plan for a named owner and a dated sign-off. Ask providers for an attestation or evidence package that names the services covered, and confirm with your assessor which official PCI SSC forms they will accept as evidence for 12.8.

What the 12.8 program costs to run each year

This table compares the main cost components of running Requirement 12.8, who is paid for each one, whether it is one-time or recurring, and what pushes it up or down. No fee or duration is given here, so use the drivers to shape a written quote based on a fixed scope.

Cost component	One-time or recurring	What drives it up	What keeps it down
Tooling or licenses	Recurring for commercial tools, one-time setup for self-hosted tools	Number of providers tracked, separate tools for register, contracts and questionnaires, per-user licensing	One register for all providers, self-hosted open-source tools with no license fee under their licenses
Internal engineering and compliance time to build the register and matrix	One-time build, then recurring upkeep	Undocumented provider services, unclear shared responsibilities, many business owners with no single record	A single TPSP list, a responsibility matrix template, named owners for each provider
Contract review by legal	Recurring for new and renewed contracts	Non-standard security terms, renegotiation of acknowledgments, each provider using its own paper	A standard contract clause set with the security acknowledgment, pre-approved fallback language
Vendor questionnaires and evidence collection	Recurring, at least yearly per provider	Number of providers with CDE access, slow provider responses, requests for evidence not on file	A shared questionnaire, a reusable evidence library, accepting official PCI SSC templates and forms
External review or consulting	Optional, one-time or periodic	Scope of the review, number of providers reviewed, gaps found during readiness work	Fixed-scope review agreed in writing, internal ownership of records between reviews
Assessor time during the audit	Recurring with each assessment	Number of providers sampled, incomplete or scattered records, missing monitoring evidence for the last 12 months	Current records kept in one place, monitoring evidence stored as it is produced

Who owns 12.8 in-house, who an implementation partner supports and what the assessor checks

Your organization owns Requirement 12.8 in full. The standard places the decision to rely on a third party, and the monitoring that follows, with the entity being assessed. Using a compliant provider does not transfer your own compliance obligations, so the people who run this program must be employees or accountable internal owners who can answer for it.

Owning the register: Maintain the list of third-party service providers that store, process, transmit or could affect account data, and keep it current when contracts start or end.
Signing agreements: Ensure written agreements acknowledge the provider's security responsibility for the account data it handles, and route them through legal and procurement before work begins.
Running monitoring: Collect each provider's compliance status at least every 12 months and record the follow-up when a provider falls short.
Approving the responsibility matrix: Confirm which requirements the provider manages, which you manage and which are shared, and sign off on the record.
Accepting provider risk: Make the decision to proceed with a provider, and document why any residual risk is acceptable.

Before the assessment, confirm that each named owner can show the register, agreements and monitoring history without relying on an outside party to produce them.

Questions buyers ask before they bring in help with 12.8

How long does 12.8 work take, and what sets the timeline?

The timeline depends mainly on how many third-party service providers (TPSPs) you use and how many of them can reach your cardholder data environment (CDE). A short list of providers with clear contracts can be documented quickly. A long list, with providers that have CDE access and agreements that predate PCI DSS v4.x, takes longer because each provider needs a written acknowledgment, a due diligence file and a responsibility matrix entry. Other drivers are how well your contract records are organized and how quickly vendors answer requests for their compliance status. Because DeployOpen works under fixed scopes agreed in writing, ask for a quote that lists the provider count, the CDE-access split and the deliverables for each one before work starts.

What does my internal team need to provide for 12.8?

Your team must own the process. Someone with authority needs to approve the TPSP list, accept responsibility for monitoring each provider and sign off on the responsibility matrix, because the organization owns its compliance. Your team also needs access to the contracts, since the written agreements must be checked for security acknowledgments. Finally, you need named vendor contacts who can supply compliance status and responsibility information on request. Ask any implementation partner to confirm in writing which of these items it will request from you and by when, so gaps surface early rather than during the assessment.

Can we meet 12.8 without outside help?

Yes. Requirement 12.8 is mostly records and recurring discipline, so an internal team can meet it with a provider register, standard contract language, a due diligence checklist and a calendar for the yearly status review. The register should list each TPSP, the services it provides, whether it can affect account data and which requirements it manages, the entity manages or the two share. Outside help is usually a choice about capacity and speed, not a requirement. If you go it alone, confirm the approach with your acquirer or payment brand and with your Qualified Security Assessor (QSA) before the assessment.

What does a partner do for 12.8 that the QSA does not?

A partner prepares the systems, records and evidence that the QSA will test. Typically that means building the TPSP register, reviewing contracts for acknowledgment language, drafting responsibility matrices, setting up the monitoring calendar and collecting provider evidence in an organized way. The QSA is independent and does not prepare your materials, so the QSA evaluates what you present and issues the Report on Compliance (ROC) or reviews the Self-Assessment Questionnaire (SAQ). Only the QSA or the assessment process issues the validation. Ask any partner to state in writing that it will not perform the assessment itself, and to name the deliverables it will hand over.

Does using a PCI DSS compliant provider remove our 12.8 duty?

No. The SAQ D note to 12.8.1 states that using a PCI DSS compliant TPSP does not make an entity compliant or remove its responsibility for its own compliance. PCI SSC FAQ 1312 adds that 12.8 does not require a provider to be PCI DSS compliant. What it does require is that you keep a list of providers, hold written agreements, perform due diligence and monitor each provider's compliance status at least every 12 months. A compliant provider simplifies that monitoring, but you still need the records.

Can a provider's compliance certificate serve as 12.8 evidence?

No. PCI SSC FAQ 1220 says compliance certificates are not acceptable evidence for Requirements 12.8 or 12.9. Only official PCI SSC templates and forms count. In practice, ask each provider for its current Attestation of Compliance on the official template, along with the responsibility information that 12.8.5 expects. Ask the provider to confirm the validity period and the services in scope, because an attestation that does not cover the service you buy does not help you.

What should we ask for in a 12.8 quote?

Ask for a written scope that lists the number of TPSPs, which of them have CDE access, and which sub-requirements (12.8.1 to 12.8.5) the work covers. Request a deliverables list, such as the TPSP register, contract review notes, the due diligence template, the responsibility matrix and the monitoring calendar. Confirm who owns each item after handover, which items recur every 12 months, and what your team must supply. Also ask what is excluded, including any work on the QSA side, and how changes to the provider list during the engagement will be priced. Ask for the quote in writing before any work starts.

How DeployOpen prepares the 12.8 program and its evidence

DeployOpen works on 12.8 as an implementation partner: it prepares the third-party service provider inventory, the responsibility matrix and the monitoring records inside your own environment. Your organization owns the program, and an independent QSA or the applicable payment brand decides how the evidence is assessed.

How we scope

Engagements are fixed-scope, with the TPSP list, systems covered and deliverables agreed in writing before work starts.
We confirm which providers touch the cardholder data environment, including those that can affect account data security.
The written scope states who maintains each monitoring record and which parties hold the responsibility matrix.

How we build

We set up a maintained TPSP register that records services, data flows and the contact owner for each provider.
We draft the responsibility matrix showing which 12.8 requirements the entity manages, the provider manages, or both share.
We configure version-controlled document and approval workflows so changes to agreements and due diligence records stay traceable.

How we hand over

You receive the TPSP inventory, responsibility matrix, due diligence templates and review schedule in editable form.
Records are arranged so your QSA or internal assessor can locate the official PCI SSC templates and provider evidence they need.
Handover includes a short walkthrough so your team can run the annual monitoring cycle without us.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing.
Retainers can cover recurring 12-month monitoring reviews and updates when providers or services change.
Confirm with your assessor which artifacts they accept before you finalize the evidence set for your next validation.

12.8 Third-party service provider risk management