What Are SAQs?
Self-Assessment Questionnaires (SAQs)
DefinitionSAQs are validation tools for use by merchants and service providers that are not required by an acquirer or payment brand to submit a full PCI DSS Report on Compliance (ROC). Being "SAQ-eligible" means the entity (1) is permitted to self-assess per payment brand compliance programs, and (2) meets the eligibility criteria for the specific SAQ chosen.
There are multiple SAQ types to match different merchant environments. Organizations must confirm they meet all eligibility criteria before beginning their self-assessment.
What Each SAQ Contains
Three Sections in Every SAQ
| Section | Content |
|---|---|
| Section 1 — Completing the SAQ | Eligibility criteria, completion instructions, expected testing, guidance on Not Applicable requirements, compensating controls, and additional resources |
| Section 2 — PCI DSS Requirements | The applicable PCI DSS requirements for that SAQ's environment, with a place to record responses. Also includes appendices for compensating controls and N/A explanations |
| Section 3 — Attestation of Compliance (AOC) | The entity's declaration of eligibility and attestation to self-assessment results. Includes Assessment Information and Attestation & Validation Details |
Compensating Controls
When Compensating Controls Apply
CCW RequiredCompensating controls may be used when an organization cannot meet a PCI DSS requirement as stated due to legitimate, documented technical or business constraints — but has sufficiently mitigated the associated risk through alternative controls.
- Complete a Compensating Controls Worksheet (CCW) for each requirement met with a compensating control (per PCI DSS Appendix B)
- Document each CCW in the applicable SAQ appendix
- For that requirement, respond with "In Place with CCW" rather than a standard "In Place"
⚠️
SAQ vs ROC — Know the Difference
An SAQ is for merchants/service providers NOT required to submit a full Report on Compliance (ROC). Larger merchants or those specifically required by their acquirer or payment brand to undergo a formal QSA assessment must complete a ROC instead. When in doubt, confirm with your acquirer or payment brand before beginning an SAQ.
All SAQ Types at a Glance
| SAQ | Environment / Use Case | Channel Restrictions |
|---|---|---|
| A | Card-not-present merchants — all account data functions fully outsourced to PCI DSS compliant TPSP. No electronic storage/processing/transmission on merchant systems. | Not face-to-face. Not service providers. |
| A-EP | E-commerce merchants — partially outsourced. Merchant website doesn't receive account data but affects security of payment transaction or integrity of the payment page. | E-commerce only. Not service providers. |
| B | Imprint machines and/or standalone dial-out terminals only. No internet connection on terminals. No other system connections. | Not e-commerce. Not service providers. |
| B-IP | Standalone PCI-listed PTS POI devices with IP connection to processor. Devices isolated from other merchant systems. Excludes SCRs and SCRPs. | Not e-commerce. Not service providers. |
| C-VT | Third-party virtual payment terminal solution accessed via isolated computing device and securely connected web browser. One transaction at a time, manually keyed. | Not e-commerce. Not service providers. |
| C | Payment application system (POS) connected to internet. Not connected to other systems. Single store/location only. | Not e-commerce. Not service providers. |
| P2PE | Only PCI-listed P2PE solution payment terminals. No access to cleartext account data. Must implement P2PE Instruction Manual (PIM) controls. | Not e-commerce. Not service providers. |
| SPoC | COTS mobile device + PTS-approved SCRP as part of PCI-listed SPoC solution. Attended card-present only. COTS device may be general-purpose. | Not unattended, MOTO, or e-commerce. Not service providers. |
| D (Merchants) | All merchants not fitting other SAQ types. Catch-all: merchants with electronic storage, e-commerce accepting account data on own website, etc. | Not service providers. |
| D (Service Providers) | All service providers defined by a payment brand as eligible to self-assess. The only SAQ option for service providers. | Service providers only. |
SAQ Eligibility Deep Dive
SAQ A — Fully Outsourced, Card-Not-Present
CNP / E-comm / MOTO- Accepts only card-not-present (e-commerce or MOTO) transactions
- All processing of account data entirely outsourced to a PCI DSS compliant TPSP
- Merchant does not electronically store, process, or transmit any account data
- Any retained account data is on paper only (not received electronically)
- For e-commerce: all elements of all payment page(s) delivered to the customer's browser originate only and directly from a PCI DSS compliant TPSP
SAQ A-EP — Partially Outsourced E-Commerce
E-commerce only- Accepts only e-commerce transactions
- All account data processing outsourced except the payment page
- Merchant website does not receive account data but controls how customers/data are redirected to the TPSP
- Each element of the payment page may originate from either the merchant's website or a compliant TPSP
- Examples: Direct Post (merchant creates payment form), JavaScript-based payment page delivery
- Note: PCI DSS "cardholder data environment" requirements apply to the merchant website(s) in SAQ A-EP
SAQ B — Imprint / Dial-Out Only
Card-present or MOTO- Uses only imprint machines and/or standalone dial-out terminals (connected via phone line)
- Standalone terminals are not connected to any other systems within merchant environment
- Terminals are not connected to the internet
- No electronic account data storage
SAQ B-IP — Standalone PTS POI with IP Connection
Card-present or MOTO- Uses only standalone, PCI-listed approved PTS POI devices with an IP connection to processor
- Excludes SCR and SCRP device classifications — those are not eligible for SAQ B-IP
- POI devices not connected to any other merchant systems (network segmentation permitted)
- Only permitted account data transmission is from the PTS POI device to the payment processor
- POI device does not rely on any other device (computer, phone, tablet) to connect to processor
SAQ C-VT — Virtual Payment Terminal
Card-present or MOTO- Payment processing only via a third-party virtual payment terminal accessed via web browser
- VPT solution is provided and hosted by a PCI DSS compliant TPSP
- Accessed only from an isolated computing device in a single location not connected to other systems
- Computing device has no software to store account data (no batch/store-and-forward)
- No attached hardware devices that capture or store account data (e.g., no card readers attached)
- One transaction at a time via keyboard — not batch processing
SAQ C — Internet-Connected Payment Application
Card-present or MOTO- Payment application system (e.g., POS) and internet connection on same device and/or LAN
- Payment application system not connected to any other systems (network segmentation required)
- Physical location not connected to other premises — single store only
- No electronic account data storage
SAQ P2PE — PCI-Listed P2PE Solution Terminals Only
Card-present or MOTO- All payment processing via a validated, PCI-listed P2PE solution
- Only systems that store/process/transmit account data are the P2PE solution payment terminals
- No access to cleartext account data on any computer system
- Merchant has implemented all controls in the P2PE Instruction Manual (PIM) provided by the solution provider
- MOTO-eligible: a MOTO merchant receiving card data on paper/phone may key it into a P2PE terminal and still qualify
- A P2PE solution with an expired validation is no longer considered "validated" — check with acquirer
SAQ SPoC — COTS + SCRP in PCI-Listed SPoC Solution
Attended card-present only- All cardholder data entry via a PTS-approved SCRP device as part of a validated PCI-listed SPoC solution
- COTS mobile device (phone/tablet) is general-purpose — doesn't need to be payment-dedicated
- Processes card-present transactions: contact chip, contactless, SCRP-based magnetic stripe
- Not applicable to MOTO, unattended card-present (kiosks), or e-commerce
- Exception: non-PTS MSRs are excluded; PTS-listed SCRPs with MSR functionality are allowed
- Merchant must implement SPoC user guide controls from the SPoC Solution Provider
🧭
Interactive SAQ Selector
Answer each question to find the right SAQ for your environment. This tool follows the official PCI SSC decision tree. Always confirm final selection with your acquirer or payment brand.
SAQ A vs SAQ A-EP
| Attribute | SAQ A — Fully Outsourced | SAQ A-EP — Partially Outsourced |
|---|---|---|
| Channel | E-commerce or MOTO (card-not-present) | E-commerce only |
| Payment Page | All elements originate only and directly from TPSP — merchant has no code on the payment page | Elements originate from merchant website OR compliant TPSP (e.g., Direct Post, JavaScript) |
| Outsourcing Level | All account data functions entirely outsourced | All outsourced except the payment page |
| PCI DSS Scope | Very narrow — TPSP handles everything payment-related | Merchant website is in scope for CDE requirements even though it doesn't receive card data |
| Approx Requirements | 12–30 (varies by e-commerce method) | 139 |
💡
The Key Trigger for SAQ A-EP
If any element of a payment page delivered to the consumer's browser originates from the merchant's website — including scripts, forms, or redirects the merchant controls — SAQ A does not apply. SAQ A-EP applies if payment functions are otherwise outsourced; SAQ D applies if the merchant manages their own payment systems.
SAQ B vs SAQ B-IP
| Attribute | SAQ B — Dial-Out | SAQ B-IP — IP-Connected PTS POI |
|---|---|---|
| Terminal Type | Imprint machines or standalone dial-out terminals | Standalone PTS-approved POI devices (excludes SCRs and SCRPs) |
| Connection | Via phone line to processor; no internet connection | Via IP to processor; isolated from all other merchant system types |
| Internet Access | None — specifically no internet connection | Yes — IP-connected, but only to the processor |
| Device Dependency | Standalone, no other system interaction | POI device must not rely on another device (computer, phone, tablet) to reach processor |
SAQ C-VT vs SAQ C
| Attribute | SAQ C-VT — Virtual Terminal | SAQ C — Payment App / POS |
|---|---|---|
| Payment Method | Manually key data one transaction at a time into a third-party VPT via web browser | Point-of-sale or other payment application system connected to internet |
| Hosting | VPT hosted by PCI DSS compliant TPSP | Merchant hosts/manages own payment application |
| Location | Isolated computing device, single location, not connected to other systems | Single store only; POS not connected to other merchant systems or other premises |
| Batch Processing | Not permitted — single transaction at a time only | Not restricted to single transactions |
SAQ P2PE vs SAQ SPoC
| Attribute | SAQ P2PE | SAQ SPoC |
|---|---|---|
| Hardware | PTS-approved POI device in a PCI-listed P2PE solution | COTS mobile device + PTS-approved SCRP in a PCI-listed SPoC solution |
| Applies To | Card-present OR MOTO merchants | Attended card-present only — NO MOTO, no unattended, no e-commerce |
| COTS Device | N/A — dedicated PTS terminal | General-purpose phone or tablet — does not need to be payment-dedicated |
| Instruction Manual | Must implement P2PE Instruction Manual (PIM) | Must implement SPoC user guide from Solution Provider |
| Magnetic Stripe | Supported through P2PE solution | Non-PTS MSRs excluded; PTS-listed SCRPs with MSR functionality allowed |
What Changed in PCI DSS v4.x SAQs
General Changes Across All SAQs
v3.2.1 → v4.x- Added a "Defining Account Data, Cardholder Data, and Sensitive Authentication Data" table from PCI DSS v4.x
- Added a "Reporting Responses" table explaining what each response means
- Requirements now mirror the wording of PCI DSS v4.x rather than being stated as questions
- Some complex requirements broken into sub-requirements
- Reporting responses aligned with the PCI DSS v4.x ROC Template — "Yes" is now "In Place"
- AOC sections updated to align with ROC AOC language
- Explanations added to some complex requirements to help merchants evaluate them
- New appendices for additional reporting response information
🆕
SAQ SPoC — New in PCI DSS v4.0
SAQ SPoC is a brand-new SAQ type introduced with PCI DSS v4.0. It is designed for card-present merchants using a COTS mobile device (phone or tablet) with a PTS-approved SCRP as part of a PCI SSC-listed SPoC Solution. It significantly reduces applicable PCI DSS requirements for qualifying merchants.
Critical: New Requirements Added to SAQ A for v4.x
⚠️
SAQ A Is Not the Same as It Was in v3.2.1
Merchants should NOT assume that an SAQ they completed for PCI DSS v3.2.1 applies in the same way for v4.x. SAQ A in particular has new requirements addressing e-commerce breaches targeting SAQ A merchants — specifically those using URL redirects or iframes.
Three New Requirements Added to SAQ A
| Requirement | Purpose |
|---|---|
| 6.4.3 | Manage payment page scripts — the merchant must manage any scripts present on their server with a webpage, even if the payment page itself is hosted by a TPSP |
| 11.3.2 / 11.3.2.1 | External vulnerability scans at least every 90 days, and after significant changes — targeting vulnerabilities on the merchant's server with a webpage |
| 11.6.1 | A change and tamper-detection mechanism to detect and alert on unauthorized modifications to security-impacting HTTP headers or script contents of payment pages — must be deployed on merchant servers and alerts must be responded to |
SAQ D for Service Providers — v4.0 Change
Additional Documentation Requirement
For PCI DSS v4.0, SAQ D for Service Providers now requires additional documentation in Section 2a and specifies that service providers must "Describe Results" for each PCI DSS requirement — a more prescriptive evidence burden than in v3.2.1.
E-Commerce SAQ A: Requirement Count by Method
| E-commerce Implementation Method | SAQ Type | PCI DSS v4.x Requirements |
|---|---|---|
| Fully outsourced — merchant has no access to own webpage | SAQ A | 12 |
| Fully outsourced — merchant webpage uses URL redirect to TPSP | SAQ A | 28 |
| Fully outsourced — merchant webpage includes TPSP's embedded iframe | SAQ A | 30 |
| Partially outsourced — Direct Post (merchant creates payment form) | SAQ A-EP | 139 |
| Partially outsourced — merchant delivers JavaScript to consumer browser | SAQ A-EP | 139 |
| All other e-commerce methods | SAQ D | All PCI DSS requirements |
🃏
Tap any card to reveal the answer
32 cards covering SAQ types, eligibility criteria, the hard distinctions between similar SAQs, v4.x changes, and compensating controls.
SAQ
Self-Assessment Questionnaire — a validation tool for PCI DSS compliance used by merchants and service providers not required to submit a full Report on Compliance (ROC). Multiple types exist for different merchant environments.
ROC
Report on Compliance — a full PCI DSS assessment conducted by a QSA. Required for larger merchants and service providers as specified by acquirers or payment brands. SAQs are the alternative for entities not required to do a ROC.
SAQ-Eligible
A merchant or service provider that (1) is permitted to self-assess per payment brand compliance programs and (2) meets all eligibility criteria for the specific SAQ type they intend to complete.
TPSP
Third-Party Service Provider — a PCI DSS validated and compliant company that handles account data functions on behalf of a merchant. Many SAQ types require that the merchant use a compliant TPSP for all or most account data processing.
Compensating Control
An alternative security control used when an organization cannot meet a PCI DSS requirement as stated due to legitimate, documented technical or business constraints. Must be documented in a CCW and submitted as "In Place with CCW."
CCW
Compensating Controls Worksheet — a document required for each PCI DSS requirement met via a compensating control. Must describe the constraint, the risk, the alternative control, and how it mitigates the risk equivalently.
AOC
Attestation of Compliance — the entity's signed declaration included in the SAQ confirming eligibility to complete that SAQ and attesting to the results of the self-assessment. Each SAQ includes an AOC section.
SAQ A
For card-not-present (e-commerce or MOTO) merchants where all account data functions are fully outsourced to a PCI DSS compliant TPSP. All payment page elements for e-commerce must originate directly from the TPSP.
SAQ A-EP
For e-commerce merchants that partially outsource payment processing but whose website affects the security or integrity of the payment transaction. Merchant website doesn't receive card data but does control the payment flow.
SAQ B
For merchants using only imprint machines or standalone dial-out terminals (connected via phone line). No internet connection on terminals. No electronic account data storage.
SAQ B-IP
For merchants using standalone PCI-listed PTS POI devices with an IP connection to the processor. Devices isolated from other merchant systems. Excludes SCR and SCRP device classifications.
SAQ C-VT
For merchants that manually enter payment data one transaction at a time into a third-party virtual payment terminal solution via an isolated computing device and securely connected web browser.
SAQ C
For merchants with a payment application system (e.g., POS) connected to the internet, with no electronic account data storage. Single store/location only. System not connected to other merchant systems.
SAQ P2PE
For merchants using only payment terminals from a validated PCI-listed P2PE solution. No cleartext account data access. Must implement P2PE Instruction Manual (PIM) controls. Applicable to card-present and MOTO.
SAQ SPoC
New in PCI DSS v4.0. For attended card-present merchants using a COTS mobile device and PTS-approved SCRP as part of a PCI-listed SPoC solution. Not applicable to MOTO, unattended, or e-commerce.
SAQ D
The catch-all SAQ. For merchants not fitting any other SAQ type, and the only SAQ available to service providers eligible to self-assess. Covers all PCI DSS requirements.
PIM
P2PE Instruction Manual — a document provided by the P2PE Solution Provider that defines the controls a merchant must implement to maintain scope reduction within the P2PE solution. Required for SAQ P2PE eligibility.
SPoC
Software-based PIN Entry on COTS — a PCI SSC standard for accepting PIN transactions on commercial off-the-shelf mobile devices paired with a PTS-approved SCRP. Merchants using validated SPoC solutions may qualify for SAQ SPoC.
SCRP
Secure Card Reader-PIN — a PTS device classification. Used in SPoC solutions. Merchants using SCRPs are NOT eligible for SAQ B-IP (which requires PTS POI devices but excludes SCRs and SCRPs).
Direct Post
An e-commerce implementation where the merchant website creates the payment form, and payment data is delivered directly from the consumer's browser to the TPSP/payment processor. This triggers SAQ A-EP, not SAQ A.
In Place with CCW
The v4.x reporting response used when a PCI DSS requirement is met via a compensating control. Replaces simply checking "Yes" — requires an accompanying Compensating Controls Worksheet in the SAQ appendix.
Knowledge Test
25 scenario-based questions on SAQ type selection, eligibility criteria, the hard distinctions between similar SAQs, v4.x changes, and compensating controls mechanics.
Arrow Payments · PCI DSS SAQ Instructions & Guidelines v4.0.1 · Internal Use Only