Merchant levels and validation: who decides what you file

The Council writes the standard and enforces nothing

This is not a technicality. It is the structural fact that explains every confusing answer you have ever received about PCI. The Council publishes PCI DSS, qualifies assessors and scanning vendors, and stops there.

No, the PCI Security Standards Council will not be replacing the individual brands' compliance programs. The individual participating payment brands will separately determine what entities must be compliant, including any brand-specific enforcement programs.PCI Security Standards Council, FAQ 1004

On consequences, it is equally direct: the Council "does not manage compliance programs and does not impose any consequences for non-compliance. Individual payment brands, however, may have their own compliance initiatives, including financial or operational consequences to certain businesses that are not compliant."

And on the threshold question of whether you have to do anything at all, the Council's own PCI DSS page closes with a sentence worth memorising: "Whether an entity is required to comply with or validate compliance to a PCI SSC standard is at the discretion of organizations that manage compliance programs, such as a payment brand, acquirer, or other entity."

The Council is also clear that compliance and validation are different things. Small merchants are inside the standard regardless of volume: "PCI DSS is intended for all entities involved in payment processing, including merchants, regardless of their size or transaction volume." Whether they have to prove it "is determined by the individual payment brands."

Five brands, five sets of thresholds

Each brand counts only its own transactions and sets its own bands. They are close enough to look interchangeable and different enough to catch you out. American Express states the position on its own page: each payment brand defines their levels differently.

Merchant tiers as each brand publishes them

Brand	Top tier begins at	Levels	Top tier obligation
Visa	Over 6 million Visa transactions annually across all channels, or global designation as Level 1 by any Visa region	Three published	File a Report on Compliance by a QSA, or by an internal resource if signed by an officer of the company, and submit an Attestation of Compliance
Mastercard	More than six million total combined Mastercard and Maestro transactions annually, or Level 1 with Visa, or Mastercard designation	Four	Annual PCI DSS assessment resulting in the completion of a Report on Compliance
American Express	2.5 million American Express transactions or more per year, or Amex designation	Four	Annual on-site assessment with a ROC Attestation of Compliance, or a STEP attestation where the merchant qualifies
Discover	6 million or more card transactions annually on Discover Network, or Discover designation, or Level 1 with another brand	Three	On-site assessment by a QSA, plus quarterly external vulnerability scans by an ASV
JCB	One million or more e-commerce, mail order or telephone order transactions	No numbered levels	Yearly on-site review and a quarterly security scan

The lower tiers are where the surprises live

Mastercard places merchants with more than 20,000 combined Mastercard and Maestro e-commerce transactions annually, up to one million, at Level 3, and everyone else at Level 4. It then says something that reads oddly the first time: "Level 4 merchants are required to comply with the PCI DSS, although validation of compliance to Mastercard is not required, except as required by applicable law or regulation." The obligation exists; the reporting does not. Mastercard shifts the burden to the acquirer instead, requiring it to "validate to Mastercard that they have a risk management program in place to identify and manage payment security risk within their Level 3 and Level 4 merchant portfolios."

Discover takes a similar line at its Level 3, where the Attestation of Compliance "is required upon request from Discover Network". American Express marks Levels 3 and 4 as reporting "if required by American Express, otherwise optional", while its Data Security Operating Policy adds that those merchants "need not submit Validation Documentation unless required in American Express' discretion, but nevertheless must comply with, and are subject to liability under all other provisions" of the policy.

The pattern is consistent across brands: below the top tiers, the paperwork becomes discretionary and the obligation does not.

Service providers are counted differently

If you store, process or transmit account data on behalf of someone else, you are a service provider for that part of your business, and a different set of thresholds applies. Two of them converge on the same number.

• Visa places at Level 1 its own processors and "any service provider that stores, processes and/or transmits over 300,000 Visa transactions annually", requiring an annual on-site assessment and an Attestation of Compliance signed by both the service provider and the QSA. Below that line, Level 2 providers submit a signed SAQ D or an AOC with a QSA signature, and Visa notes that QSA validation is required before a provider can be listed on its Global Registry of Service Providers.
• Discover draws the same 300,000 line, requires an annual on-site QSA assessment plus quarterly ASV scans at Level 1, and states that providers self-assessing must use "PCI DSS Self-Assessment Questionnaire D for Service Providers".
• Mastercard uses categories rather than volume for most of them. Every third-party processor, staged digital wallet operator, digital activity service provider, business payment service provider, token service provider, 3-D Secure service provider, installment service provider and merchant payment gateway is Level 1 regardless of transaction count. Only AML and sanctions service providers, data storage entities and payment facilitators are sorted by the 300,000 threshold.
• American Express sets its service provider split at 2.5 million of its own transactions and, unlike its merchant programme, has no discretionary lower tier: both levels are mandatory reporting.

That Mastercard rule catches more European fintechs than any other line on this page. A small payment gateway with modest volume is Level 1 for Mastercard on the basis of what it does, not how much of it it does.

There is no PCI certificate

This one is worth stating without hedging, because a whole industry of certificates exists in defiance of it. PCI SSC recognises only its own forms.

No. The only documentation recognized for PCI DSS validation are the official form documents from the PCI SSC website. Any other form of certificate or documentation issued for the purposes of documenting compliance to PCI DSS or any other PCI SSC standard are not authorized or validated by PCI SSC, and their use is not acceptable for evidencing compliance.PCI Security Standards Council, FAQ 1220

The recognised set is short: the Report on Compliance, the Attestations of Compliance, the Self-Assessment Questionnaires, and the Attestation of Scan Compliance for ASV scans. The Council goes further and says that use of unofficial certificates is not acceptable for the third-party requirements in 12.8 and 12.9 either, and that an entity receiving one "should request that documentation be provided using the official PCI SSC templates."

If a supplier hands you a certificate with a logo on it, the polite response is to ask for the AOC.

What your suppliers owe you

Most merchants meet PCI mainly through other people's systems, and the requirements that govern that relationship are 12.8 and 12.9. The Council's guidance on them is unusually practical.

• You must manage and oversee every third-party service provider relationship and monitor their compliance status "at least annually". The Council notes that 12.8 "does not specify that the customer's TPSPs must be PCI DSS compliant, only that the customer monitors their compliance status".
• If a provider has an Attestation of Compliance, it "is expected to provide the AOC to customers upon request", and that AOC has to cover the services it actually provides to you. You may also ask for relevant sections of its ROC or its SAQ D for Service Providers.
• A provider that hands over a merchant-style attestation is not answering the question. The Council states that a provider offering only "a limited set of SAQ requirements applicable to a merchant (for example, SAQ A or an SAQ A Attestation of Compliance (AOC)) has not provided sufficient evidence of PCI DSS compliance for its merchant customers."
• A provider validated to an older version of the standard can still count, provided the validation was completed before that version retired and "12 months have not passed since the service provider's validation".
• Your assessor does not have to visit them. The Council states it "does not require that an entity's assessor go onsite to the entity's TPSP and retest PCI DSS requirements that have already been covered in the TPSP's current PCI DSS assessment."

The twelve-month line is the one to diarise. An AOC that was fine at signing quietly stops being evidence, and the discovery usually happens in the middle of your own assessment.

Dates, and the one that matters most

The version timeline is public and settled. PCI DSS v4.0 was published in March 2022. Version 3.2.1 retired on 31 March 2024. Version 4.0.1, a limited revision with "no additional or deleted requirements", was published in June 2024, and v4.0 itself retired on 31 December 2024, leaving v4.0.1 as the only active version. Of the 64 new requirements introduced in v4.0, 51 were future-dated and became effective on 31 March 2025.

Against all of that, the date that governs your programme is a private one. Discover states it plainly: "The due date to report your PCI DSS compliance to Discover Network is one year from the date of prior compliance validation." Your clock started when you last validated, and the Council's calendar is a different thing entirely.

For what you will be asked to have tested by then, see ASV scan or penetration test and segmentation testing.