SAQ Types Compared: How to Choose the Right Questionnaire

Merchants often default to SAQ-D when a shorter form would apply. Self-Assessment Questionnaires give merchants a structured way to assess PCI DSS compliance without a full QSA-led Report on Compliance. The SAQ must match your card data environment and payment process. Choosing the wrong one means attesting to controls that do not describe your risk surface. That is not compliance, but documentation presenting a false picture of your posture.

Start with SAQ Eligibility Criteria

Before choosing an SAQ, assess eligibility for each type. It depends on your payment method, relationship to cardholder data, and merchant level. Not every SAQ is available to every merchant. The PCI DSS SAQ Instructions and Guidelines from the PCI SSC define these criteria precisely.

Merchant level follows transaction volume. Level 1 merchants, with more than 6 million Visa or Mastercard transactions annually, need a QSA assessment and cannot self-assess. Level 2 merchants, with 1 to 6 million transactions, may use the appropriate SAQ. Levels 3 and 4 are smaller merchants generally eligible for an SAQ matching their environment. An acquiring bank may add requirements beyond card-brand minimums.

SAQ-A: Outsourced Card-Not-Present

SAQ-A is for card-not-present merchants, mainly e-commerce, that outsource all cardholder data handling to a PCI DSS-compliant third party. Their systems never receive, transmit, or store cardholder data. Checkout uses a hosted payment page or iFrame from the payment service provider, with all card entry inside that hosted context.

The key condition is that the merchant website never receives card data. If its application receives a PAN and sends it to a processor, even briefly, SAQ-A does not apply. The business also must not store, process, or transmit cardholder data on paper while operating the e-commerce channel.

Under version 4.0, SAQ-A has 22 requirements. They mainly address third-party service-provider certification, a clear security policy, and physical security for systems connected to the payment flow. It is the shortest SAQ because security responsibility has largely been outsourced to the processor.

SAQ-A-EP: E-Commerce with JavaScript Integration

SAQ-A-EP is for e-commerce merchants using direct post or JavaScript payment integrations. The merchant hosts the payment page, while card entry uses a processor-hosted JavaScript component, such as an embedded hosted payment field.

Unlike SAQ-A, the merchant web server delivers the checkout page. Even when an embedded JavaScript element sends card data directly to the processor, the merchant serves the page containing it. A compromise of that page can compromise payment collection. SAQ-A-EP therefore adds controls for the web application and server hosting the payment page.

SAQ-A-EP also applies when PCI DSS 4.0 Requirement 6.4.3 is relevant. Third-party scripts on the payment page must be inventoried, protected for integrity, and monitored for unauthorized changes. Without the script management required by 6.4.3, a merchant using SAQ-A-EP has a compliance gap visible to an assessor.

SAQ-B: Physical Terminals, No Storage

SAQ-B covers merchants using imprint machines or standalone dial-out terminals. Card data is not sent over a network other than a standalone dial-out connection, and no electronic cardholder data is stored. These are usually small face-to-face merchants whose terminals are not integrated with a wider payment system.

SAQ-B seldom fits merchants with internet-connected payment infrastructure. An IP connection instead of telephone dial-out means SAQ-B does not apply.

SAQ-B-IP: IP Terminals

SAQ-B-IP covers merchants using standalone payment terminals that connect to the processor over an IP network. The terminals have no connection to other systems or internet access in the merchant environment. They connect directly to the processor, and no other merchant systems touch the payment flow.

The terminal must be isolated. It cannot communicate with another system on the merchant network and must transmit only to the processor. Terminals sharing a network with business systems without proper segmentation do not qualify for SAQ-B-IP.

SAQ-C and SAQ-C-VT: Payment Apps and Virtual Terminals

SAQ-C covers merchants whose internet-connected payment application handles authorization, while cardholder data does not flow through or reside on other systems in the environment. One example is internet-connected point-of-sale software with the POS system isolated from other business systems.

SAQ-C-VT covers virtual terminal software on an isolated computer with no cardholder data flow to or from other systems. That computer must be dedicated to virtual terminal access and separated from business systems. A shared workstation does not qualify, even when the virtual terminal runs in another browser tab.

SAQ-D: The Catch-All That Merchants Overuse

SAQ-D applies when no other SAQ accurately describes the cardholder data environment. It covers the full PCI DSS scope for the assessment type and includes more than 200 requirement sub-items under version 4.0.

Merchants overuse SAQ-D because they are unsure whether a shorter form fits, an acquiring bank requires it by default, or they have not scoped the environment well enough to apply shorter-form criteria. The answer is to scope first. Completing SAQ-D without knowing whether a narrower form applies consumes resources and creates a document without the understanding needed to make the assessment meaningful.

Choosing the Right SAQ

Start with how cardholder data enters your environment. Card-not-present, fully outsourced processing with no card data on your servers and no hosted checkout page: SAQ-A is likely. Merchant-hosted checkout delivering processor JavaScript: SAQ-A-EP. Standalone dial-out terminals: SAQ-B. Isolated IP-connected terminals: SAQ-B-IP. An internet-connected payment application with no data flow to other systems: SAQ-C. Everything else, including electronic card data storage: SAQ-D.

When uncertain, a more comprehensive SAQ is safer because it is less likely to leave a gap, not because it is necessarily accurate. The goal is accuracy. An SAQ matching your environment creates documentation that is defensible and meaningful, rather than merely complete.