Beginner’s Guide to PCI DSS Compliance Levels (1–4): What They Mean and How to Find Your Level

PCI DSS Compliance Level Definitions

PCI DSS compliance levels categorize merchants by annual transaction volume and risk. The higher your annual transaction volume, the higher your level and the more rigorous your validation obligations. Acquiring bank requirements and card-brand rules can elevate your level based on risk factors such as a prior breach.

Typical thresholds used by the major card brands are: Level 1 for over 6 million transactions per year or any entity designated by a brand; Level 2 for about 1–6 million; Level 3 for roughly 20,000–1 million e‑commerce; and Level 4 for lower volumes. Treat these as guidance—your acquiring bank has the final say for your program enrollment.

Regardless of level, you must meet all applicable PCI DSS requirements. What changes across levels is how you prove it: a Report on Compliance (ROC) by a Qualified Security Assessor for Level 1, or a Self-Assessment Questionnaire (SAQ) and Attestation of Compliance (AOC) for lower levels, often paired with Approved Scanning Vendor (ASV) scans.

Level 1 Compliance Requirements

Level 1 applies to the largest or highest-risk merchants. You validate compliance through an annual on‑site assessment by a Qualified Security Assessor, resulting in a formal Report on Compliance and an Attestation of Compliance filed with your acquirer.

• Annual on‑site QSA assessment producing a ROC and AOC for submission to your acquirer.
• Quarterly external vulnerability scans by an Approved Scanning Vendor, plus internal scans and prompt remediation.
• Annual penetration testing and segmentation testing where segmentation is used to reduce scope.
• Documented security policies, logging and monitoring, strong authentication (including multi‑factor), and robust change and vulnerability management.
• Evidence retention and timely responses to any acquiring bank requirements or card-brand inquiries.

Level 2 Compliance Requirements

Level 2 merchants validate primarily with a Self-Assessment Questionnaire and an Attestation of Compliance. Some acquirers may still require a QSA-led assessment based on their risk evaluation or your proximity to Level 1 volumes.

• Annual SAQ (often SAQ D if you store, process, or transmit cardholder data; other SAQ types may apply based on your architecture) plus AOC.
• Quarterly ASV scans for all internet-facing systems in scope, with remediation of findings.
• Penetration testing, segmentation testing (if used), and ongoing security operations aligned to PCI DSS requirements.
• Submission cadence and any extra artifacts per acquiring bank requirements.

Level 3 Compliance Requirements

Level 3 typically covers mid‑volume e‑commerce merchants. Validation focuses on choosing the correct SAQ for your payment model and demonstrating effective control over web applications and third‑party dependencies.

• Annual SAQ (commonly SAQ A for fully redirected e‑commerce or SAQ A‑EP when your site affects the transaction), plus AOC.
• Quarterly ASV scans for internet-facing assets; additional web application security testing as applicable.
• Third‑party oversight: verify your gateways, payment processors, and content delivery partners provide appropriate AOCs and meet your due‑diligence standards.

Level 4 Compliance Requirements

Level 4 applies to lower‑volume merchants, including many small brick‑and‑mortar and very low‑volume e‑commerce merchants. You still must implement PCI DSS controls; the difference is in how you attest to them.

• Annual SAQ using the type that matches your environment (for example, SAQ A, B, B‑IP, C‑VT, P2PE, or D), plus the AOC.
• Quarterly ASV scans if you have internet-facing systems; no scans are required for strictly standalone, dial‑out terminals that meet the appropriate SAQ type.
• Emphasis on secure device handling, provider due diligence, and avoiding storage of cardholder data to keep scope minimal.

Determining Your PCI DSS Compliance Level

Start by calculating your annual transaction volume per card brand across all channels. If you accept multiple brands or operate multiple merchant IDs, aggregate volumes appropriately and assume the highest level applies unless your acquirer advises otherwise.

Map your payment flows to the correct SAQ type by identifying where cardholder data is stored, processed, or transmitted. If you fully outsource processing and only serve hosted payment pages, your SAQ type may differ from a merchant that touches card data directly.

Confirm your preliminary level and validation method with your acquirer. They set program deadlines, required documents (ROC vs. SAQ/AOC), and any additional evidence. If you have a history of compromise or rapid growth, expect elevated oversight regardless of current volumes.

Document your scope, controls, ASV scan cadence, and testing plan. Reevaluate after major changes—such as adding a new gateway, enabling in‑app payments, or crossing a volume threshold—to ensure your level and validation artifacts remain accurate.

Additional Compliance Considerations

Merchants vs. service providers

If you store, process, or transmit cardholder data for other businesses, you may be a service provider with different validation requirements. Clarify your role early to avoid under‑scoping obligations.

Scope reduction strategies

Tokenization, point‑to‑point encryption (P2PE), and fully hosted payment pages can shrink PCI scope dramatically. The right design can move you to a lighter SAQ, but you must still manage providers and verify their Attestations of Compliance.

Third‑party oversight

Collect current AOCs from processors, gateways, hosting platforms, and content delivery services influencing your payment pages. Build contractual requirements to maintain compliance and notify you of changes that could affect your SAQ type.

Common pitfalls

Counting transactions incorrectly, assuming “small” equals “exempt,” or using the wrong SAQ are frequent mistakes. Align on annual transaction volume early, confirm acquiring bank requirements in writing, and keep evidence organized year‑round.

Conclusion

Your PCI DSS compliance level reflects annual transaction volume and risk, while your validation method (ROC vs. SAQ/AOC plus ASV scans) reflects how you prove compliance. Work with a Qualified Security Assessor and your acquirer to right‑size scope, choose the correct SAQ, and maintain clean, repeatable evidence throughout the year.

FAQs.

What criteria determine PCI DSS compliance levels?

Levels are primarily based on annual transaction volume per card brand, then adjusted by risk factors such as prior compromises or aggregation models. Your acquiring bank can raise or refine your level and specify exactly how you must validate each year.

How do I find out my PCI DSS compliance level?

Gather your prior 12 months of transactions by brand and channel, estimate the next 12 months, and identify the highest applicable tier. Share this with your acquirer, who will confirm your program level and the required validation artifacts (ROC, SAQ, AOC, and any ASV scans).

What are the main differences between PCI DSS compliance levels?

The underlying security standard is the same; the difference is validation rigor. Level 1 typically requires a QSA-led on‑site assessment with a Report on Compliance, while Levels 2–4 usually validate via the appropriate Self‑Assessment Questionnaire, an Attestation of Compliance, and quarterly ASV scans where applicable.

Can acquiring banks impose additional PCI DSS requirements?

Yes. Acquiring bank requirements can mandate QSA involvement for lower levels, accelerate due dates, request extra documentation, or require more frequent testing. Always defer to your acquirer’s instructions even if your volumes suggest a lighter validation path.