The Payment Card Industry Data Security Standard (PCI DSS) requires any organisation that stores, processes, or transmits cardholder data to validate its compliance. For most merchants — and some service providers — this validation takes the form of a Self-Assessment Questionnaire (SAQ). The SAQ is a structured set of yes-or-no questions corresponding to PCI DSS requirements, designed to let organisations evaluate their own cardholder data environment without engaging an external auditor for a full Report on Compliance (ROC).
Not every organisation fills out the same questionnaire. The PCI Security Standards Council (PCI SSC) publishes multiple SAQ types, each tailored to a specific payment processing model and risk profile. Selecting the correct SAQ type is not optional — it determines which requirements apply to your organisation, how many controls you must implement, and how your compliance is reported to acquiring banks and payment brands. Choosing the wrong type can leave gaps in your security posture or burden your team with requirements that do not apply.
Understanding which SAQ type applies to your organisation requires a clear picture of how cardholder data flows through your systems: where it is captured, how it is transmitted, whether it is stored, and which third parties are involved. This guide explains each SAQ type, who qualifies for it, and how to determine the right one for your business.
Who needs to complete an SAQ?
SAQs are primarily used by Level 2, Level 3, and Level 4 merchants — classifications determined by annual transaction volume. Level 1 merchants, which typically process over six million transactions per year across a single payment brand, are generally required to undergo a full ROC conducted by a Qualified Security Assessor (QSA). The exact thresholds vary by payment brand (Visa, Mastercard, American Express, Discover, and JCB each define their own merchant levels), but the principle is consistent: lower transaction volumes qualify for self-assessment, while higher volumes demand independent audits.
Service providers may also use an SAQ in certain cases. SAQ D for Service Providers is available to eligible service providers with lower transaction volumes, though many are required to complete a full ROC depending on the payment brand’s rules and the acquiring bank’s requirements.
The acquiring bank (sometimes called the merchant bank) is the final authority on which validation method a merchant must use. Even if a merchant’s transaction volume technically qualifies for an SAQ, the acquirer may require a ROC — particularly if the merchant has experienced a data breach, operates in a high-risk industry, or has previously been found non-compliant.
SAQ types explained
Each SAQ type corresponds to a specific payment environment. The PCI SSC defines eligibility criteria for each type, and merchants must meet every criterion to use a particular SAQ. Below is a detailed explanation of each type.
SAQ A
SAQ A is the simplest questionnaire, containing approximately 22 requirements. It is designed for card-not-present merchants (e-commerce or mail/telephone order) that have fully outsourced all cardholder data functions to PCI DSS-validated third-party service providers. The merchant’s systems never store, process, or transmit cardholder data in any form.
A typical SAQ A scenario is an e-commerce merchant that redirects customers entirely to a payment processor’s hosted payment page (such as a Stripe Checkout or PayPal redirect). The merchant’s website never touches card data — the customer enters their details on the processor’s domain, and the merchant receives only a transaction confirmation.
To qualify for SAQ A, the merchant must confirm that all processing of cardholder data is entirely outsourced to validated third parties, the merchant does not electronically store, process, or transmit any cardholder data on its systems or premises, and the merchant has confirmed that all third parties handling cardholder data are PCI DSS compliant.
SAQ A-EP
SAQ A-EP applies to e-commerce merchants that do not directly receive cardholder data but whose website does affect the security of the payment transaction. This is a critical distinction from SAQ A. If your website hosts a payment page that loads a third-party iframe, uses JavaScript from a payment provider to render a payment form, or in any way controls the redirect to the payment processor, you likely fall under SAQ A-EP rather than SAQ A.
SAQ A-EP contains approximately 191 requirements — a dramatic increase from SAQ A’s 22. The additional requirements address web application security, vulnerability scanning, penetration testing, and other controls necessary because the merchant’s web infrastructure is part of the attack surface, even though cardholder data is handled by a third party.
Common scenarios include merchants using payment provider JavaScript libraries (such as Stripe.js or Braintree’s client SDK) that render payment fields within the merchant’s page via iframes. While the card data technically flows to the payment provider, the merchant’s page controls the user experience and could be compromised to intercept or redirect that data.
SAQ B
SAQ B is designed for merchants that process cardholder data only via imprint machines or standalone, dial-out payment terminals. These devices use a telephone line (not an internet connection) to communicate with the payment processor. SAQ B contains approximately 41 requirements.
To qualify, the merchant must not process cardholder data via any internet-connected systems. The terminal must be a standalone device — not connected to the merchant’s network or any other systems. This SAQ type is increasingly rare as dial-out terminals are replaced by IP-connected devices, but it remains relevant for some brick-and-mortar merchants.
SAQ B-IP
SAQ B-IP extends the scope of SAQ B to merchants that use standalone, PCI-listed Point-to-Point Encryption (P2PE) payment terminals connected via IP (internet) rather than a telephone line. It contains approximately 82 requirements.
The key distinction from SAQ B is the IP connectivity: because the terminal communicates over the internet, additional network security controls are required. However, because the terminal encrypts cardholder data at the point of interaction and the merchant has no ability to decrypt it, the scope remains limited compared to other SAQ types.
To qualify, the terminals must be on the PCI SSC’s list of validated PTS devices, the merchant must not store cardholder data in electronic format, and the payment terminals must be the only devices in the merchant’s cardholder data environment connected to the internet for payment processing.
SAQ C-VT
SAQ C-VT applies to merchants that process cardholder data manually, one transaction at a time, through a virtual terminal provided by a PCI DSS-validated third-party service provider. A virtual terminal is a web-based application accessed through a browser on the merchant’s device, used to key in payment card details for mail or telephone orders.
This SAQ contains approximately 79 requirements. It is common among small businesses that take orders by phone and manually enter card details into a payment provider’s web-based interface. The merchant’s computer accesses the virtual terminal via the internet, but no cardholder data is stored electronically by the merchant.
To qualify, the merchant must process only through a virtual terminal accessed via a web browser, the virtual terminal must be provided by a validated third-party service provider, the merchant’s computer must not be connected to any other systems within the cardholder data environment, and the merchant must not store cardholder data in electronic format.
SAQ C
SAQ C is for merchants whose payment application systems are connected to the internet but who do not store cardholder data electronically. It contains approximately 160 requirements and covers a broader set of controls than SAQ B-IP or SAQ C-VT because the merchant’s payment systems have internet connectivity.
Typical SAQ C merchants operate point-of-sale (POS) systems connected to the internet for payment processing. The POS system processes transactions in real time but does not retain cardholder data after authorisation. The merchant’s environment is segmented so that the POS system is isolated from other business systems.
SAQ D (Merchant)
SAQ D for Merchants is the most comprehensive self-assessment questionnaire, containing approximately 329 requirements — nearly every requirement in the full PCI DSS standard. It applies to any merchant that does not qualify for any other SAQ type.
Merchants that store cardholder data electronically, process payments through complex multi-channel environments, or have payment systems that do not fit the specific criteria of SAQ A through SAQ C will default to SAQ D. This includes merchants that store cardholder data post-authorisation (even if encrypted), merchants with multiple payment channels that cannot be segmented into simpler SAQ categories, and any merchant whose acquiring bank determines that SAQ D is appropriate.
SAQ D effectively requires the merchant to evaluate itself against the full PCI DSS standard. Organisations completing SAQ D often engage a QSA for guidance, even though QSA involvement is not mandatory for self-assessment.
SAQ D (Service Provider)
SAQ D for Service Providers mirrors the merchant version in scope and applies to service providers eligible for self-assessment. It contains approximately 329 requirements. Service providers are organisations that are not a payment brand but are directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity — for example, hosting providers, managed security service providers, or payment gateway operators.
Eligibility for SAQ D as a service provider depends on transaction volume and the requirements of the relevant payment brand. Many service providers exceed the threshold for self-assessment and must complete a full ROC instead.
SAQ P2PE
SAQ P2PE is designed for merchants that use a PCI SSC-listed Point-to-Point Encryption (P2PE) solution and have no other systems or processes that handle unencrypted cardholder data. It contains approximately 33 requirements, making it one of the shortest questionnaires.
P2PE solutions encrypt cardholder data at the point of interaction (the payment terminal) and ensure that no entity in the payment chain other than the solution provider has access to decryption keys. Because the encryption is managed end-to-end by a validated solution, the merchant’s scope is dramatically reduced.
To qualify, the merchant must use only a validated, PCI SSC-listed P2PE solution, the merchant must not store, process, or transmit cardholder data outside of the P2PE solution, and the merchant must have confirmed the P2PE solution’s validation status on the PCI SSC website.
Comparison of SAQ types
The following table summarises the key characteristics of each SAQ type. The number of requirements listed is approximate and may vary between PCI DSS versions.
| SAQ Type | Approx. Requirements | Who Qualifies | Typical Use Case |
|---|---|---|---|
| SAQ A | 22 | Card-not-present merchants that fully outsource all cardholder data functions | E-commerce with full redirect to hosted payment page |
| SAQ A-EP | 191 | E-commerce merchants whose website affects payment transaction security | E-commerce using JavaScript-based payment forms or iframes |
| SAQ B | 41 | Merchants using imprint machines or standalone dial-out terminals only | Brick-and-mortar with dial-out card terminals |
| SAQ B-IP | 82 | Merchants using standalone IP-connected PTS-approved terminals | Retail with IP-connected standalone terminals |
| SAQ C-VT | 79 | Merchants processing one transaction at a time via a virtual terminal | Phone orders keyed into a web-based virtual terminal |
| SAQ C | 160 | Merchants with internet-connected POS systems, no electronic storage | Retail POS connected to the internet, no data retention |
| SAQ D (Merchant) | 329 | Any merchant not qualifying for another SAQ type | Multi-channel merchants, those storing cardholder data |
| SAQ D (Service Provider) | 329 | Eligible service providers processing, storing, or transmitting cardholder data | Hosting providers, payment gateways, managed service providers |
| SAQ P2PE | 33 | Merchants using only a PCI SSC-listed P2PE solution | Retail using validated point-to-point encryption terminals |
How to determine your SAQ type
Selecting the correct SAQ type requires a systematic evaluation of your payment environment. The following decision process covers the most common scenarios.
Step 1 — Identify your payment channels
List every way your organisation accepts payment cards. This includes e-commerce websites, mobile applications, point-of-sale terminals, mail order, telephone order, and any recurring billing systems. Each channel may have a different cardholder data flow and may qualify for a different SAQ type — though some organisations consolidate into a single SAQ D if segmentation between channels cannot be demonstrated.
Step 2 — Map the cardholder data flow
For each payment channel, trace the path of cardholder data from the moment a customer presents their card to the point where the transaction is fully processed. Identify every system, application, network segment, and third party that touches, transmits, or stores cardholder data. This mapping is the foundation for determining your scope and your SAQ type.
Step 3 — Evaluate outsourcing and encryption
Determine whether cardholder data is fully outsourced to a validated third party, partially outsourced, or handled internally. If you use a P2PE solution, confirm its validation status on the PCI SSC’s list of validated P2PE solutions. If you use a payment provider’s JavaScript library or iframe, determine whether your website merely redirects to the provider or whether your web infrastructure affects the security of the transaction.
Step 4 — Check for electronic storage
Determine whether any system in your environment stores cardholder data electronically — including primary account numbers (PANs), expiry dates, cardholder names, or service codes — after authorisation. If cardholder data is stored electronically at any point post-authorisation, SAQ D is almost certainly required.
Step 5 — Confirm with your acquiring bank
Once you have identified the SAQ type you believe applies, confirm it with your acquiring bank. The acquirer has the final say on which validation method you must use and may impose additional requirements based on your risk profile, transaction history, or industry.
Common mistakes in SAQ selection
Selecting the wrong SAQ type is one of the most frequent compliance errors in PCI DSS programmes. The following mistakes appear regularly across organisations of all sizes.
Confusing SAQ A with SAQ A-EP
This is the single most common SAQ selection error among e-commerce merchants. Many organisations assume that because they “never see” cardholder data, they qualify for SAQ A. However, if their website hosts the page that contains the payment form — even if the form fields are rendered by a third-party iframe or JavaScript library — SAQ A-EP applies. The test is not whether your server receives cardholder data, but whether your web infrastructure could be compromised in a way that affects the security of the payment transaction.
Overlooking additional payment channels
A merchant that qualifies for SAQ A for its e-commerce channel may also take telephone orders keyed into a virtual terminal (SAQ C-VT) or use POS terminals in a physical shop (SAQ C or SAQ B-IP). If these channels cannot be isolated and assessed separately, the merchant may need to complete SAQ D to cover the full environment.
Assuming P2PE qualification without verification
Not every encryption solution qualifies as P2PE under PCI DSS. The solution must appear on the PCI SSC’s list of validated P2PE solutions. Using a terminal that encrypts data but is not on the validated list does not qualify the merchant for SAQ P2PE. Merchants should verify the solution’s PCI SSC listing number and confirm the listing is current.
Ignoring connected systems
A standalone payment terminal connected to the same network as business workstations, printers, or servers may not qualify as “standalone” for SAQ B or SAQ B-IP purposes. If the terminal shares a network segment with other devices, the scope expands and a different SAQ type may be required. Proper network segmentation is essential to maintaining eligibility for reduced-scope SAQs.
Failing to reassess after changes
Changes to payment infrastructure — such as moving from a fully hosted payment page to a JavaScript-based integration, adding a new sales channel, or migrating terminals from dial-out to IP connectivity — can change the applicable SAQ type. Organisations must reassess their SAQ eligibility whenever the payment environment changes, not only at the annual assessment.
The Attestation of Compliance (AOC)
The Attestation of Compliance (AOC) is a formal document that accompanies every SAQ submission. It serves as the official declaration that the organisation has completed its PCI DSS assessment and records the results. The AOC is typically the document that acquiring banks, payment brands, and business partners request as proof of compliance — not the SAQ itself.
What the AOC contains
The AOC records the organisation’s legal name, business details, and contact information. It identifies the SAQ type completed, the PCI DSS version assessed against, and the date of the assessment. It specifies whether the organisation is fully compliant, compliant with exceptions, or non-compliant. Where a QSA or ISA assisted with the assessment, their details and signature are included alongside the merchant or service provider’s executive signature.
Who signs the AOC
For self-assessments, the AOC is signed by an executive officer of the merchant or service provider — typically a CEO, CFO, CTO, CISO, or another authorised representative. This signature carries legal weight: the signatory attests that the information in the SAQ and AOC is accurate and complete to the best of their knowledge. If a QSA conducted or assisted with the assessment, the QSA also signs the AOC, attesting to the accuracy of the findings.
Why the AOC matters
The AOC is often the only PCI DSS document shared externally. While the full SAQ contains detailed responses to each requirement, many acquiring banks and business partners require only the AOC as evidence of compliance. This makes accuracy in the AOC critical — errors or misrepresentations can result in compliance disputes, fines, or loss of card processing privileges if a breach later reveals that the attested compliance status was inaccurate.
Organisations should retain signed copies of both the SAQ and AOC for a minimum of three years, as acquiring banks and payment brands may request historical assessments during investigations or compliance reviews. Prova GRC can help you manage and track your SAQ and AOC documentation alongside your broader compliance programme, ensuring that deadlines are met and records are maintained in a single auditable platform.