Which PCI DSS SAQ do I need?

What “which SAQ” actually asks

The question collapses three different ones. Kept separate, they resolve cleanly; run together, they produce either an over-scoped questionnaire nobody needed or an under-scoped one that fails at attestation.

1. Your role. Are you a merchant accepting cards for your own goods or services, a service provider handling card data for others, or out of scope? The three do not share a questionnaire.
2. Whether you store cardholder data. Electronic storage of the card number removes eligibility for every reduced SAQ, whatever the channel, so a merchant uses SAQ D (or a Report on Compliance if its level requires one). This overrides everything below it.
3. How you accept cards. If you store none, the channel and technology decide which reduced questionnaire fits: the mapping table below is the core of the answer.

This guide paraphrases the structure of the PCI DSS v4.0.1 Self-Assessment Questionnaires and their eligibility criteria in original wording (identifiers only, no reproduced standard text). It is educational content, not legal advice and not a binding validation determination.

How to decide, step by step

1. 1

   Settle your role before you pick a questionnaire

   “Which SAQ do I need?” is really three questions stacked together, and the first is your role. A merchant accepts payment cards for its own goods or services. A service providerstores, processes, or transmits cardholder data on behalf of other organisations, or can otherwise affect the security of their card payments (a payment gateway, a hosting provider that sits inside the cardholder data environment, a managed-service provider). An organisation that never stores, processes, or transmits cardholder data and cannot affect a payment's security has nothing for PCI DSS to attach to on those facts, though that carve-out is fragile: taking a single card payment or embedding a payment form brings it back into scope. The three roles do not share a questionnaire, so establish yours first. If your organisation is both a merchant and a service provider, assess each role separately.

2. 2

   Check the decisive question: do you store cardholder data?

   Answer this before you look at payment channels, because it overrides them. Cardholder data means the primary account number, alone or together with the cardholder name, expiry date, or service code. If a merchant electronically stores cardholder data, anywhere in its own systems, it does not qualify for any of the reduced questionnaires: a merchant permitted to self-assess then uses SAQ D for Merchants, the full questionnaire, while a merchant whose validation level requires an assessment validates through a Report on Compliance instead. Storage hides in places people forget to look: a database, a spreadsheet, a CRM record, application logs, call recordings, or an inbox, not only an obvious card vault. It does not count where a compliant third party holds the data and you only ever handle a token you cannot use to retrieve the card number, or a properly truncated number, though outsourcing the storage does not remove your responsibility to oversee that provider. This is the single most common reason a business that would otherwise fit a short questionnaire loses eligibility for one, which is why not storing cardholder data is usually the highest-value scope-reduction move available to you.

3. 3

   Map your payment channel and technology to the reduced SAQ

   With no stored cardholder data, the eligible questionnaire follows exactly how you accept cards. Each pattern maps to a different SAQ because it changes which of your systems can touch a card. The mapping table below is the core of the decision. Two practical cautions apply throughout. First, if you accept cards in more than one way (a website and a shop counter, say), there is no single “widest” channel that decides everything: assess each channel against its own eligibility criteria, and you may complete a separate SAQ per channel where the environments are segmented, or one assessment covering every applicable requirement, as agreed with your acquirer. Second, every reduced SAQ depends on storing no cardholder data; if that changes, or any other system in the environment starts to touch card data, you lose eligibility for the reduced questionnaire regardless of channel.

4. 4

   Get the SAQ A vs SAQ A-EP boundary right

   Two errors cluster here. The first is treating any use of a payment provider as SAQ A; the second is assuming that a redirect to the processor forces SAQ A-EP. Neither is right. An ordinary merchant page that redirectsthe shopper's browser to a PCI DSS compliant provider's page can stay SAQ A. SAQ A applies to an e-commerce merchant where every element of the payment page or form reaches the browser only and directlyfrom PCI DSS compliant third parties, your site never receives card data, and your site delivers none of those elements. A redirect to the provider's page, or a provider iframe whose card-capture elements all come from the provider, can qualify where all the SAQ A criteria are met. SAQ A-EP applies where your own website itself creates or deliverspart of the payment page: a merchant-built payment form, a direct-post integration where card data is posted through your page's own mechanism, or scripts your site serves that help create the payment page or transmit card data, while your systems still never directly receive the card data. It is substantially larger because your servers now take part in the payment even though they never store the card number. Under PCI DSS v4.0.1 the SAQ A eligibility criteria added a condition for the embedded (iframe) case: the merchant confirms its site is not susceptible to the relevant script attacks, through suitable protections or confirmation from the compliant provider. That condition does not attach to a plain redirect or payment link. Confirm which pattern you actually run before you assume the smallest questionnaire.

5. 5

   Separate the SAQ from your merchant validation level

   The SAQ is a reporting tool for an environment that meets its eligibility criteria. It does not decide whether you may self-assess at all, or your merchant level, and those are set by someone else. The card brands sort merchants into validation levels by yearly transaction volume, and the top tier typically validates through an annual onsite assessment by a Qualified Security Assessor that produces a Report on Compliance rather than a Self-Assessment Questionnaire. Thresholds and the exact validation method are set by each card brand and your acquiring bank, differ by brand and region, and can move with your transaction volume. The largest-volume merchants and any merchant a brand has designated to its top level are typically in that tier, and a card-data compromise can lead a brand or acquirer to reclassify a merchant or impose additional validation. The key point: your environment decides which SAQ eligibility criteria you meet, while the card brands and your acquirer decide whether you may use that SAQ or must produce a Report on Compliance. Confirm your level and validation type with your acquirer.

6. 6

   Scope per channel, keep the record, and re-check when things change

   Three mechanics keep the answer correct over time. First, scope: the questionnaire can differ per payment channel, so scope your cardholder data environment carefully and assess each channel against its own eligibility criteria, using a separate SAQ per segmented channel or a single assessment covering every applicable requirement, as agreed with your acquirer. Second, record: keep the assessment and its reasoning with your compliance records, even where the result is that PCI DSS does not currently apply, because that conclusion is fragile and you will want to show how you reached it. Third, re-check: the answer is not permanent. Starting to store cardholder data, embedding a payment form, changing how terminals connect, adding a channel, or handling card data for another organisation can each move you to a different, usually larger, questionnaire, and storing cardholder data removes eligibility for every reduced SAQ. Settle any open point with your acquirer or a Qualified Security Assessor, then run the mapping again.

Six mistakes that put you in the wrong questionnaire

• Assuming a payment provider automatically means SAQ A

  Using a compliant third party is necessary but not sufficient for SAQ A. SAQ A needs every payment-page element to reach the shopper only and directly from compliant providers, with your site delivering none of them. Redirecting the shopper to the provider can still be SAQ A. It is SAQ A-EP when your own site creates or delivers part of the payment page (a merchant-built form, a direct-post integration, or scripts your site serves), a much larger questionnaire. The test is whether your site creates or delivers any payment-page element, not merely whether a provider is involved.

• Forgetting that stored card data forces SAQ D

  Electronic storage of the full card number removes eligibility for every reduced questionnaire, whatever your channel. A business that would map to SAQ A or B on its acceptance model still completes SAQ D if it stores cardholder data anywhere, including spreadsheets, logs, or email.

• Confusing the SAQ with the merchant validation level

  The SAQ is a compliance reporting tool for an environment that meets its eligibility criteria, not the authority that decides your applicable requirements. Your merchant level, and whether you self-assess or need a QSA-led Report on Compliance, are set by the card brands and your acquirer by transaction volume and programme. The level never changes which SAQ eligibility criteria your environment meets.

• Treating the PCI SSC as the one who decides

  The PCI SSC publishes the standard and the SAQ eligibility criteria, but validation is enforced through your acquiring bank and the card brands, and the requirements differ by brand and region. Confirm the final questionnaire and validation type with your acquirer.

• Assessing only one channel when you accept cards several ways

  A website plus a shop counter plus phone orders can each map to a different questionnaire. Assess each channel against its own eligibility criteria: complete a separate SAQ per channel where the environments are segmented, or one assessment covering every applicable requirement, as agreed with your acquirer. Do not let one channel silently set the answer for the whole business.

• Treating 'no card data' as permanent

  The out-of-scope conclusion is fragile. Taking one card payment, embedding a payment form, or handling card data for another organisation brings PCI DSS into scope at once, and even a redirect can pull an e-commerce site into SAQ A. Keep the assessment and re-check when arrangements change.

Frequently asked questions