PCI DSS SAQ type checker

Frequently asked questions

Does this tool tell me for certain which SAQ I must complete?

No. It applies the published PCI DSS v4.0.1 SAQ eligibility criteria to your answers and returns the questionnaire your setup maps to, as a structured assessment. The final questionnaire, your merchant level, and whether you self-assess or need an onsite assessment by a Qualified Security Assessor are confirmed by your acquiring bank and the card brands, and can differ by brand and region. Treat this as a fast first pass to scope the conversation, not the decision itself.

What is a PCI DSS Self-Assessment Questionnaire (SAQ)?

An SAQ is a validation tool for merchants and service providers that are eligible to assess their own PCI DSS compliance rather than undergo an onsite assessment. There are several types, each a shorter or longer subset of the full standard, matched to how the entity accepts or handles card data. Completing the right one, and signing the Attestation of Compliance, is how a smaller merchant demonstrates compliance to its acquirer.

Why does storing cardholder data force me onto SAQ D?

Every reduced questionnaire (A, A-EP, B, B-IP, C-VT, C, and P2PE) is built on the assumption that no cardholder data is stored electronically. Once you retain the full card number after authorisation, in a database, spreadsheet, CRM, log, call recording, or anywhere else, that assumption fails and only SAQ D for Merchants, the full questionnaire, covers your environment. Removing stored cardholder data is usually the single most valuable step to shrink both your questionnaire and your cardholder data environment.

What is the difference between SAQ A and SAQ A-EP?

Both are for e-commerce merchants that outsource payment processing and store no card data. In SAQ A the payment is handled entirely by a validated third party (a redirect to the provider's page, or the provider's page embedded in yours) and your website cannot affect the security of the payment page. In SAQ A-EP your website still does not receive card data, but it can affect the security of the payment page, for example by serving or generating part of the payment form, using a direct-post integration, or running scripts on it. That extra exposure makes SAQ A-EP substantially larger. One v4.0.1 point: the newer SAQ A script-protection eligibility criteria apply to e-commerce merchants who embed the provider's payment page or form (for example via an iframe), not to a plain redirect or a payment link.

We use card terminals in a shop. Which SAQ applies?

It depends on the terminals. Standalone dial-out terminals or imprint machines that connect over a phone line, with no electronic storage, map to SAQ B. Standalone approved terminals with an internet (IP) connection map to SAQ B-IP. Terminals that are part of an internet-connected payment application or integrated point-of-sale map to SAQ C. And terminals that are part of a validated PCI point-to-point encryption solution map to SAQ P2PE, which keeps the most systems out of scope. If any system in the shop stores card data, you move to SAQ D regardless.

Does PCI DSS apply if a third party like Stripe or Adyen handles all our card payments?

Usually yes, at the smallest level. Fully outsourcing card handling to a validated third party does not remove PCI DSS; it reduces it. An e-commerce merchant that redirects to, or embeds, a validated provider and stores no card data typically completes SAQ A, the shortest questionnaire, and still has to confirm the outsourcing arrangement; where the provider's page is embedded (for example in an iframe), the v4.0.1 SAQ A criteria add a script-protection expectation for that embedded page. If your own site can affect the security of the payment page (a direct-post integration, or scripts your site serves or controls on it), SAQ A-EP applies instead.

What are merchant levels, and does this tool decide mine?

No, it does not. Merchant levels are set by the card brands by yearly transaction volume, with the largest-volume merchants (and any merchant that has had a card-data breach) in the top level, which typically validates through an onsite assessment producing a Report on Compliance rather than a self-assessment. This tool identifies which SAQ describes your environment, which tells you the control scope, but your level and validation method are confirmed by your acquiring bank and the card brands, and the thresholds differ by brand and region.

We are a SaaS or hosting provider inside our customers' card flows. Are we a merchant or a service provider?

If you store, process, or transmit cardholder data on behalf of your customers, or could affect the security of their card payments, you are a service provider for that activity, even though you also sell your own product. Service providers eligible to self-assess complete SAQ D for Service Providers; larger ones undergo a Report on Compliance. Your customers will usually ask for evidence of your PCI DSS status as part of their own compliance, so settle it with the card brands and the customers whose data you handle.

Is PCI DSS a law?

No. PCI DSS is a security standard maintained by the PCI Security Standards Council and enforced contractually through the card brands and acquiring banks, not a statute. That said, non-compliance carries real consequences, including fines passed down by your acquirer and liability after a breach, and some jurisdictions reference PCI DSS in law or regulation. It also sits alongside actual regulations for many organisations: an EU fintech, for example, may face PCI DSS for card data and DORA for operational resilience at the same time.

By ISMS Copilot. Based on the PCI DSS v4.0.1 Self-Assessment Questionnaires and their eligibility criteria published by the PCI Security Standards Council.