PCI DSS- A quick guide to its levels

PCI DSS Compliance Levels: A Complete, Updated Guide

PCI DSS stands for Payment Card Industry Data Security Standard — the global security framework created through a collaboration between American Express, Discover, JCB, Mastercard, and Visa in 2004. Any organization that stores, processes, or transmits cardholder data, whether in clear text or encrypted form, is required to comply with it. We've covered where the standard came from, and what's changed with the move to PCI DSS 4.0, in our companion guide, PCI DSS: The Payment Industry's Armour — worth a read if you want the full backstory before diving into levels and validation requirements here.

Most people can describe PCI DSS at a high level. Far fewer can explain the compliance levels within it — what determines which level a business falls into, what each level actually requires, and how those requirements have shifted under PCI DSS 4.0. This guide covers exactly that.

PCI DSS Compliance Levels

PCI DSS compliance is divided into four levels, based on the number of credit or debit card transactions a business processes annually. These levels determine what an organization actually needs to do — and how it needs to prove it — to stay compliant.

Level 1

Applies to merchants processing more than six million card transactions annually. Level 1 carries the strictest validation requirement in the standard: an authorized PCI Qualified Security Assessor (QSA) conducts an annual assessment, including an on-site (or remote-equivalent) evaluation, to:

• Authenticate the scope of the assessment

• Evaluate technical information and documentation

• Confirm whether PCI DSS requirements are actually being met

• Guide the organization through the compliance process

• Evaluate any compensating or customized controls in place

On successful evaluation, the QSA issues a Report on Compliance (RoC) to the organization's acquiring bank, formally demonstrating compliance. Under PCI DSS 4.0, this evaluation increasingly has to hold up as continuous evidence rather than a point-in-time snapshot — a Level 1 organization needs to be able to show that controls like MFA enforcement, payment page script monitoring, and access logging are operating consistently, not just correctly configured on the day the QSA visits.

Level 2

Applies to merchants processing between one and six million card transactions annually. Security testing reports on network hosts and applications need to be completed on a defined, regular frequency, and — depending on the acquiring bank's requirements and the card network involved — a RoC from a QSA may also apply at this level, alongside or instead of a Self-Assessment Questionnaire (SAQ).

Level 3

Applies to merchants processing between 20,000 and one million e-commerce transactions annually. A yearly assessment using the relevant SAQ, along with a quarterly PCI-approved vulnerability scan, is required.

Level 4

Applies to merchants processing fewer than 20,000 e-commerce transactions annually, or up to one million transactions across other channels. Like Level 3, this requires a yearly SAQ-based assessment and a quarterly PCI scan.

A note on thresholds: the exact transaction thresholds for each level can vary slightly between card networks — Visa, Mastercard, American Express, Discover, and JCB each publish their own merchant levels, and while they're broadly aligned with the structure above, it's worth checking directly with your acquiring bank or the specific card network to confirm which level applies to your business.

Self-Assessment Questionnaires (SAQs): Which One Applies to You

PCI DSS defines several types of SAQs, and the right one depends on how a merchant handles card data — not just its transaction volume. Under PCI DSS 4.0, the SAQ categories remain broadly the same as under 3.2.1, but the underlying questions within each SAQ reflect the strengthened 4.0 requirements — MFA across the CDE, payment page script integrity, and targeted risk analyses among them. The main SAQ types include:

• SAQ A: For merchants who fully outsource card data processing (including e-commerce transactions) to certified, PCI-compliant third parties, and retain no cardholder data on their own systems.

• SAQ A-EP: For e-commerce merchants who outsource payment processing but retain control over the site that redirects customers to the payment processor — meaning the merchant's own site can still influence the security of the transaction.

• SAQ B: For merchants who don't store cardholder data electronically but use standalone, dial-out terminals for card-present transactions.

• SAQ B-IP: For merchants who don't store cardholder data electronically but use IP-connected point-of-interaction (POI) devices — applicable to both card-present and card-not-present scenarios.

• SAQ C: For merchants with payment application systems connected to the internet, where the payment application system is not connected to any other systems within the merchant's environment.

• SAQ C-VT: For merchants who process cardholder data manually via a virtual payment terminal, with no electronic cardholder data storage.

• SAQ D: The most comprehensive SAQ, applicable to merchants and service providers who don't qualify for any of the more limited categories above — essentially, anyone whose card data environment doesn't fit a narrower, lower-risk profile.

• SAQ P2PE: For merchants using a validated point-to-point encryption (P2PE) solution, where cardholder data is encrypted from the point of interaction onward.

Choosing the right SAQ matters — each one maps to a different set of compliance requirements based on how payment card data actually flows through your business, and selecting the wrong one can leave real gaps in your security posture even if the paperwork is technically filed.

How to Become PCI DSS Compliant

PCI DSS is built around six control objectives that every compliant organization needs to meet:

1. Build and maintain a secure network and systems

2. Protect cardholder data

3. Maintain a vulnerability management program

4. Implement strong access control measures

5. Regularly monitor and test networks

6. Maintain an information security policy

These six objectives haven't changed in principle under PCI DSS 4.0 — what's changed is the depth and rigor expected within each one. "Strong access control," for instance, now explicitly means multi-factor authentication across the entire cardholder data environment, not just for remote or administrative access. "Regular monitoring" now extends to payment page script integrity and tamper detection, addressing the e-skimming attacks that have become far more common since 3.2.1 was written. And "maintain an information security policy" increasingly means being able to produce a documented, defensible targeted risk analysis — not just a policy binder that gets updated once a year.

For acquirers and MMS (Merchant Management System) providers, these same six objectives have to be met — and validated — across an entire merchant portfolio, not a single environment. If that's the position you're in, our detailed breakdown in Navigating PCI DSS 4.0 Compliance as an Acquirer or MMS Provider covers the specific operational and scoping challenges that come with managing compliance at that scale.

The Penalties of Non-Compliance

Cardholder data is treated as sensitive personal data, which means a PCI DSS breach carries consequences on par with a serious data protection violation elsewhere in the world — think GDPR-level scrutiny, applied specifically to payment data. Non-compliant organizations face real financial and operational risk:

• Fines levied by card networks, passed through the acquiring bank, which can escalate the longer non-compliance continues

• Increased transaction costs, as some acquirers apply higher processing rates to merchants who can't demonstrate compliance

• Suspension or termination of the ability to accept card payments, in cases of serious or repeated non-compliance

• Liability for breach-related costs — forensic investigation, cardholder notification, credit monitoring, and reissuance costs — that can fall on a non-compliant merchant or service provider following an incident

• Reputational damage that often outlasts the direct financial penalty, particularly for merchants whose breach involved customer card data

With PCI DSS 4.0 raising the bar on authentication, e-commerce script monitoring, and continuous evidence of compliance, the gap between "technically registered as compliant" and "actually compliant" has become more visible — and more consequential — than it was under 3.2.1.

The Bottom Line

PCI DSS compliance levels exist to make sure the depth of scrutiny a business faces is proportionate to the risk it carries — the more transactions you process, the more rigorously you need to prove your controls hold up. What's changed under PCI DSS 4.0 isn't the logic of that structure, but the strength of what "proof" actually requires at every level, from a Level 4 merchant filing an SAQ to a Level 1 enterprise sitting through a full QSA assessment. In short, PCI DSS remains what it's always been: a standard built to ensure trust, business continuity, and the safety of cardholder data — just held to a higher, more continuous bar than before.

Subscribe to our newsletter and get the latest fintech news, views, and insights, directly to your inbox. Follow us on LinkedIn and Twitter for insightful fintech tales curated for curious minds like you.

Related Reading

• PCI DSS: The Payment Industry's Armour — the full history of PCI DSS and what's new under version 4.0.

• Navigating PCI DSS 4.0 Compliance as an Acquirer or MMS Provider — a deeper look at what these requirements mean when you're managing compliance across an entire merchant portfolio.