How to Identify the Right PCI Compliance Level for Your Business

Key Takeaways

• PCI DSS doesn’t define merchant levels. The card brands do.
  
• Your level is based on transaction volume and breach history.
  
• Service providers face stricter validation, even at low volumes.
  
• SAQs are based on how you handle cardholder data.
  
• Your level can change yearly or after an incident.
  
• Centraleyes streamlines PCI prep and audit readiness.

Let’s start with a simple truth:

PCI DSS doesn’t assign compliance levels.

Surprised?

Most people you talk to lump “Level 1” and “Level 4” merchants directly under PCI DSS as if those classifications come from the standard itself.

But they don’t.

So, where do PCI compliance levels actually come from?

The levels are determined by the card brands.

Visa, Mastercard, American Express, Discover, and JCB each define compliance tiers- often based on how many transactions you process annually and whether you’ve had a breach.

These levels determine how you prove compliance, not whether you’re subject to PCI DSS.

Who enforces these PCI DSS levels?

Not the PCI Security Standards Council (PCI SSC).

Enforcement and level assignment come from the payment brands and your acquiring bank- the institution that handles your card transactions.

Who are the key players in PCI compliance?

Before diving deeper, it’s helpful to understand the major players involved in PCI compliance and their roles:

• PCI Security Standards Council (PCI SSC) – The standards body. They publish PCI DSS and related documentation but do not enforce compliance.
• Card Brands (e.g., Visa, Mastercard, AmEx, Discover, JCB) – The companies that define merchant and service provider levels based on transaction volume and risk.
• Acquirer (Acquiring Bank) – The financial institution that enables merchants to accept card payments and acts as the enforcement arm of PCI compliance. They:
  • Assign your PCI level
  • Notify you of reporting requirements
  • Receive your SAQs or ROCs
  • Escalate you if there’s a breach
• Merchants – Businesses that accept card payments for goods or services.
• Service Providers – Businesses that process, store, or transmit cardholder data on behalf of others (e.g., payment gateways, hosting platforms).
• QSAs (Qualified Security Assessors) – Certified professionals authorized by the PCI SSC to perform on-site assessments and issue Reports on Compliance (ROCs).
• ASVs (Approved Scanning Vendors) – Third parties certified to perform required vulnerability scans for PCI DSS.

What does the PCI DSS standard require?

The PCI DSS (currently version 4.0) outlines a single set of security requirements for all entities that store, process, or transmit cardholder data.

It includes:

• 12 core requirements
  
• Detailed implementation guidance
  
• Assessment templates (like SAQs and ROC)
  

But it never says “Level 1 merchants must do X.” Because PCI DSS doesn’t define levels at all.

Where did the PCI merchant levels come from?

You might be wondering: if PCI DSS doesn’t define the PCI DSS levels of compliance, why do they exist?

These levels of PCI compliance were introduced by card brands in the mid-2000s when PCI compliance was still relatively new and adoption was inconsistent.

At the time, payment brands needed a scalable way to ensure merchants and service providers were properly securing cardholder data without requiring every mom-and-pop shop to go through a full-scale audit.

The solution? A risk-based tier system.

Merchants and service providers that processed higher volumes of transactions posed greater exposure to fraud and data breaches. So they were grouped into stricter tiers (like Level 1), requiring full QSA-led audits and deeper oversight.

Smaller merchants with lower transaction volumes, on the other hand, were permitted to complete a self-assessment, reducing compliance burden while still holding them to the same core requirements.

This model allowed for:

• Proportional validation requirements
• A clearer path for acquirers to manage risk across their merchant portfolios
• Reduced overhead for small businesses

Today, this structure is nearly universal.

Here’s a breakdown of the merchant levels (based on Visa/Mastercard guidelines):

Level	Who it applies to	What’s required
Level 1	Over 6 million transactions/year OR history of breach	Full QSA audit + ROC + AOC + ASV scans
Level 2	1 to 6 million transactions/year	SAQ or ROC (depending on acquirer) + AOC + scans
Level 3	20k to 1M e-commerce transactions/year	SAQ + AOC + scans
Level 4	Fewer than 20k e-commerce or under 1M total	SAQ + maybe scans (acquirer decides)

Service provider levels are simpler:

• Level 1: Over 300,000 transactions → QSA-led ROC
  
• Level 2: Under 300,000 → SAQ D (unless acquirer says otherwise)
  

Merchants vs. service providers: What’s the difference?

Understanding whether you’re a merchant or a service provider is more than a technicality- it directly affects your compliance level and validation requirements.

• A merchant is any entity that accepts payment cards for goods or services.
• A service provider is any business that stores, processes or transmits cardholder data on behalf of another entity.

This includes payment gateways, hosting providers, managed security service providers, or any vendor that can impact the security of cardholder data.

Why this matters:

• Merchants are grouped into 4 merchant levels, and some may qualify for simplified SAQs depending on transaction volume and infrastructure.
• Service providers have only 2 levels, and are much more likely to require a full QSA-led audit, even at lower volumes.

For example, a merchant processing 50,000 e-commerce transactions may complete SAQ A, while a service provider supporting just 10 clients could be required to submit a full ROC.

This difference reflects the higher risk and broader impact service providers pose across the payment ecosystem. Many enterprises and acquirers also demand greater transparency and assurance from third-party vendors.

If your business sits in a gray area, it’s worth confirming your classification with your acquirer or a Qualified Security Assessor (QSA).

Where do you start if you’re unsure of your PCI DSS compliance level?

Step 1: Determine Your Compliance Level

A. Calculate how many card transactions you process annually (per card brand)

• Over 6 million → Likely Level 1
• 1M–6M → Level 2
• 20k–1M (e-commerce) → Level 3
• Less than 20k (e-commerce) or under 1M total → Level 4

B. Have you had a security breach involving cardholder data?

• Yes → You may be escalated to Level 1, regardless of volume
• No → Your level likely aligns with transaction volume

Once your level is established, you’ll know if you’re required to complete a full ROC or may be eligible to complete an SAQ instead.

Step 2: If SAQ-Eligible, Determine Which SAQ Type Applies

A. Do you store, process, or transmit cardholder data directly?

• Yes → You’re likely in scope for SAQ D or a full ROC (depending on level)
• No → You may qualify for a simplified SAQ (like A, A-EP, B, or C)

Can you choose a stricter level voluntarily?

Yes. Many smaller businesses opt into Level 1-style audits to build trust with partners or large clients.

Being “over-compliant” might not be fun, but sometimes it’s strategic.

What are SAQs?

If you’re not required to do a full audit, you’ll complete a Self-Assessment Questionnaire (SAQ) instead.

An SAQ is a structured, standardized form issued by the PCI Security Standards Council. It allows merchants and service providers—typically those in lower compliance levels—to validate that they meet PCI DSS requirements without undergoing an on-site assessment by a Qualified Security Assessor (QSA).

SAQs are used when:

• Your acquirer or card brand has determined your level allows for self-validation
• You don’t store cardholder data directly, or your environment has limited risk exposure

There are 9 types of SAQs, each designed for different technical environments. The SAQ type you use depends on how payments are processed and whether your systems touch cardholder data. 

Here’s a quick SAQ cheat sheet:

• SAQ A: Fully outsourced e-commerce (e.g., Stripe + no card data touching your systems)
  
• SAQ A-EP: You host part of the e-commerce environment
  
• SAQ B / B-IP: Standalone terminals
  
• SAQ C / C-VT: POS or virtual terminals
  
• SAQ D: Catch-all for complex environments and all service providers
  

What if I’m not a merchant?

If you handle cardholder data on behalf of others (e.g., a payment gateway, hosting provider, or cloud service), you’re a service provider- even if you don’t directly charge cards.

The card brands hold service providers to higher scrutiny.

Can your level change?

Yes.

Your compliance level isn’t static:

• Increase in transactions → may trigger Level 1 requirements
• A security breach → may cause an acquirer to bump your level

In fact, most acquiring banks review your level annually based on your previous year’s transaction volume. If you’ve grown significantly- or experienced a compromise- you may be required to undergo a more stringent validation process.

Likewise, your validation method isn’t fixed either. If you change your payment architecture, such as:

• Moving from hosted checkout to on-site processing
• Adding new third-party payment processors
• Consolidating PSPs to reduce scope

…your applicable SAQ type may change, or you may fall under more (or less) rigorous compliance expectations.

Always review your payment flows when updating infrastructure- it can directly affect how you’re scoped.

Where do you go from here?

• Start with your transaction counts per card brand
  
• Clarify your role (merchant or service provider)
  
• Work with your acquirer to confirm your level and obligations
  
• Choose the right SAQ- or prepare for a full ROC
  

Who does what? PCI SSC vs. Card Brands

Responsibility	PCI Security Standards Council (PCI SSC)	Card Brands (Visa, Mastercard, etc.)
Publishes the PCI DSS standard	✅ Yes	❌ No
Defines compliance levels (e.g., Level 1, 2, 3, 4)	❌ No	✅ Yes
Sets security control requirements	✅ Yes (e.g., 12 core PCI DSS requirements)	❌ No
Creates Self-Assessment Questionnaires (SAQs)	✅ Yes	❌ No
Determines if you need a QSA audit	❌ No	✅ Yes (often via your acquirer)
Maintains QSA, ASV, and PA-DSS lists	✅ Yes	❌ No
Enforces compliance	❌ No	✅ Yes (directly or through acquiring banks)
Provides guidance documents & training	✅ Yes	❌ No
Handles breaches or fines	❌ No	✅ Yes

How Centraleyes helps you get PCI-ready

Centraleyes gives you the tools to streamline every stage of PCI compliance.

With Centraleyes, you can:

• Automatically map PCI DSS requirements to controls and policies across your organization
• Identify and assess gaps with built-in readiness checks
• Manage and track evidence collection in a centralized workspace
• Generate auditor-ready reports, including SAQs and custom ROC-readiness exports
• Stay ahead of version updates like PCI DSS 4.0 with real-time content

We also work with certified auditors to help you move from readiness to full compliance with ease.

But even if you’re managing PCI on your own, Centraleyes adapts to your needs. From small merchants seeking guided SAQ workflows to enterprises conducting internal validations, our platform adapts to fit your business type, compliance goals, and level of support.

FAQs

1. Do all card brands have the same PCI levels and requirements?

No. While the four merchant levels are similar across Visa, Mastercard, Discover, and AmEx, the exact thresholds and reporting requirements can vary slightly by brand.

2. What happens if I ignore my PCI level and skip validation?

Your acquirer may fine you, increase your transaction fees, or terminate your ability to process card payments altogether.

3. Can a third-party payment processor make me exempt from PCI DSS?

No. Even if you fully outsource processing, you’re still responsible for validating PCI compliance, typically through a simplified SAQ (such as SAQ A).

4. If I use Stripe or Square, do I still need to take any additional steps?

Yes. These providers simplify compliance, but you must still complete an SAQ and confirm you’re not storing or handling card data yourself.

6. Is PCI DSS required by law?

No federal law mandates PCI DSS in most countries, but card brands contractually require it, and some U.S. states and countries reference it in their own security laws.

7. Can my PCI level be downgraded if I reduce the number of transactions?

Yes, but only after a full annual cycle has passed. Your acquiring bank must review and approve a reclassification.