The SAQ is the primary validation mechanism for the majority of organizations in the PCI DSS ecosystem. Choosing the wrong SAQ — one that does not match your actual payment acceptance model — creates compliance risk: you may be attesting to requirements that do not apply while missing requirements that do. The correct SAQ depends entirely on how your organization accepts card payments.
The Nine SAQ Types
| SAQ | Payment Model | Electronic Storage of CHD | Approx. Questions |
|---|---|---|---|
| SAQ A | Card-not-present (e-commerce/MO-TO); all CHD functions fully outsourced to PCI DSS compliant third party | No | ~22 |
| SAQ A-EP | E-commerce only; payment page not entirely hosted by third party; merchant website affects payment data security | No | ~191 |
| SAQ B | Card-present only; use only imprint machines or standalone dial-out terminals (no electronic storage) | No | ~41 |
| SAQ B-IP | Card-present only; use only standalone PTS-approved IP-connected POI terminals | No | ~83 |
| SAQ C | Payment application systems connected to the internet; no electronic CHD storage | No | ~160 |
| SAQ C-VT | Card-not-present only; use web-based virtual terminal provided by third party; isolated computer | No | ~65 |
| SAQ D (Merchant) | All merchants not covered by other SAQ types; or merchants with electronic CHD storage | May apply | ~340 |
| SAQ D (SP) | Service providers eligible to complete a SAQ | May apply | ~340+ |
| SAQ P2PE | Use of a PCI SSC-listed P2PE solution only; no access to cleartext CHD | No | ~35 |
Decision Framework — Which SAQ Applies?
The primary decision factors are: (1) Do you store electronic CHD? → SAQ D. (2) Are you a service provider? → SAQ D-SP. (3) Card-not-present with fully outsourced payment page? → SAQ A (if eligible). (4) E-commerce with partially involved website? → SAQ A-EP. (5) Physical terminals only, no electronic storage? → SAQ B or B-IP based on terminal type. (6) Internet-connected payment applications, no storage? → SAQ C. (7) Virtual terminal only? → SAQ C-VT. (8) Validated P2PE solution? → SAQ P2PE.
| KEY IDEA | SAQ A is often misapplied. To qualify, ALL payment functions must be entirely outsourced to a PCI DSS-compliant third party — including the payment page itself. If your website loads any scripts, frames, or content that could affect the payment page security, you likely do not qualify for SAQ A and should be on SAQ A-EP instead. The v4.0 requirements have made this distinction more consequential. |
SAQ A — The E-Commerce Minimal Scope SAQ
SAQ A is the shortest and most common SAQ for e-commerce merchants who fully outsource payment page hosting. Eligibility requirements: the merchant accepts only card-not-present payments, all payment page functions are hosted by a PCI DSS-compliant third-party PSP, the merchant does not store, process, or transmit CHD, and the merchant has confirmed the PSP is PCI DSS compliant.
| v4.0 added Requirement 12.9.2 to SAQ A — merchants must confirm their PSP is PCI DSS compliant annually and maintain evidence of this confirmation. This is a new administrative requirement that catches many SAQ A merchants off guard. Obtain an AoC (Attestation of Compliance) from your PSP annually and file it as part of your compliance evidence. |
SAQ D — The Full-Scope SAQ
SAQ D covers all requirements across all 12 PCI DSS requirement areas. It applies to merchants who store electronic CHD, merchants whose payment acceptance model does not fit any other SAQ type, and all service providers who complete SAQs. SAQ D has approximately 340 questions and reflects the full depth of PCI DSS v4.0.
| SAQ A vs SAQ D | SAQ A | SAQ D (Merchant) |
|---|---|---|
| Questions | ~22 | ~340 |
| Network requirements | Minimal | Full Requirements 1 & 2 |
| Cryptography requirements | Confirm PSP handles encryption | Full Requirements 3 & 4 |
| Vulnerability management | Minimal | Full Requirements 5, 6, 11 |
| Access control | Minimal | Full Requirements 7, 8 |
| Logging and monitoring | Minimal | Full Requirement 10 |
| Annual effort | Days | Months |
SAQ for Indonesian Payment Organizations
Indonesian payment organizations commonly fall into these SAQ categories:
- Small e-commerce merchants using Midtrans, Xendit, or Doku hosted checkout → SAQ A (if fully hosted)
- E-commerce merchants with custom checkout page or JavaScript → SAQ A-EP
- Fintech platforms with internal payment processing → SAQ D (Merchant)
- Payment gateways and PSPs → SAQ D (Service Provider)
- Physical retail with standalone terminals (no storage) → SAQ B-IP
- Banks with acquiring functions → Full ROC (Level 1 equivalent)
| Misclassification is common for Indonesian e-commerce merchants who believe they qualify for SAQ A because they use a PSP like Midtrans or Xendit. The key question is: does your website load any JavaScript that runs on the page where the customer sees or interacts with the payment form? If yes — even indirectly — you likely do not qualify for SAQ A. We recommend a scoping review before self-selecting an SAQ type. |
Completing and Submitting the SAQ
The SAQ must be completed honestly, with evidence supporting each answer. Common submission requirements: submit to your acquiring bank annually, include passing ASV scan report (for SAQs that require it), retain copies for your own records. The SAQ includes an Attestation of Compliance (AoC) section that must be signed by an executive.