PCI DSS 12.8.4: Check at least once every 12 months that each of your third-party providers is still PCI DSS compliant, and keep the evidence.
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.
PCIComplianceHubLast updated Last reviewed against PCI DSS v4.0.1
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 every 12 months 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 is the agreement and 12.8.3 the checks before signing; this one is a program to monitor status at least once every 12 months, so an AOC collected at signing and never looked at again 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. PCI DSS sets no expiry date for an AOC (PCI SSC FAQ 1601), but the payment brands expect providers to validate every year, so a provider whose last assessment is nearly a year old at your review is the one to chase. Where a provider meets requirements on your behalf and does not meet them, the applicability notes say those requirements are also not in place for you.
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: its AOC for the services you use, or, where it has none, the other evidence the guidance allows, such as evidence given to your assessor.
- 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 assessment date, not only your review date. Reviewing everyone every January means a provider assessed the previous February is close to a year old before you look. What happens if your provider’s AOC is nearly a year old? covers what the Council says.
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’s Global Registry of Service Providers is one; for a provider that appears on it, checking is quick and the evidence is a dated copy of what you saw.
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… |
Terms
Glossary entries that name this control, each with its own example, limits and sources:
← 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.