SAQ B: who qualifies, what it covers, and how to confirm it

If your whole card setup is a terminal on a phone line, or a manual imprint machine and a locked drawer of paper slips, PCI DSS asks far less of you than it asks of a merchant running networked payment software. SAQ B exists for exactly that environment. The two words that decide it: only and dial-out.

Who SAQ B fits

SAQ B is one of the eight PCI DSS Self-Assessment Questionnaires, the validation documents the PCI Security Standards Council (PCI SSC) publishes for merchants that qualify to self-assess. Completing one ends in a signed Attestation of Compliance (AOC) that goes to your acquiring bank or the card brands. SAQ B is the version written for the smallest of card setups: paper imprints and standalone terminals on telephone lines. It tends to sound like this:

• “The terminal plugs into the phone jack.” A plumbing company runs cards on a countertop terminal that dials the processor, prints a slip, and does nothing else. No POS software, no online checkout.
• “Internet’s not reliable out here.” A rural feed store kept its dial-out terminal because the phone line always works. Card data never touches a computer the store owns.
• “We still use the imprint machine at events.” A community club runs a manual imprint machine at seasonal fairs and deposits the paper slips with the bank.
• “Two terminals, both dial-out. That’s the system.” A tailor with a pair of standalone dial-out terminals and a paper receipt book, and nothing else that ever sees a card number.

The common thread: cardholder data moves from the customer’s card to a standalone device to the processor over a telephone line, or onto a paper imprint. It never enters your computers, your network, or a website you run. That is precisely the environment SAQ B was written for, and it’s why the questionnaire can stay short. If none of these sound like you, the guide to all 8 SAQ types maps every acceptance pattern to its questionnaire.

The exact eligibility criteria

Per the PCI SSC’s SAQ Instructions and Guidelines for PCI DSS v4.0, SAQ B is for merchants that use only imprint machines or standalone dial-out terminals, with no electronic storage of cardholder data. It’s a short sentence, and every word in it is doing work:

• Only. The claim covers every way you accept cards, across every location. One website checkout or hand-keyed virtual-terminal payment running alongside the terminals, and your environment is bigger than SAQ B.
• Imprint machines. Manual devices that press the card’s embossed digits onto a paper slip. No electronics, no transmission. The slip goes to the bank.
• Standalone. The terminal is not connected to any other system you run: no POS integration, no inventory software, no back-office link. It talks to the processor and to nothing else.
• Dial-out. The terminal reaches the processor over a telephone line, not over the internet or your local network. This single detail is the entire boundary between SAQ B and SAQ B-IP.
• No electronic storage of cardholder data. No database, no spreadsheet, no scanned slips in a shared folder, no card numbers sitting in emails or call recordings. Paper is expected in a SAQ B environment and must be protected, but paper is not electronic storage.

The SAQ B document itself opens with an eligibility checklist you attest to, item by item. If any item doesn’t describe your setup, the right move is to find the SAQ that does, not to stretch this one, because your signature on the Attestation of Compliance says the checklist is true.

What disqualifies you: the adjacent-SAQ traps

Most wrong SAQ B submissions aren’t dishonesty. They’re a setup that changed, or a boundary nobody flagged. Four things to check before you attest:

Your terminal connects over the internet: that’s SAQ B-IP

The boundary between SAQ B and SAQ B-IP is the connection type, nothing more. Dial-out means the transaction travels over a telephone line. If your terminal reaches the processor through your router, an Ethernet cable, or Wi-Fi, it has an IP connection, and SAQ B-IP is the questionnaire written for standalone, PTS-approved terminals with an IP connection to the processor. Same standalone idea, different transport, and the questionnaire adds network-facing content to match. The practical tell: if you swapped the old phone-line terminal for one that uses your internet connection, your SAQ changed with it.

The terminal is wired into anything else: not standalone anymore

A terminal integrated with POS software, a till system, or anything else in your environment is no longer standalone, and neither SAQ B nor SAQ B-IP describes it. Payment-application systems connected to the internet point to SAQ C, and environments that fit no reduced SAQ land in SAQ D.

You take cards any other way

The word only fails quietly. A checkout page on your website points to SAQ A or SAQ A-EP. Staff keying phone orders into a processor-hosted page points to SAQ C-VT. If you accept cards through more than one channel, your validation can span more than one SAQ, and your acquiring bank tells you how to submit the whole picture.

Anything stores card data electronically: the SAQ D override

This one overrides everything else on the page. If any system you control stores cardholder data electronically, a database, a spreadsheet, an app log, a call recording, a scanned imprint slip saved to a drive, the reduced SAQs are off the table and SAQ D generally applies, whatever hardware sits on the counter. The reduced SAQs exist because you hold no electronic card data. Keep it that way and SAQ B stays available.

What you answer, at a high level

Every SAQ draws from the same standard: the 12 PCI DSS requirements, organized under six goals (secure networks and systems, protect account data, vulnerability management, access control, monitoring and testing, and an information security policy). You’re validating against PCI DSS v4.0: v3.2.1 retired on March 31, 2024, and v4.0’s future-dated requirements became mandatory on March 31, 2025.

A reduced SAQ covers fewer requirements because most of the standard can’t apply to an environment with no network carrying card data. For SAQ B, expect the questions to concentrate on things you can physically point to:

• The paper. Where imprint slips and receipts with card data live, who can reach them, how long you keep them, and how they’re destroyed when you’re done.
• The terminals. Where the devices sit, and periodic checks that nobody has tampered with them or swapped one for a lookalike.
• The people. Who is allowed to handle card data, kept to the people whose job needs it.
• The providers. Knowing which third parties (your processor, your terminal supplier) touch cardholder data on your behalf, with responsibilities in writing.
• The policy. A written security policy that matches what your business actually does.

We deliberately don’t quote a question count: the exact set varies by SAQ version, so any specific number you read online deserves suspicion. The honest summary is that SAQ B is among the shortest SAQs because so little of the standard applies to a paper-and-phone-line environment.

How to confirm SAQ B is yours

Eligibility is defined by the PCI SSC, but the confirmation isn’t yours to make alone. Your acquiring bank or the card brands assign your validation level from your annual card volume and confirm which questionnaire they’ll accept. Most small and mid-size merchants validate with an SAQ; the highest-volume merchants go through a QSA-led Report on Compliance instead.

If your setup has a genuinely ambiguous edge, a terminal you can’t identify, a channel you’re not sure counts, a Qualified Security Assessor can rule on it formally. And if you want a defensible starting point before either conversation, our free check asks how you accept cards and computes your likely SAQ on screen in about two minutes, no email needed to see the result. It’s indicative, not a QSA assessment, and it’s built to make the bank conversation shorter.

Frequently asked questions

Related guides