PCI DSS SAQ Types Explained: Which Self-Assessment Questionnaire Do You Need?

PCI DSS compliance does not look the same for every merchant. A small e-commerce store using Stripe Checkout has fundamentally different obligations than a hotel chain processing cards through on-premise terminals. The self-assessment questionnaire (SAQ) system exists to match your compliance burden to your actual payment processing model.

The problem is that choosing the wrong SAQ is one of the most common PCI DSS mistakes we see. Merchants regularly select a shorter questionnaire than their architecture requires, leaving them non-compliant without realizing it. Others complete SAQ D when their payment model would qualify for SAQ A, wasting months on requirements that do not apply.

What Is a Self-Assessment Questionnaire?

An SAQ is a validation tool for merchants and service providers who are not required to undergo a full on-site assessment by a Qualified Security Assessor (QSA). Most Level 2, 3, and 4 merchants (those processing fewer than 6 million card transactions annually) can self-assess using the appropriate SAQ rather than engaging a QSA for a Report on Compliance (ROC).

Each SAQ type corresponds to a specific payment processing environment. The type you need depends on how you accept, process, store, and transmit cardholder data. The questionnaires range from 22 requirements (SAQ A) to 326 requirements (SAQ D), and the difference between them is not just paperwork. It determines how much security infrastructure you need to build and maintain.

SAQ Types at a Glance

SAQ A: The Smallest Scope

SAQ A is the simplest questionnaire and the goal for most e-commerce merchants. To qualify, you must meet all of these criteria:

• Your entire payment page is hosted by a PCI DSS-compliant third-party service provider
• You do not electronically store, process, or transmit any cardholder data on your systems or premises
• You have confirmed that all third parties handling cardholder data are PCI DSS compliant
• Your company does not receive cardholder data through any channels (electronic or paper-based, aside from what the third party handles)

The classic SAQ A architecture is a redirect-based checkout. Your customer clicks "Pay," gets redirected to Stripe, PayPal, or a similar provider, completes the transaction on their domain, and returns to your site. Your servers never see the card number.

SAQ A-EP: The E-Commerce Middle Ground

SAQ A-EP exists specifically for e-commerce merchants who partially outsource payment processing but whose website controls elements that could affect the payment transaction. The most common scenario is using a JavaScript-based payment integration where the card form fields are rendered by a third-party SDK on your webpage.

With Stripe Elements, Braintree Drop-in, or similar integrations, the card data goes directly from the customer's browser to the payment processor's servers. Your backend never sees the card number. However, because your website serves the JavaScript that creates the payment form, a compromise of your website (such as a Magecart-style script injection) could capture card data before it reaches the processor.

SAQ A-EP has 191 requirements, nearly nine times more than SAQ A. It includes requirements for vulnerability scanning, secure development practices, change management, and web application security. If you are currently on SAQ A-EP, consider whether migrating to a full redirect-based checkout would qualify you for SAQ A instead.

SAQ B and B-IP: Physical Terminal Merchants

SAQ B applies to merchants using standalone, dial-out payment terminals or manual card imprint machines. These terminals connect via phone line, not IP, and do not store electronic cardholder data. This is increasingly rare as most modern terminals use IP connectivity.

SAQ B-IP covers merchants using standalone, PTS-approved payment terminals that connect via IP but are segmented from other systems on the network. The terminal must be validated as PTS-approved by the PCI Security Standards Council. If your terminal connects to the internet and your network is not properly segmented, you may need SAQ C or SAQ D instead.

SAQ C-VT and SAQ C: Connected Environments

SAQ C-VT is for merchants who manually key in one transaction at a time through a virtual terminal provided by a PCI-compliant third party. The virtual terminal runs in a web browser on a dedicated device that is not used for other purposes. No cardholder data is stored electronically. This is common for small businesses taking phone orders.

SAQ C applies to merchants with payment application systems connected to the internet, such as a POS system running on a networked device. The key distinction from SAQ D is that SAQ C merchants do not store electronic cardholder data after authorization. If your POS system or payment application stores card numbers, even temporarily, you are likely in SAQ D territory.

SAQ D: The Full Assessment

SAQ D applies to any merchant that does not fit into the other SAQ categories, and to all service providers who are eligible for self-assessment. With 326 requirements, SAQ D covers the full PCI DSS standard. You need SAQ D if you:

• Store cardholder data electronically in your environment
• Process or transmit cardholder data through your systems
• Have a payment processing architecture that does not fit any other SAQ type
• Are a service provider handling cardholder data on behalf of other businesses

SAQ D is where the full weight of PCI DSS applies. You need network segmentation, comprehensive logging and monitoring, encryption for data at rest and in transit, vulnerability scanning, penetration testing, and all the access control and authentication requirements in the standard.

Common SAQ Selection Mistakes

These are the SAQ classification errors we encounter most frequently:

• Claiming SAQ A when you embed payment fields. If you use JavaScript-based payment forms (Stripe Elements, Braintree Hosted Fields) embedded in your website via iframe or direct DOM manipulation, you may need SAQ A-EP, not SAQ A. The distinction depends on whether your website serves content that could affect the security of the payment transaction
• Ignoring phone-based payments. If your call center agents enter card numbers into any system, that system is in scope. Many companies focus on their e-commerce checkout but forget that their customer service team is processing cards through a virtual terminal or CRM
• Assuming tokenization eliminates all scope. Tokenization reduces scope by replacing card numbers with non-sensitive tokens, but the point of tokenization (where the real card number first enters your environment) is still in scope. If the card number passes through your server before being tokenized, you are not SAQ A
• Mixing SAQ types across channels. A merchant that qualifies for SAQ A for e-commerce and SAQ B-IP for in-store terminals cannot simply submit two separate SAQs. You need to validate compliance for your entire cardholder data environment, which typically means SAQ D if you have multiple channels with different architectures

How to Reduce Your SAQ Scope

The most effective way to reduce your PCI DSS burden is to change your payment architecture so that cardholder data never touches your systems. Here are the strategies that work:

Move to redirect-based payment pages. Instead of embedding payment forms on your site, redirect customers to your payment processor's hosted checkout page. This is the cleanest path to SAQ A. Stripe Checkout, PayPal Standard, and similar products handle the entire payment page on their infrastructure.

Implement tokenization at the point of entry. For in-person transactions, use point-to-point encryption (P2PE) validated terminals. For e-commerce, ensure card data goes directly from the browser to the payment processor without passing through your servers. For recurring billing, store tokens instead of card numbers.

Segment your network. If you cannot fully outsource, proper network segmentation limits the scope of your cardholder data environment and reduces the number of systems that need to comply with PCI DSS requirements.

Lorikeet Security Team

Penetration Testing & Cybersecurity Consulting

We've completed 170+ security engagements across web apps, APIs, cloud infrastructure, and AI-generated codebases. Everything we publish here comes from patterns we see in real client work.