PCI DSS Levels and SAQ Types: Which Compliance Path Applies to Your Business?
· Compliance
PCI DSS compliance isn't a one-size-fits-all process. Your obligations are determined by two independent factors: your annual card transaction volume (which sets your "Level") and exactly how your business handles cardholder data (which determines your "SAQ" — Self-Assessment Questionnaire — type). Our previous article covered PCI DSS's TLS requirements; this follow-up breaks down which compliance path applies to which business.
What Are PCI DSS Compliance Levels?
Card brands (Visa, Mastercard, American Express, Discover, JCB) classify merchants into four levels based on annual transaction volume. Thresholds vary slightly by brand, but Visa's widely-referenced figures are:
Level 1: Merchants processing more than 6 million card transactions per year across all channels (e-commerce, POS, phone). Any merchant designated Level 1 by a card brand, or one that has suffered a prior data breach, is automatically placed in this tier regardless of volume.
Level 2: 1 million to 6 million transactions annually.
Level 3: 20,000 to 1 million e-commerce transactions annually.
Level 4: Fewer than 20,000 e-commerce transactions, or up to 1 million transactions through other channels — typically small and mid-sized merchants.
Audit Requirements by Level
Level 1: The heaviest obligation. An annual on-site assessment by a Qualified Security Assessor (QSA) produces a Report on Compliance (RoC). Internal audit is technically allowed if signed by an officer, but most card brands require QSA-led assessment. Additionally, quarterly external vulnerability scans by an Approved Scanning Vendor (ASV) and an annual penetration test are mandatory.
Levels 2–4: An annual Self-Assessment Questionnaire (SAQ) is generally sufficient — QSA assessment isn't mandatory (though some acquiring banks may request one for Level 2). Quarterly ASV scans (if card data touches the internet) and a signed Attestation of Compliance (AOC) are required.
SAQ Types: Determined by How You Handle Card Data
Your SAQ type isn't determined by transaction volume — it's determined by how much cardholder data actually passes through your systems. The PCI Security Standards Council defines nine SAQ types:
SAQ A — The lightest obligation. Cardholder data is fully outsourced to a PCI DSS-validated third party (e.g., a hosted payment page or redirect-based checkout); card data never touches your servers or storage. Roughly 22 questions.
SAQ A-EP — Your payment page is visually hosted on your own site, but card data goes directly to a third party via an iframe or direct-post method. Because your page's integrity is security-critical, this SAQ is far more comprehensive than SAQ A.
SAQ B — For merchants using only standalone, non-internet-connected dial-out POS terminals.
SAQ B-IP — For merchants using only PCI PTS-approved standalone payment terminals connected via IP, with no electronic storage of card data.
SAQ C — For merchants with an internet-connected payment application or POS system that doesn't electronically store card data.
SAQ C-VT — For merchants whose staff manually key in one transaction at a time via a browser-based virtual terminal, with no card data storage.
SAQ P2PE — For merchants using only hardware terminals that are part of a PCI SSC-validated Point-to-Point Encryption (P2PE) solution.
SAQ D (for Merchants) — Any merchant that doesn't fit any other category. The most comprehensive SAQ, covering all 300+ PCI DSS requirements. Applies to merchants who process, store, or transmit card data on their own systems, or use custom payment integrations.
SAQ D (for Service Providers) — For service providers permitted by the card brands to self-assess (most large service providers are still subject to a full QSA assessment).
Which SAQ Type Applies to You?
Ask yourself: Does card data ever touch your servers? Is your payment page fully hosted by a third party, or embedded in your own page? Do you use a physical terminal or sell entirely online? The answers determine your correct SAQ category. Choosing the wrong SAQ type can result in rejection during review and force you to restart the process.
AOC: The Formal Close of the Process
After completing a SAQ or RoC, the merchant signs an Attestation of Compliance (AOC) — a formal declaration that PCI DSS requirements have been met, typically submitted to the acquiring bank.
Where SSL/TLS Fits In
Regardless of your level or SAQ type, one requirement is constant across every category: cardholder data must be transmitted using TLS 1.2 or higher. Even the smallest merchant using SAQ A must maintain a valid SSL certificate on the website that redirects to the payment page — otherwise browsers display a "Not Secure" warning and customer trust evaporates instantly.
Visit the PekiSSL product page to find the right certificate for your needs.