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

Once payment software enters your environment, a till application, a tablet checkout, a payment app on a PC, PCI DSS starts caring about the systems it runs on and the network they sit on. SAQ C is the reduced questionnaire for exactly that setup, and it stays available on one condition: nothing you run stores cardholder data electronically.

Who SAQ C fits

SAQ C is one of the eight PCI DSS Self-Assessment Questionnaires published by the PCI Security Standards Council (PCI SSC). Completing one ends in a signed Attestation of Compliance (AOC) that goes to your acquiring bank or the card brands. SAQ C is the version for merchants running payment software, and it tends to sound like this:

• “Checkout runs through our POS software.” A bistro’s till application sends each card transaction to the processor over the restaurant’s internet connection, and nothing keeps the card number afterward.
• “Tablets at the counter.” A bakery takes cards through a payment application on tablets. Orders, totals, and payment run through the app; card data is processed, not stored.
• “One store, one connected register.” A boutique’s payment application runs on the PC at the register, connected to the internet, storing nothing.
• “The old dial terminal became a software checkout.” A shop that moved from a standalone terminal to POS software. The setup got smarter, and the SAQ moved with it.

The common thread: software you operate processes card data on internet-connected systems, and nothing in your environment stores cardholder data electronically. If that’s not quite your picture, 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 C is for merchants with payment-application systems connected to the internet, with no electronic storage of cardholder data. Unpacked:

• Payment-application system. Software that processes payments, running on systems you operate: a till, a tablet, a PC at the register. Card data passes through software and hardware you’re responsible for, which is what separates SAQ C from every fully outsourced path.
• Connected to the internet. The system that processes cards also touches the internet. That combination is what the questionnaire is built around, and it’s why network protections feature in it.
• No electronic storage of cardholder data. The application authorizes transactions and retains nothing: no card numbers in databases, files, or logs, and none anywhere else in your environment either.
• Kept to itself. The SAQ’s eligibility checklist also looks at how the payment system is separated from other systems and locations in your environment. How yours is segmented is a setup-specific question, and exactly the kind of thing to confirm with your acquiring bank or a QSA rather than assume.

As with every SAQ, the document opens with an eligibility checklist you attest to item by item, and your signature on the AOC says the checklist is true. Answer it against how things actually run.

What disqualifies you: the adjacent-SAQ traps

SAQ C borders C-VT on one side, B-IP on the other, and SAQ D underneath everything. Four things to check before you attest:

A person keys everything into a hosted page: that’s SAQ C-VT

The boundary between SAQ C and SAQ C-VT is who does the processing. If your only card processing is someone typing one transaction at a time into an isolated, third-party-hosted virtual terminal, C-VT is the narrower questionnaire written for you. SAQ C assumes software in your environment processes cards; C-VT assumes a person and a browser. If no payment application runs on your systems, don’t take on SAQ C’s extra ground.

Standalone terminals with no software in the path: that’s SAQ B-IP

If cards are taken only on standalone, PTS-approved terminals with an IP connection to the processor, and no payment application touches the transaction, you’re describing SAQ B-IP. The line is hardware versus software: a standalone device talking straight to the processor points to B-IP; a payment-application system points to C. A terminal integrated with your POS software has already left “standalone” behind, which is usually where the SAQ C conversation starts. And if the terminals dial out over a phone line instead, that’s SAQ B.

Your application, or anything else, stores card data: the SAQ D override

This is the override that outranks every reduced SAQ. If the payment application keeps card numbers in a database or writes them into logs, or anyone saves them in a spreadsheet or call recording, SAQ D generally applies. Worth confirming with your software vendor exactly what the application retains before you attest to storing nothing: “we never look at it” and “it isn’t stored” are different claims.

You sell online too

A checkout page on your website points to SAQ A or SAQ A-EP territory, and keyed phone orders point 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.

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.

Because payment software runs on internet-connected systems you operate, expect SAQ C to reach across more of those goals than the standalone-terminal questionnaires do:

• The network. How the payment system connects, how it’s protected from the outside, and how it’s kept separate from everything else you run.
• The systems. Keeping the payment application and the machines beneath it maintained and patched, with vendor defaults gone.
• The software hygiene. Protection against malware and staying on top of vulnerabilities in the systems that touch card data.
• The access. Who can reach the payment system, physically and logically, kept to the people whose job needs it.
• The paper and the devices. Receipts with card data, and physical protection of the equipment that processes cards.
• The policy. A written security policy that matches what your business actually does.

We don’t quote question counts, because the exact set varies by SAQ version. The honest summary: SAQ C asks more than B, B-IP, or C-VT because software and a network are in the card’s path, and it stays well short of SAQ D as long as nothing stores cardholder data.

How to confirm SAQ C 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 an ambiguous edge, a POS integration you’re not sure counts, a vendor whose storage behavior you can’t pin down, 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