PCI DSS: Working Out Which Self-Assessment Questionnaire Applies
Any business accepting card payments is subject to PCI DSS. For most, compliance is demonstrated through a Self-Assessment Questionnaire, and which SAQ applies makes an enormous difference — the simplest has a few dozen requirements, the most complex has hundreds.
The deciding factor is not your size or your transaction volume. It is how card data moves through your environment, and specifically whether it touches your systems at all.
The SAQ types
SAQ A — Card-not-present only, with all payment processing fully outsourced to a validated third party. Your website redirects to the processor, or embeds an iframe you do not control the contents of. You never see, transmit or store card data.
The lightest by a wide margin, and the one to aim for.
SAQ A-EP — E-commerce where your site does not receive card data but does affect how it is captured. The classic case: a JavaScript-based payment form hosted on your page, where your site delivers the script that collects the card.
This catches people out constantly. Many businesses believe they are SAQ A because "the processor handles it", when their integration actually places them in A-EP — which has many times the requirements, including external vulnerability scanning.
SAQ B — Standalone, dial-out payment terminals. No electronic card data storage.
SAQ B-IP — Standalone terminals connected by IP. More requirements than B, because the terminal is on your network.
SAQ C-VT — Virtual terminal: staff manually key transactions into a web-based form on an isolated computer, one transaction at a time.
SAQ C — Payment application systems connected to the internet, with no electronic cardholder data storage.
SAQ P2PE — Point-to-point encryption terminals using a validated P2PE solution. Very short, but only if the solution is on the validated list — "it encrypts" is not the same thing.
SAQ D — Everything else, including any merchant who stores cardholder data. The full set.
How to work out which one you are
The honest answer requires a cardholder data flow diagram: every point where card data enters, moves, is processed, and leaves. Most businesses have never drawn one, which is why so many assume the wrong SAQ.
Ask, for every channel you accept payment through:
- Does card data ever reach a system we control, even momentarily?
- Does our website serve any code involved in capturing the card?
- Do staff ever handle card numbers — on the phone, on paper, in email?
- Is card data stored anywhere, including call recordings, screenshots or email?
- Are terminals on our general network, or isolated?
Phone payments are the most common trap. If staff take card numbers over the phone, those numbers are in your environment. If calls are recorded, they are in your recordings. That alone can move you from a light SAQ to a heavy one — and recordings containing card data are stored cardholder data, which lands you in SAQ D.
The usual fix is pause-and-resume recording around payment capture, or routing payments to an automated IVR so staff never hear the number.
Reducing scope is the real work
Compliance effort scales with how much of your environment touches card data. The highest-value activity is almost always removing systems from scope rather than securing more of them.
Move to a redirect or hosted payment page. The difference between SAQ A-EP and SAQ A is often a change to how your checkout embeds the payment form.
Use validated P2PE terminals. Encryption at the point of swipe or tap means the data is unreadable in your environment.
Stop storing card data. There is almost never a good reason. Use processor tokens for recurring billing instead of retaining numbers.
Isolate payment terminals on their own network segment.
Eliminate card data from phone calls through IVR payment capture or pause-and-resume.
Purge historical card data. Old systems, spreadsheets, scanned forms and email archives. Each is scope you are carrying for no benefit.
Things people get wrong
"The processor is compliant, so we are." Their compliance covers their systems. Yours covers yours.
"We're small, so it does not apply." Transaction volume affects validation method — self- assessment versus a formal report — not whether the standard applies.
"We did it last year." Validation is annual, and the environment changes. A new website, integration or terminal can change your SAQ.
"Our developer said it's fine." The integration method determines the SAQ. Get it in writing from whoever built it, and check it against the actual page source.
Email and spreadsheets. Card data arriving by email, stored in a spreadsheet "temporarily", or written on a form in a drawer is all in scope, and all avoidable.
A practical sequence
- Draw the cardholder data flow for every acceptance channel.
- Identify every place card data touches your systems or staff.
- Reduce that set — hosted pages, P2PE, tokenisation, IVR payments, isolation.
- Re-draw the flow with those changes.
- Determine the SAQ against the new flow.
- Complete it honestly, and remediate the gaps.
- Schedule scanning where your SAQ requires it.
- Re-check the SAQ whenever the payment path changes.
Step three is where the return is. Businesses that treat PCI as a questionnaire to complete find it painful every year. Businesses that treat it as a reason to get card data out of their environment find it gets easier each time — and they carry much less risk in between.
