PCI DSS (the Payment Card Industry Data Security Standard) is not government law - it is a contractual security standard maintained by the PCI Security Standards Council, a body founded by the major card brands, and enforced through card-brand rules and acquirer contracts rather than a regulator. It binds any entity that stores, processes, or transmits cardholder data or sensitive authentication data, and its Requirement 12 - the policy and governance requirement - is where the standard turns from securing an organization's own environment to managing the vendors that touch that data on its behalf. The current version, PCI DSS v4.0.1, published in June 2024 as a limited revision correcting v4.0 without changing any requirement, has been the only active version of the standard since v3.2.1 retired at the end of March 2024, and the full set of new v4.0 requirements originally introduced as "future-dated" became mandatory on 31 March 2025.
A third-party service provider (TPSP), in the standard's own vocabulary, is any entity - other than a payment brand itself - that is directly involved in processing, storing, or transmitting cardholder data on an organization's behalf, or that manages components of the cardholder data environment such as network security devices, firewalls, or physical access controls. That reaches further than "payment vendor" narrowly read: payment processors and gateways, hosting and cloud providers, managed security or IT vendors with access to the environment, and call-center or fulfillment vendors that see card numbers directly are all typically TPSPs.
Requirement 12.8: the five things a program owes its TPSPs
Requirement 12.8 - "Risk to information assets associated with third-party service provider (TPSP) relationships is managed" - is where PCI DSS names TPSP oversight as its own control, broken into five testable sub-requirements:
| Sub-requirement | What it requires |
|---|---|
| 12.8.1 | Maintain a list of all TPSPs with which account data is shared, or that could affect the security of the cardholder data environment, including a description of the service each one provides. |
| 12.8.2 | Maintain written agreements with each TPSP that include the TPSP's written acknowledgement that it is responsible for the security of account data it possesses or otherwise stores, processes, or transmits on the entity's behalf, or to the extent it could affect that data's security. |
| 12.8.3 | Follow an established process for engaging TPSPs, including proper due diligence before engagement. |
| 12.8.4 | Monitor each TPSP's PCI DSS compliance status at least once every 12 months. |
| 12.8.5 | Maintain information about which PCI DSS requirements are managed by each TPSP, which are managed by the entity itself, and which are shared between the two. |
Read together, the five map to a lifecycle rather than one control: 12.8.1 is inventory, 12.8.2 is the contract, 12.8.3 is pre-engagement diligence, 12.8.4 is ongoing monitoring, and 12.8.5 is the scoping question - who owns which control - that most vendor disputes after an incident turn out to hinge on. A program that has the signed agreement 12.8.2 requires but no current answer to 12.8.5 can point to a contract and still not say, in the middle of an incident, whether the TPSP or the entity itself owned the control that failed.
Requirement 12.9: what a TPSP owes back
Requirement 12.9 is the mirror image, binding organizations that are themselves TPSPs to their own customers. 12.9.1 requires a TPSP to acknowledge in writing to its customers that it is responsible for the security of account data it possesses, or otherwise stores, processes, or transmits, on the customer's behalf - the acknowledgement 12.8.2 requires the customer to obtain. 12.9.2 requires the TPSP to support its customers' 12.8.4 and 12.8.5 obligations directly, providing information about which PCI DSS requirements it manages, which the customer manages, and any that are shared, for any service that meets a PCI DSS requirement on the customer's behalf or could affect the security of the customer's account data. A TPSP that treats this as the customer's problem to chase down is itself out of compliance - the duty to hand over the responsibility split sits with the TPSP, not only with the customer's diligence process.
What counts as evidence, not just a claim
"PCI DSS compliant" is not itself a document a vendor can hand over. Per the Council's own FAQ guidance, a TPSP that has completed its own PCI DSS assessment should give customers sufficient evidence that the assessment's scope covered the services the customer actually uses, an Attestation of Compliance (AOC) applicable to those services, and - on request - the relevant sections of its full Report on Compliance (ROC) or SAQ D for Service Providers so the customer's own assessor can confirm the scope really covers what the customer relies on. A TPSP with no assessment or AOC of its own is expected to provide specific evidence against the applicable requirements directly, so the customer, or its QSA, can verify compliance without an AOC to point to. Either way, the 12.8.5/12.9.2 responsibility matrix is not paperwork alongside the evidence - it is what tells the customer's assessor which parts of that evidence actually apply to the service in scope for their own assessment.
An AOC scoped to the wrong service, or one that has quietly gone stale since its assessment window closed, satisfies none of this. That is exactly why the Council frames 12.8.4 monitoring as a recurring obligation rather than a one-time collection step - a point the Council's earlier Information Supplement on Third-Party Security Assurance made in laying out due diligence and ongoing-monitoring practices for TPSP relationships in the first place.
Validation levels: a QSA-audited ROC and a self-assessed SAQ are not interchangeable
Not every TPSP validates its own PCI DSS compliance the same way. The card brands - Visa and Mastercard chief among them - set merchant and service-provider validation levels by transaction volume, and the level determines the validation method: a higher-volume TPSP is generally required to undergo an annual on-site assessment by a Qualified Security Assessor (QSA) and produce a full Report on Compliance, while a lower-volume TPSP may self-assess against SAQ D for Service Providers. Both outcomes get described as "PCI DSS compliant," but a QSA-audited ROC and a self-attested SAQ are different strengths of evidence, and a program's own risk tiering - not a vendor's marketing page - should decide which one is acceptable for a given relationship. Each card brand sets and can revise its own volume thresholds, so check the brand's current published figures rather than treating any single number as fixed.
Turning Requirement 12.8 into TPRM actions
- Build the 12.8.1 inventory from data flow, not vendor category. Any vendor that can access, store, or affect the environment around cardholder data belongs on the list, not only the obvious payment processors. See vendor tiering.
- Get the 12.8.2 acknowledgement into the contract itself, not implied by a vendor's marketing claim of "PCI compliance" - and confirm the TPSP's own paperwork actually contains the 12.9.1 language, not just a reference to it.
- Treat 12.8.3 due diligence as a gate, not a formality. Request the AOC or equivalent evidence before cardholder data starts flowing, not after the contract is signed.
- Make 12.8.4 monitoring continuous in practice, even though the requirement's floor is once every 12 months - an AOC current at signing can lapse well before the next scheduled review. See continuous vendor monitoring.
- Keep the 12.8.5/12.9.2 responsibility matrix current per service, not per vendor - a TPSP providing more than one service can carry a different split of responsibility for each.
Where this sits among TPRM platforms
Collecting and expiring AOCs, ROCs, and responsibility matrices on a schedule is squarely governance workflow - the kind of structured library OneTrust and ProcessUnity are built to hold, alongside a SIG- or CAIQ-style questionnaire as corroborating evidence (see the Shared Assessments SIG). What that workflow does not tell a program is whether a TPSP's actual, internet-facing environment still matches what its last assessment described - the same gap covered generally in evidence-based risk scoring, where BitSight, SecurityScorecard, and UpGuard contribute externally observed signal. Rescana's role is pairing that continuous, evidence-based monitoring with automated evidence collection, so a 12.8.4 review checks current signal rather than trusting a document at face value until its stated period runs out.
Frequently asked questions
What does PCI DSS Requirement 12.8 require for third-party service providers?
PCI DSS Requirement 12.8 requires an organization to manage risk from its third-party service providers (TPSPs) through five sub-requirements: maintain a list of all TPSPs with access to account data or the cardholder data environment (12.8.1); maintain written agreements including the TPSP's acknowledgement that it is responsible for the security of account data it handles (12.8.2); follow an established due-diligence process before engaging a TPSP (12.8.3); monitor each TPSP's PCI DSS compliance status at least once every 12 months (12.8.4); and maintain a current record of which PCI DSS requirements the TPSP manages, which the entity itself manages, and which are shared (12.8.5).
What must a PCI DSS Requirement 12.8.2 written agreement with a TPSP contain?
At minimum, it must include the TPSP's written acknowledgement that it is responsible for the security of the account data it possesses, or otherwise stores, processes, or transmits, on the entity's behalf, or to the extent it could affect the security of that data. This acknowledgement is the customer-side half of Requirement 12.9.1, which separately obligates the TPSP to make the same acknowledgement directly to its customers - so the agreement should reflect language the TPSP is independently required to provide, not just a clause the customer's legal team drafted alone.
How often must a TPSP's PCI DSS compliance status be monitored?
Requirement 12.8.4 sets a floor of at least once every 12 months. In practice, an Attestation of Compliance that was current when a contract was signed can lapse well before the next scheduled annual review, so many programs treat 12.8.4 as a continuous monitoring obligation rather than a once-a-year calendar task - tracking a TPSP's assessment expiration alongside other signal about its current security posture rather than waiting for the next scheduled check.
What evidence should a TPSP provide to prove PCI DSS compliance?
A TPSP that has completed its own PCI DSS assessment should provide an Attestation of Compliance (AOC) scoped to the services the customer actually uses, sufficient evidence that the assessment's scope covered those services, and - on request - relevant sections of its Report on Compliance (ROC) or SAQ D for Service Providers. A TPSP without its own assessment or AOC should instead provide specific evidence against the applicable requirements directly. Either way, Requirements 12.9.1 and 12.9.2 also require the TPSP to supply a responsibility matrix showing which PCI DSS requirements it manages versus which the customer manages, since an AOC alone does not indicate which of its findings apply to the specific service in scope for the customer's own assessment.