PCI DSS 12.8.2: Written agreements with TPSPs are maintained
PCI DSS v4.0.1 control 12.8.2: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 12.8.
Requirement 12: Support Information Security with Organizational Policies and Programs › Section 12.8
Written agreements with TPSPs are maintained as follows:
- Written agreements are maintained with all TPSPs with which account data is shared or that could affect the security of the CDE.
- Written agreements include acknowledgments from TPSPs that TPSPs are responsible for the security of account data the TPSPs possess or otherwise store, process, or transmit on behalf of the entity, or to the extent that the TPSP could impact the security of the entity’s cardholder data and/or sensitive authentication data.
Summary
Have a written agreement with every third party that handles account data or could affect the security of your card environment, and make sure it says in writing that they are responsible for the data they hold.
What the assessor will examine
These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.
| Procedure | |
|---|---|
| 12.8.2.a | Examine policies and procedures to verify that processes are defined to maintain written agreements with all TPSPs in accordance with all elements specified in this requirement. |
| 12.8.2.b | Examine written agreements with TPSPs to verify they are maintained in accordance with all elements as specified in this requirement. |
Two procedures, and the second is the one that bites. 12.8.2.a examines whether you have a process for maintaining these agreements. 12.8.2.b examines the agreements themselves and checks the acknowledgement is actually present. A signed contract that never mentions PCI DSS responsibility passes 12.8.2.a and fails 12.8.2.b. Note the scope wording: it is not only providers who touch account data, but any that "could impact the security" of your environment, which pulls in hosting, tag managers and support tooling. Pair this with 12.8.1, the list of providers, and 12.8.4, monitoring their compliance status.
What to prepare
- The list of third-party service providers from 12.8.1, which is what tells you how many agreements you should have.
- The written agreement for each one, with the responsibility acknowledgement identifiable in it.
- The provider’s current Attestation of Compliance for the specific services you use, dated within the last twelve months.
- Your process document for putting an agreement in place before a new provider is engaged.
How to implement it
1. Start from the provider list, not the contract folder. The gap is almost always a provider nobody classified as one: the hosting company, the CDN, the tag manager, the session-replay tool, the outsourced support desk. Each of these can affect the security of the payment page even though none of them "handles" card data in the ordinary sense.
2. Check the acknowledgement clause exists, by name. Many standard vendor agreements say nothing about PCI DSS responsibility. Where a provider will not amend the master agreement, a signed addendum or their published responsibility matrix referenced by the agreement is the usual route.
3. Get the AOC at the same time as the agreement. Asking for an Attestation of Compliance is a routine request to any serious provider, and the answer is informative either way: a provider who cannot produce one is telling you something about the responsibility you are about to accept.
4. Make it a gate in procurement. An agreement obtained after the provider is live is evidence of a process that does not work. The cheapest place to enforce this is before the contract is signed.
5. Record which responsibilities are yours. The clearest agreements say who does what for each applicable requirement. Where the provider does not offer a responsibility matrix, write down your own understanding and have them confirm it, because the assessor will ask who covers each control.
Where this commonly fails
- A fully outsourced merchant assuming outsourcing removes the obligation. It moves the work to the provider and leaves you the agreement, the AOC and the monitoring.
- The hosting provider left off the list, when for an e-commerce merchant they are among the clearest cases of a party that could affect security.
- A signed contract with no PCI DSS responsibility acknowledgement anywhere in it, which fails 12.8.2.b.
- An AOC collected once at onboarding and never refreshed, so it no longer covers the current period or the services now in use.
- Nested providers ignored: your provider’s own subcontractors can be in scope, and the agreement should say how that is handled.
Related controls
Others in section 12.8:
| Control | What it requires |
|---|---|
| 12.8.1 | A list of all third-party service providers (TPSPs) with which account data is shared… |
| 12.8.3 | An established process is implemented for engaging TPSPs… |
| 12.8.4 | A program is implemented to monitor TPSPs’ PCI DSS compliance status at least once every 12… |
| 12.8.5 | Information is maintained about which PCI DSS requirements are managed by each TPSP… |
← 12.8.1 · All controls · 12.8.3 →
Source
The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.
The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.