PCI DSS levels decide how a business must prove it complies with the Payment Card Industry Data Security Standard. Your level depends on how many card transactions you handle each year and whether you are a merchant that accepts cards or a service provider that handles card data for others. Every level must meet PCI DSS, but higher levels face stricter validation, such as an on-site assessment by a Qualified Security Assessor (QSA). This guide explains the levels, what each must do, and what PCI means for small businesses, startups and SaaS companies.
Related guides: PCI SAQ: which one do you need? · PCI DSS compliance checklist · PCI DSS scoping mistakes · Best PCI compliance software
Key takeaways
- Card brands such as Visa and Mastercard define the levels. Your acquiring bank (or payment processor) tells you which level you are and how to validate.
- Merchants have four levels, based on annual transactions. Service providers usually have two.
- Level 1 needs a Report on Compliance (ROC), usually by a QSA. Lower levels typically use a Self-Assessment Questionnaire (SAQ).
- PCI DSS v4.0.1 is the current version of the standard.
Who must comply with PCI DSS?
Any organization that stores, processes or transmits cardholder data, or can affect the security of that data, must comply. That includes merchants of every size, payment processors, hosting providers and SaaS platforms that handle card data for customers. Using a payment provider such as a hosted checkout reduces your scope a great deal, but it does not remove your obligation to comply.
PCI DSS merchant levels
The thresholds below follow Visa's widely used definitions. Other brands are similar, though details differ, and any merchant that suffers a breach can be moved to Level 1.
| Level | Annual transactions (per card brand) | Typical validation |
|---|---|---|
| Level 1 | Over 6 million | Annual ROC by a QSA (or qualified internal auditor where allowed), quarterly ASV scans, Attestation of Compliance |
| Level 2 | 1 to 6 million | Annual SAQ, quarterly ASV scans, AOC. Some brands require an ROC or a trained internal assessor |
| Level 3 | 20,000 to 1 million e-commerce | Annual SAQ, quarterly ASV scans where applicable, AOC |
| Level 4 | Fewer than 20,000 e-commerce, or up to 1 million total | Annual SAQ, scans where applicable, as required by the acquirer |
PCI DSS service provider levels
| Level | Annual transactions | Validation |
|---|---|---|
| Service provider Level 1 | Over 300,000 | Annual ROC by a QSA, quarterly ASV scans, AOC |
| Service provider Level 2 | Fewer than 300,000 | Annual SAQ D for service providers, quarterly ASV scans, AOC |
Large customers often ask service providers for a ROC even at Level 2, so check contract requirements.
Key PCI terms
- ROC (Report on Compliance): a detailed assessment report, usually completed by a QSA.
- SAQ (Self-Assessment Questionnaire): a self-assessment for eligible merchants and service providers. There are several types. See which SAQ you need.
- AOC (Attestation of Compliance): a signed declaration of your compliance status, submitted with the ROC or SAQ.
- ASV scan: a quarterly external vulnerability scan by an Approved Scanning Vendor.
- QSA: a Qualified Security Assessor company approved by the PCI Security Standards Council.
PCI compliance for small businesses
Most small businesses are Level 4. To keep PCI simple and affordable:
- Use a PCI-compliant payment provider with hosted payment pages or iframes, so card data never touches your systems.
- Never store card numbers in your own systems, email or spreadsheets.
- Complete the right SAQ each year. Fully outsourced e-commerce merchants often qualify for SAQ A, the shortest.
- Run ASV scans if your SAQ requires them.
- Keep basic security controls in place, such as strong passwords, MFA, updates and secure configuration.
PCI for SaaS and startups
A SaaS company falls into PCI scope in two ways. As a merchant, it charges its own customers by card. Using a payment provider's hosted checkout usually keeps this to SAQ A. As a service provider, it stores, processes or transmits card data for its customers, or could affect its security, for example a platform that embeds payment flows. Then it must validate as a service provider, and customers will ask for its AOC. Design your product so card data goes directly to a compliant processor through tokenization, which keeps your own scope small.
What changed with PCI DSS v4.0 and v4.0.1
PCI DSS v4.0 was published in 2022 and v3.2.1 was retired in March 2024. Requirements that were "future dated" became mandatory on March 31, 2025. Notable changes include broader MFA for access to the cardholder data environment, stronger password rules, targeted risk analyses for flexible requirements, controls to manage and monitor payment page scripts on e-commerce sites, and a new customized approach that lets organizations meet a requirement's objective in their own way. v4.0.1, published in 2024, is a limited revision that clarifies wording and adjusts some requirements without adding new ones.
PCI compliance checklist by level
| Task | Level 1 | Level 2 | Levels 3 and 4 |
|---|---|---|---|
| Confirm level and validation method with acquirer | Yes | Yes | Yes |
| Scope the cardholder data environment | Yes | Yes | Yes |
| Engage a QSA for an on-site assessment | Yes | If required by the brand or acquirer | Rarely |
| Complete the right SAQ | No, ROC instead | Yes | Yes |
| Quarterly ASV scans | Yes | Yes | If the SAQ requires them |
| Penetration testing | Yes | If the SAQ requires it | If the SAQ requires it |
| Sign and submit the AOC | Yes | Yes | Yes |
| Repeat yearly | Yes | Yes | Yes |
How to reduce your PCI scope
The fewer systems that touch card data, the cheaper and simpler PCI becomes. Use hosted payment pages or iframes from your processor, tokenize card data so your systems only see tokens, segment any systems that must touch card data from the rest of your network, and keep card data out of logs, support tools and email. Scope reduction often moves a merchant from SAQ D to SAQ A, cutting the number of requirements dramatically.
How SecureSlate helps
SecureSlate includes PCI DSS v4.0.1 alongside SOC 2 and ISO 27001, so shared controls are done once. It helps you scope your cardholder data environment, pick the right SAQ, track ASV scans and keep evidence ready for your acquirer or QSA.
FAQ
Who decides my PCI level?
Your acquiring bank or payment processor, based on card brand rules and your annual transaction volume.
Are PCI levels counted across all card brands?
Levels are generally based on transactions for each card brand separately. Your acquirer will confirm how they apply to you.
Do small businesses need to be PCI compliant?
Yes. Every business that accepts card payments must comply. Small merchants usually validate with a short SAQ.
What happens if we are not PCI compliant?
Acquirers can charge non-compliance fees, and after a breach you may face fines from card brands, forensic investigation costs and the loss of the ability to accept cards.
Does using Stripe or another payment provider make us PCI compliant?
It greatly reduces your scope, but you still need to validate compliance, usually with SAQ A, and keep your website and systems secure.
Can a company be both a merchant and a service provider?
Yes. A SaaS platform may accept cards for its own subscriptions as a merchant and also handle card data for customers as a service provider, so it validates both roles.
How long is a PCI AOC valid?
An Attestation of Compliance covers one year. You must revalidate annually and whenever significant changes affect your cardholder data environment.
Do Level 4 merchants need a QSA?
Usually not. Level 4 merchants normally self-assess with an SAQ, though an acquirer can ask for more, especially after a security incident.
Does PCI DSS apply if we only take payments over the phone?
Yes. Phone payments are card-not-present transactions. How staff enter the card details decides which SAQ applies, and call recordings must not store card data.
Is PCI DSS a law?
No. PCI DSS is an industry standard enforced through contracts between card brands, acquirers and merchants. Some laws reference it, and non-compliance can still lead to fees and liability.
Disclaimer (legal note)
This article is for general information only and is not legal, regulatory, or professional advice. Requirements vary by framework, industry, and jurisdiction. Consult qualified advisors for your specific obligations.
Need compliance without the complexity?
SecureSlate automates ISO 27001, SOC 2, GDPR, HIPAA, and more. Built for growing teams. See it in action.
Find compliance gaps in 30 seconds
