The cost of PCI DSS compliance is driven almost entirely by scope: how much of your environment touches cardholder data. This tool asks a handful of structured questions about how you accept payments and whether you store card data, then returns the Self-Assessment Questionnaire type you most likely qualify for, your merchant level, and practical scope-reduction moves.
How it works
Two factors dominate the result:
- Do your systems ever touch card data? If a fully hosted or redirect payment page keeps cardholder data off your servers entirely, you fall into the lightest questionnaire, SAQ A.
- Channel and integration. Card-present, virtual terminal, direct-post e-commerce, and full storage each map to a different SAQ.
No card data on your systems + hosted/redirect page → SAQ A
E-commerce with embedded/direct-post elements → SAQ A-EP
Card-present, standalone PTS terminal, no storage → SAQ B
Virtual terminal only → SAQ C-VT
You store, process, or transmit card data yourself → SAQ DMerchant level is then read from your annual transaction volume, and Level 1 volumes trigger a full on-site assessment by a Qualified Security Assessor.
Cutting scope
The fastest scope reductions are outsourcing the payment page to a compliant provider (move from SAQ D toward SAQ A), network segmentation to isolate any remaining CDE systems, and never storing the full PAN or any sensitive authentication data after authorisation. Each of these removes systems from the CDE and therefore removes requirements from your SAQ.
SAQ types in plain language
Understanding where each SAQ type applies helps engineering and finance teams communicate clearly about what is actually required.
SAQ A is the goal for most e-commerce merchants. If you redirect to a third-party hosted page — Stripe Checkout, PayPal, or equivalent — and your own servers never see card data, you qualify. The questionnaire has roughly 20 controls, heavily focused on vendor management and account security rather than technical infrastructure.
SAQ A-EP applies when your checkout page loads on your own domain but uses JavaScript from a third party (for example, Stripe Elements or Braintree’s hosted fields). Your page is in scope because a compromise of it could intercept card data, even though the data itself routes elsewhere. This requires additional controls around your website scripts and e-commerce platform.
SAQ B covers merchants who process cards only on standalone payment terminals that dial out directly and have no connection to other systems on your network. Typical for small retail with PTS-listed terminals.
SAQ D is the broadest form and applies to merchants who store, process, or transmit cardholder data on their own systems. It carries the full PCI DSS requirement set — over 280 controls in v4.0 — and is what most organizations are trying to avoid through scope reduction.
PCI DSS v4.0 changes to watch
Version 4.0, mandatory since March 2024, introduced targeted risk analyses for customized controls, new requirements for e-commerce script integrity monitoring (Requirement 6.4.3 — you must authorize and verify every script on your payment page), and stronger phishing protections. If you previously qualified for SAQ A or A-EP, review whether your script inventory and authorization process meets the new standard.