Key Takeaways
- Accuracy is critical. Choosing the wrong SAQ or underreporting scope can lead to compliance gaps and fines.
- SAQs are self-assessment tools required by PCI DSS for merchants and service providers that qualify.
- SAQ A through SAQ D vary by how card data is handled and stored.
- Eligibility matters. The right SAQ is determined by payment channel, technology setup, and whether cardholder data is stored.
- SAQ A is the simplest (outsourced, no card data handling), while SAQ D is the most comprehensive (all others).
- Annual completion is required by most acquiring banks to demonstrate PCI DSS compliance.
SAQ eligibility depends on exactly how you accept payments, how you handle cardholder data, and how your payment systems connect to the rest of your environment. The PCI Security Standards Council defines the SAQ types, but your acquiring bank or payment processor is the one who decides which applies to you. They may work with a third-party vendor to collect your SAQ, but they are the final authority, and they can reject a submission if it doesn’t match their PCI compliance assessment of your environment.
What is a PCI SAQ?
The PCI DSS (Payment Card Industry Data Security Standard) was created to protect cardholder data wherever it’s processed, stored, or transmitted.
Large merchants and service providers often undergo a full on-site PCI DSS assessment by a Qualified Security Assessor (QSA), resulting in a Report on Compliance (ROC). Smaller entities, or those with simpler payment environments, may instead complete a Self Assessment Questionnaire, commonly referred to as an SAQ.
An SAQ is a structured set of yes/no questions mapped to PCI DSS requirements, tailored for specific payment channels and risk levels. It’s intended to reduce the compliance burden for lower-risk environments while still maintaining strong baseline protections.
Full Report on Compliance (ROC) vs. Self-Assessment Questionnaire (SAQ)
Report on Compliance (ROC):
Large merchants or service providers with complex environments undergo a comprehensive on-site audit conducted by a Qualified Security Assessor (QSA), resulting in a ROC.
Self-Assessment Questionnaire (SAQ):
Smaller businesses or those with straightforward payment processes may qualify to self-attest via an SAQ (effectively a PCI compliance assessment in the form of a structured SAQ test).
Why Are There Multiple PCI SAQ Types?
The PCI DSS includes hundreds of requirements. Not every merchant or service provider faces the same risks:
- Simple, small businesses using standalone terminals shouldn’t face the same requirements as large online retailers storing cardholder data in multiple systems.
- Multiple SAQs reduce scope and effort for lower-risk environments while maintaining essential protections.
Key Factors That Determine Your SAQ Type
Understanding these factors is critical for choosing and qualifying for the correct SAQ:
1. How You Accept Card Payments
- E-commerce (Online transactions): Merchants whose websites interact with payment pages face higher risks.
- Face-to-face (Brick-and-mortar): Using standalone payment devices limits PCI DSS scope.
- Mail Order/Telephone Order (MOTO): Payments entered into secure virtual terminals may qualify for specific SAQs.
2. Cardholder Data Environment (CDE)
The cardholder data environment (CDE) encompasses all systems, people, and processes that store, process, transmit, or can impact the security of cardholder data. If cardholder data is stored electronically, you’ll fall under the broadest SAQ, typically SAQ D. If no data is stored and processing is fully outsourced, you may qualify for lighter SAQs.
3. Integrations and System Connections
Any integrations—such as hosting payment forms or connecting your website, network, or apps to your payment flow—can expand your PCI scope. Even outsourced setups might still bring portions of your environment into scope (for example, moving from SAQ A to SAQ A-EP if your website hosts a payment form).
4. Merchant Level
Merchant levels are defined by credit card brands (Visa, Mastercard, AmEx, Discover, JCB) and are based on annual transaction volumes. Higher transaction levels may require an ROC, while lower levels typically qualify for SAQs.
Who Decides Your SAQ Type?
While you can compare your setup to these factors, your acquirer (bank or processor) is the final authority on which SAQ you must complete. They may use third-party vendors to collect your data, but their compliance team sets the requirement.
The Importance of PCI DSS Scope
Scope defines all systems, people, and processes that can affect the security of cardholder data:
- Narrow scope: Fully outsourced payments using validated solutions allow simpler SAQs (A, P2PE, SPoC).
- Expanded scope: Internal systems, integrations, or storing any cardholder data require broader SAQs (C, D).
If any part of your environment can impact transaction security (e.g., web servers, logging systems, shared networks, source code repositories), those assets are in scope.
Reducing PCI DSS Scope
Reducing your cardholder data environment scope makes compliance easier and safer. Strategies include:
- Outsourcing payment processing to PCI-listed providers.
- Using Point-to-Point Encryption (P2PE) or Software-Based PIN Entry on COTS devices (SPoC) devices listed by PCI SSC.
- Network segmentation to isolate payment systems.
- Eliminating any cardholder data storage.
Merchants vs. Service Providers
Before selecting an SAQ, you need to know your role:
- Merchant: Any entity accepting card payments for goods or services, even if using a processor.
- Service Provider: Any entity that processes, stores, transmits, or secures cardholder data for other organizations.
Note: Service providers only use SAQ D (Service Provider). All other SAQs are for merchants.
Do You Store Cardholder Data?
This is a crucial checkpoint:
- Yes: You must use SAQ D (Merchant or Service Provider). No exceptions—even partial or temporary electronic storage counts.
- No: You may be eligible for lighter SAQs, depending on your payment channels and integrations.
Payment Methods and SAQ Eligibility
PCI DSS organizes SAQ eligibility by how you process payments:
| Payment Channel | Possible SAQs |
| Online Merchants | SAQ A, A-EP, D Merchant |
| Face-to-Face Merchants | SAQ B, B-IP, P2PE, SPoC |
| MOTO Merchants | SAQ C-VT, A, D Merchant |
9 Types of SAQs
1. SAQ A
Who it’s for: Merchants that have fully outsourced all cardholder data functions to validated third parties, with no storage, processing, or transmission of cardholder data on their own systems.
Example: An e-commerce boutique using a PCI-compliant payment gateway that redirects customers to a hosted checkout page (e.g., Stripe Checkout, PayPal).
2. SAQ A-EP
Who it’s for: E-commerce merchants outsourcing payment processing but whose website can impact the security of the transaction (e.g., hosting or controlling the payment form).
Example: An online retailer that hosts a payment form on its domain but processes transactions through a third-party gateway.
3. SAQ B
Who it’s for: Merchants using only standalone, dial-out terminals connected via a phone line, with no electronic cardholder data storage.
Example: A small tailor shop with a single countertop card reader connected through a standard landline.
4. SAQ B-IP
Who it’s for: Merchants using standalone IP-connected terminals that connect directly to the payment processor, with no card data storage.
Example: A retail store using Ethernet-connected countertop terminals certified for PCI compliance.
5. SAQ C-VT
Who it’s for: Merchants who manually enter transactions into a virtual terminal provided by a PCI-compliant third party, with no cardholder data storage.
Example: A mail-order company taking phone payments and entering details into a secure online form provided by their processor.
6. SAQ C
Who it’s for: Merchants with payment application systems connected to the Internet but with no cardholder data storage.
Example: A restaurant using an Internet-connected POS to process transactions directly with its acquirer.
7. SAQ P2PE
Who it’s for: Merchants using only PCI-validated Point-to-Point Encryption (P2PE) devices from a listed solution provider, with no card data storage.
Example: A pop-up shop using a mobile P2PE reader certified by the PCI Council.
8. SAQ D for Merchants
Who it’s for: Merchants not eligible for any other SAQ type, typically because they store, process, or transmit cardholder data electronically.
Example: A subscription business storing customer payment data for recurring billing.
9. SAQ D for Service Providers
Who it’s for: Service providers eligible to complete an SAQ instead of undergoing a full ROC.
Example: A payment gateway operator handling cardholder data flows for multiple merchants.
FAQs for SAQs
Q: Can I change my SAQ type mid-year?
Yes, if your payment environment changes (e.g., you add e-commerce), you should update your SAQ type.
Q: Do I need an SAQ if I process under 20,000 transactions?
Likely yes; PCI DSS applies to all entities accepting cards, though your validation method may differ.
Q: Is completing an SAQ the same as being PCI DSS compliant?
Not necessarily. The SAQ is a self-attestation; actual compliance depends on your security controls in practice.
Q: If payment data is encrypted, does it still count?
Yes. Transmission of encrypted cardholder data is still considered “transmitted” and in scope.
Q: After finishing SAQ D, what do I do?
Sign it, store it, and share only if requested. A QSA signature adds credibility but isn’t mandatory unless required by your acquirer.
Q: Who decides if I need a QSA?
Your acquirer decides. If they say self-assess, you don’t need a QSA. If they require one, you do.
Q: What’s an example of unexpected scope creep?
Code repositories, telemetry systems, or logging tools, even if not handling card data directly, can fall into scope if they affect payment
