PCI SAQ types are standardized assessment forms used to validate compliance with the Payment Card Industry Data Security Standard (PCI DSS) for organizations that process, store, or transmit cardholder data. There are five distinct SAQ types-A, B, C, D, and the newer SAQ 3.0-each tailored to specific business models and technical environments.
The PCI Security Standards Council (PCI SSC) created these forms to simplify compliance for diverse merchants and service providers. Each SAQ type defines the scope, controls, and validation steps required based on how card data is handled. Using the correct form ensures accurate assessment and reduces risk of non-compliance penalties.
Each SAQ type maps to a specific environment based on how card data flows through a business. The form includes a checklist of 12 PCI DSS requirements, such as securing networks, protecting stored data, and maintaining access control. Businesses complete the SAQ by confirming whether each requirement is met, supported by evidence like firewall logs, access reports, or configuration files.
For example, SAQ A applies to businesses using only paper-based or manually keyed transactions with no electronic storage of card data. These entities must confirm they do not store, process, or transmit cardholder data electronically. If a business uses a third-party processor and never sees card numbers, SAQ A is appropriate.
SAQs are submitted annually to acquirers or processors. Failure to complete the correct form results in inaccurate validation and potential audit failure. The PCI SSC provides official templates and guidance to ensure consistency across assessments.
There are five primary SAQ types, each designed for a specific processing model. The table below outlines the core differences:
| SAQ Type | Applicable To | Card Data Handling | Example Business |
|---|---|---|---|
| SAQ A | Merchants using only manual entry and no electronic storage | No electronic storage or transmission | Small retail shop with cash-only payments and manual key-in of cards |
| SAQ B | Merchants using dial-up terminals with no card data storage | Card data transmitted via dial-up, not stored | Restaurant with a legacy terminal that sends data over phone lines |
| SAQ C | Merchants with a system connected to the internet but no card data storage | Data transmitted over network, not stored | Online store using a payment gateway without storing card details |
| SAQ D | Merchants with internal systems that store, process, or transmit card data | Full handling of cardholder data | E-commerce platform with a database containing encrypted card numbers |
| SAQ 3.0 | Service providers with limited card data exposure | Minimal card data processing, often automated | Payment processor with secure APIs but no direct access to raw card data |
SAQ A requires no network infrastructure beyond a basic POS terminal. SAQ B covers older dial-up systems still used in some small businesses. SAQ C is common among small online retailers using hosted payment pages. SAQ D applies to larger businesses with internal databases, requiring ongoing monitoring and detailed documentation.
A common mistake is selecting SAQ C for a business that stores card data-even briefly. The PCI SSC warns that storing cardholder data, even in memory during a transaction, disqualifies a business from SAQ C. This error leads to failed assessments and increased audit risk.
Merchants and service providers use PCI SAQ types to demonstrate compliance with PCI DSS to acquirers, processors, and auditors. The form is part of the annual self-assessment process required under PCI DSS v4.0. It's not optional-failure to complete the correct SAQ can result in fines up to $500,000 per incident, according to Visa's merchant compliance policy.
For example, a local coffee shop using a mobile app to accept card payments via a third-party processor must complete SAQ A if the app never stores card data and transactions are manually entered. If the app caches card numbers locally, even temporarily, the business must switch to SAQ D.
Non-compliance isn't just financial. A breach involving unsecured card data can lead to reputational damage and loss of customer trust. In 2022, a small e-commerce site using SAQ C incorrectly was fined $120,000 after a data leak exposed 18,000 card records due to misconfigured server settings.
Many businesses assume SAQ C applies to any online store. That's incorrect. SAQ C only applies to merchants who use a third-party processor and do not store, process, or transmit cardholder data on their own systems. If a business runs its own payment application or stores data in a cloud database, SAQ D is required.
Another misconception is that SAQ A allows any manual entry. But the form specifically excludes businesses that use electronic devices to capture card data-even if they don't store it. For example, a restaurant using a tablet to enter card details into a cloud-based POS system cannot use SAQ A. The device itself creates a risk surface that falls under SAQ D.
I once reviewed a SAQ submission from a boutique that claimed SAQ A because they "only handwrite card details." Upon inspection, their staff used a handheld scanner to read magnetic stripes and send data to a central server. The scanner had a temporary buffer that stored data. This violated the "no electronic storage" rule. The business was reassigned to SAQ D and had to redo the assessment.
Also, SAQ 3.0 is not a replacement for SAQ C-it's a new category for service providers with minimal data exposure. It's not for merchants. Misclassifying it leads to incorrect scope and control mapping.
Understanding PCI SAQ types prevents costly errors. A single misclassified form can trigger a full audit, delay certification, or result in fines. Review your environment annually. Technology changes, so does compliance.