PCI DSS 12.8.4: A program is implemented to monitor TPSPs’ PCI DSS compliance status at least once every 12
PCI DSS v4.0.1 control 12.8.4: 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
A program is implemented to monitor TPSPs’ PCI DSS compliance status at least once every 12 months.
Summary
Check at least once a year that each of your third-party providers is still PCI DSS compliant, and keep the evidence.
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.4.a | Examine policies and procedures to verify that processes are defined to monitor TPSPs’ PCI DSS compliance status at least once every 12 months. |
| 12.8.4.b | Examine documentation and interview responsible personnel to verify that the PCI DSS compliance status of each TPSP is monitored at least once every 12 months. |
The obligation that outlives onboarding. 12.8.2 gets the agreement and the attestation once; this one is a program to monitor status at least every twelve months, so an AOC collected at signing and never refreshed fails it. 12.8.4.a examines the policy defining the program, 12.8.4.b examines evidence that the monitoring happened. The practical trap is timing: a provider’s AOC has its own expiry, and yours is not aligned to it, so a provider can lapse mid-year without anyone noticing.
What to prepare
- The documented monitoring program: who checks, how often, and what they check.
- Current evidence per provider, dated within the last twelve months.
- The provider list from 12.8.1, which defines how many checks you owe.
- A record of what you did where a provider could not evidence compliance.
How to implement it
1. Track each provider’s AOC expiry, not your review date. Reviewing everyone every January means a provider whose attestation lapsed in February is unmonitored for eleven months.
2. Decide in advance what a failed check triggers. A provider that cannot produce a current AOC is a risk decision, and having no process for it is why these checks quietly stop happening.
3. Use the published lists where they exist. Visa and Mastercard maintain service provider registries; for providers that appear on them, checking is quick and the evidence is a dated screenshot or export.
4. Keep the evidence yourself. A link to a provider’s trust page is not evidence twelve months later, because the page changes.
Where this commonly fails
- An AOC collected at onboarding and treated as permanent.
- Monitoring the payment provider and not the hosting provider, the CDN or the tag manager.
- Evidence held as a URL rather than a copy, so nothing is retained.
- No defined response when a provider fails the check, so the finding is recorded and nothing follows.
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.5 | Information is maintained about which PCI DSS requirements are managed by each TPSP… |
← 12.8.3 · All controls · 12.8.5 →
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.