PCI DSS 12.8.5: Information is maintained about which PCI DSS requirements are managed by each TPSP
PCI DSS v4.0.1 control 12.8.5: the requirement in full, the 3 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
Information is maintained about which PCI DSS requirements are managed by each TPSP, which are managed by the entity, and any that are shared between the TPSP and the entity.
Summary
Write down, requirement by requirement, which controls your provider covers, which you cover, and which you share.
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.5.a | Examine policies and procedures to verify that processes are defined to maintain information about which PCI DSS requirements are managed by each TPSP, which are managed by the entity, and any that are shared between both the TPSP and the entity. |
| 12.8.5.b | Examine documentation and interview personnel to verify the entity maintains information about which PCI DSS requirements are managed by each TPSP, which are managed by the entity, and any that are shared between both entities. |
| 12.8.5 | in accordance with all elements specified in this requirement. |
The control that makes outsourcing checkable. Without it, both parties assume the other has a requirement, which is how a fully outsourced merchant arrives at an assessment with no evidence for controls neither side ran. The three procedures examine the policy, the information itself, and the entity’s understanding of it, so it has to be more than a document you were handed: you have to know what it says. Most serious providers publish a responsibility matrix; where they do not, writing your own and having them confirm it is the accepted route, and it pairs directly with the agreement in 12.8.2.
What to prepare
- A responsibility matrix covering the requirements applicable to your environment, per provider.
- The provider’s own published matrix where one exists, and your confirmation of it where it does not.
- Evidence you have read and understood it, which is what the third procedure examines.
How to implement it
1. Cover shared requirements explicitly. The requirement names three categories, and "shared" is the one that gets lost. Requirement 12.6 awareness training is a good example: the provider trains their staff, you train yours, and neither covers the other.
2. Do it per requirement, not per service. "They handle payments" is not a mapping. The matrix has to be at a level where you can point at a control and say who evidences it.
3. Reconcile it against your own evidence. Anything marked as the provider’s should have their attestation behind it; anything marked yours should appear in your own evidence. Requirements with neither are the finding this control exists to surface.
4. Revisit it when the service changes. Adding a provider feature can move a requirement across the line, and the matrix is usually the last thing anyone updates.
Where this commonly fails
- A matrix supplied by the provider and filed unread, which the third procedure tests directly.
- Requirements assumed to be the provider’s because the service is "fully managed", with nothing recording it.
- Shared requirements marked as belonging to one side, so half the obligation is unmet.
- A matrix covering the provider’s standard offering rather than the services you actually buy.
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.2 | Written agreements with TPSPs are maintained… |
| 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.4 · All controls · 12.9.1 →
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.