Konfirmity

Part of the PCI DSS compliance guide

PCI Compliance Levels: Merchant and Service Provider Tiers Explained

Amit Gupta

Amit Gupta

2026-10-05

PCI compliance levels are tiers assigned by the individual card brands, based mainly on how many card transactions you process a year. Your level determines your validation route — who assesses you and with which instrument — not which of the twelve PCI DSS requirements apply to you. All twelve apply to everyone who stores, processes or transmits cardholder data, at every level.

That single distinction resolves most of the confusion. A Level 4 merchant is not held to a shorter standard than a Level 1 merchant. It is held to the same standard with a lighter proof obligation: a self-assessment questionnaire instead of an audit conducted by someone else.

The second thing worth knowing early is that the levels are not the PCI Security Standards Council's. They belong to Visa, Mastercard, American Express, Discover and JCB individually, and the thresholds differ between them.

What PCI Compliance Levels Actually Decide

PCI compliance levels decide the validation route — the instrument you fill in, and whether an independent assessor signs it. They do not decide scope, and they do not switch requirements on or off.

So if you are hoping that being Level 4 lets you skip network segmentation, encryption of stored card data, or logging, it does not. Those obligations sit in the twelve requirements, and the twelve requirements are level-agnostic. What being Level 4 usually means is that you attest to meeting them yourself rather than paying a Qualified Security Assessor to test them.

Teams routinely budget as if a lower level meant less engineering work. It means less assessment work. The control work is driven by how card data moves through your systems, which is a scope reduction question.

Who Sets the Levels, and Why Your Acquirer Is the Authority

The card brands set the levels, and your acquirer tells you which one you are. The PCI DSS standard itself is published by the PCI Security Standards Council, but the Council does not assign merchant levels, does not enforce them, and does not collect your attestation.

Each brand publishes its own bands, and they are close but not identical — counts are per brand, and some brands treat e-commerce, mail-order and card-present channels differently. A merchant that is Level 2 for one brand can land at Level 3 for another in the same year.

So confirm your level in writing with your acquirer before you commission anything. Do not read it off a blog, including this one. The acquirer accepts or rejects your validation documents, and if they say you are Level 1, you are Level 1 regardless of what a threshold table suggests. Brands and acquirers also retain discretion to designate a merchant at a higher level than volume alone would indicate.

The standard itself and the Council's guidance are at pcisecuritystandards.org.

The Four PCI Merchant Levels Against Validation Route

The commonly published shape across the card brands is four PCI merchant levels driven by annual transaction volume. Treat the bands below as the brands' typical published figures and verify yours with your acquirer — thresholds vary by brand and by channel.

LevelCommonly published volume bandValidation instrumentWho performs itQuarterly ASV scans
Level 1More than ~6 million transactions a year for a given brand; also any merchant that has suffered a breach, or that a brand designatesReport on Compliance (ROC) plus Attestation of Compliance (AOC)Qualified Security Assessor, or an Internal Security Assessor where permittedWhere the instrument calls for them
Level 2Roughly 1 million to 6 million transactions a yearSelf-Assessment Questionnaire plus AOCSelf-completed, signed by the merchantWhere the instrument calls for them
Level 3Roughly 20,000 to 1 million e-commerce transactions a yearSelf-Assessment Questionnaire plus AOCSelf-completed, signed by the merchantWhere the instrument calls for them
Level 4Below the Level 3 bandSelf-Assessment Questionnaire plus AOCSelf-completed, signed by the merchantWhere the instrument calls for them

Two caveats that the table cannot carry. First, an acquirer or a brand can require a ROC at any level — the SAQ route for Levels 2 to 4 is the common case, not an entitlement. Some acquirers require a ROC of Level 2 merchants as a matter of policy. Second, which SAQ you complete is a separate decision driven by how you accept payments, not by your level; the SAQ types and eligibility are worth settling before you start filling anything in.

Not sure whether you are on the SAQ route or the ROC route?

Send your work email and we will send back the questions to put to your acquirer to pin down your level per brand, plus which validation instrument each answer points to.

We check that your email domain is real and can receive mail before sending. If we can't verify it, we won't be able to follow up — so please use a work address rather than a forwarding or temporary one.

We'd like to know who we're talking to. By submitting this form you agree that we may contact you about Konfirmity — no more than six emails a year, and we won't ask again each time. You can unsubscribe from any of them, and we'll stop. See our Privacy Policy.

PCI DSS Level 1 Requirements in Practice

The PCI DSS Level 1 requirements that differ from other levels are requirements about proof, not about controls. A Level 1 merchant validates with an annual Report on Compliance, performed by a Qualified Security Assessor or by an Internal Security Assessor where the brand permits that, together with an Attestation of Compliance.

The day-to-day experience differs sharply even though the control set is identical. A ROC means an external party selects samples, interviews your engineers, reads your configurations and decides whether each requirement is met. Assertions that would pass unchallenged on a self-assessment get tested. Evidence has to exist in a form someone else can read, dated and tied to the period under review.

That is why moving from an SAQ to a ROC catches teams out. The controls were nominally in place for years; what was missing was the evidence trail and the consistency across sampled systems. Budget for the assessor's time, your engineers' time answering them, and a remediation window before the assessment rather than after.

Quarterly external scans by an Approved Scanning Vendor apply where the validation instrument calls for them, across levels — this is not a Level 1 addition. If your instrument requires them, you need four passing quarters, so start ASV scanning early enough that failed scans can be remediated and rescanned before your attestation is due. The same timing logic applies to penetration testing.

Service Provider Levels PCI Treats as a Separate Scheme

The service provider levels PCI uses are a different scheme from the merchant levels, and conflating the two is the most common mistake in this topic. A service provider is an entity that stores, processes or transmits cardholder data on behalf of others, or that can affect the security of those transactions.

Service providers are commonly split into two levels, by the volume of transactions they handle on behalf of others. The larger tier is required to validate by annual on-site assessment resulting in a Report on Compliance; the smaller tier is permitted a self-assessment. Service providers may also be required to appear on card brand registries of compliant providers, which is a listing process separate from validation itself. Thresholds and registry rules are brand-specific — confirm both with each brand or with your sponsoring acquirer.

Note the asymmetry. Two levels, not four, and the volume that pushes a service provider into an on-site assessment is far lower than the merchant Level 1 threshold. A payment-adjacent SaaS company with a modest customer base can sit in the large tier while a direct-to-consumer retailer with ten times the transaction count stays on an SAQ.

If you handle card data for your customers, you are probably in this scheme rather than the merchant one, and you may be in both. Enterprise buyers will ask for your AOC and your registry listing during vendor review, which makes the validation route a sales dependency rather than a back-office one.

Counting Transaction Volume for PCI Purposes

Transaction volume for PCI level purposes is counted per card brand, over a year, and for the whole corporate entity rather than per website or per business unit.

Three counting details change the answer more often than people expect. Volume aggregates across all your channels and all your doing-business-as names under one legal entity, so five storefronts on one merchant account add up. It is counted separately for each brand, so your Visa count and your Mastercard count are different numbers and can land in different bands. And brands may count e-commerce and card-present volume under different rules, which is why the Level 3 band is commonly stated in e-commerce terms specifically.

So pull twelve months of settled transaction counts from your acquirer, split by brand and channel, and send them back with one question: which level does this put us at, per brand, for the coming year? Their written answer feeds everything downstream — instrument, assessor, budget. Re-ask annually, and ask how they treat a threshold crossed mid-year, since only your acquirer can confirm the timing they apply.

A Breach Can Move You to Level 1 Regardless of Volume

A breach can move a merchant to Level 1 regardless of volume. This is the rule most likely to invalidate a plan built purely on transaction counts, and it is worth stating to your board before anything happens rather than after.

The mechanism is simple: brands designate merchants to Level 1 following a compromise of cardholder data, so the validation route switches from a questionnaire you complete to an assessment someone else performs. A company that has never engaged a QSA finds itself needing one under time pressure, with an incident to explain and evidence that was never built to be read by an outsider.

The defence is not pre-emptive Level 1 validation. It is operating the controls as if they would be sampled and keeping evidence in a state where a QSA could pick it up. Teams that run a PCI DSS compliance checklist against themselves continuously, rather than in the weeks before an attestation, absorb a level change without a crisis.

What Changes With Level, and What Never Does

What changes with level is narrow, and what never changes is broad. Setting the two side by side stops a lot of wasted argument.

  • Changes with level: the validation instrument (ROC versus SAQ), whether an independent assessor performs the assessment, the cost and duration of validation, and in some cases registry listing obligations for service providers.
  • Never changes with level: which of the twelve requirements apply, how scope is determined, the obligation to secure stored cardholder data, and the expectation that controls operate continuously rather than at attestation time.
  • Not driven by level at all: which SAQ you are eligible for, whether your instrument requires quarterly ASV scans, and how much of your environment falls in scope.

The last bullet is where the real cost lives. A merchant with a flat, unsegmented network and card data in half a dozen systems has far more work at Level 4 than a Level 1 merchant that routes everything through a hosted payment page. To bring the effort down, reduce scope — and read the changes in PCI DSS v4 before designing around assumptions from the previous version.

PCI Compliance Level Questions Teams Ask

These are the PCI compliance level questions teams ask most often once they realise the level sets their validation route rather than their control obligations.

No. All twelve PCI DSS requirements apply to every entity that stores, processes or transmits cardholder data, at every level. Your level determines the validation route — whether you complete a Self-Assessment Questionnaire or undergo a Report on Compliance performed by a Qualified Security Assessor — not which requirements are in play. What genuinely reduces the work is reducing scope, for instance by moving card capture to a hosted page so your own systems never touch card data.

Ask your acquirer, in writing, and ask per card brand. The brands define the levels individually and their thresholds differ, so you can hold different levels with different brands in the same year. Pull twelve months of settled transaction counts split by brand and channel, send them over, and ask which level they are placing you at for the coming validation cycle. Brands and acquirers can also designate a merchant higher than volume alone suggests, which is why the acquirer's answer is the authoritative one.

No, they are a separate scheme. Service providers are commonly split into two levels rather than four, by the volume of transactions they handle on behalf of others: the larger tier validates by annual on-site assessment and Report on Compliance, the smaller tier is permitted a self-assessment. Service providers may also need to appear on card brand registries. Thresholds and registry rules are brand-specific. A company can be both a merchant and a service provider, with a separate obligation under each.

Yes. The Self-Assessment Questionnaire route commonly available to Levels 2 through 4 is the usual case, not a right. An acquirer or a card brand can require a Report on Compliance at any level, and some acquirers require one of Level 2 merchants as standing policy. Confirm which instrument your acquirer expects before planning the work — the gap between completing an SAQ and engaging a Qualified Security Assessor is the largest single variable in validation cost and timeline.

It can. Brands may designate a merchant as Level 1 following a compromise of cardholder data, regardless of transaction volume, switching the validation route from a self-assessment to an assessment performed by a Qualified Security Assessor. Planning only against your transaction count leaves you exposed to that switch. Operate controls and retain evidence as though an outside assessor would sample them, so a level change becomes a scheduling problem rather than a remediation programme.

Keep your PCI evidence ready for whichever validation route you land on

Book a demo and we will show how Konfirmity maps the twelve requirements to your systems and keeps the evidence current, so an SAQ or a QSA-led ROC draws from the same record.

Book a demo

Confirm Your Level Before You Scope the Work

Get your level in writing from your acquirer, per brand, before you commission an assessor or start filling in a questionnaire. It is a short email and it removes the largest source of rework in a first PCI programme — discovering in month three that you are on the ROC route, or that you are a service provider rather than a merchant, or both.

Then stop thinking about the level. Once the validation route is settled, every remaining decision is about scope and controls: where card data enters, which systems touch it, and what evidence shows the twelve requirements operating. That work is the same at Level 4 as at Level 1, and it is where the cost sits, which is why a realistic view of PCI DSS cost starts from your data flows rather than your transaction count.

If you are building that view now, start with the twelve PCI DSS requirements and work outward to what each one needs from your environment. The level tells you who checks your answer. The requirements tell you what the answer has to be.

Tools

Put your PCI DSS plan into numbers

More PCI DSS guides

Related Articles

PCI ASV Scan Requirements: What Four Passing Quarters Take

Security Controls & Practices

amit-gupta

2026-10-05

PCI ASV Scan Requirements: What Four Passing Quarters Take

arrow

PCI ASV scan requirements mean four passing quarterly external scans a year from a Council-listed vendor. What gets scanned, and where teams lose a quarter.

PCI DSS Compliance Checklist: A Phased Plan You Can Actually Work

Templates & Checklists

amit-gupta

2026-10-05

PCI DSS Compliance Checklist: A Phased Plan You Can Actually Work

arrow

A sequenced PCI DSS compliance checklist: confirm your CDE scope, choose an SAQ or ROC route, work the twelve requirements, then attest with evidence.

PCI DSS Compliance Cost: How to Build a Budget That Holds

Leadership & Strategy

amit-gupta

2026-10-05

PCI DSS Compliance Cost: How to Build a Budget That Holds

arrow

Nobody can quote your PCI DSS compliance cost without seeing your scope. The real line items, what moves each one, and how to build the estimate yourself.

PCI DSS Penetration Testing Requirements: Scope, Segmentation and Evidence

Security Controls & Practices

amit-gupta

2026-10-05

PCI DSS Penetration Testing Requirements: Scope, Segmentation and Evidence

arrow

PCI DSS penetration testing requirements under Requirement 11: external and internal scope, segmentation testing, and the report an assessor accepts.

The 12 PCI DSS Requirements: What Each One Demands and How It Is Evidenced

Beginner Guides

amit-gupta

2026-10-05

The 12 PCI DSS Requirements: What Each One Demands and How It Is Evidenced

arrow

All twelve PCI DSS requirements grouped under their six control objectives, with what each one demands and the evidence an assessor will ask you to produce.

PCI DSS SAQ Types: Which Self-Assessment Questionnaire You Need

Audit & Readiness

amit-gupta

2026-10-05

PCI DSS SAQ Types: Which Self-Assessment Questionnaire You Need

arrow

The nine PCI DSS SAQ types, who each one is for, and how to tell SAQ A from SAQ A-EP before your acquirer makes the decision for you.

How Real Security Becomes Compliance

Built by the CTO who scaled NIUM to $2 billion. 10 years building security and compliance for regulated fintechs. 4.5 years running Konfirmity profitably.

Book a call