SAQ C walkthrough: payment application on an internet-connected POS

By Sam Rivera, Founder, SentinelPanda · June 3, 2026 · 3 min read · PCI DSS

SAQ C is for the integrated POS case: a payment application on a system you operate, connected to the internet, no card storage. Heavier than B-IP, lighter than D.

Who SAQ C is for

SAQ C applies to merchants whose business premises use a payment application installed on a POS system connected to the internet, but where cardholder data is not stored electronically after authorisation. Examples: a Square POS app on a tablet integrated with a cash drawer and receipt printer; a hospitality POS that integrates a payment terminal but stores no card data; an in-store ordering app where the customer card payment is routed through the POS.

Critical distinction from SAQ B-IP: the merchant operates a payment APPLICATION on a general-purpose system (or a POS device with admin access), not just a standalone PTS-approved terminal. The application processes card data in memory during the transaction.

The eligibility checklist

• A payment application is in use on a POS system that is connected to the internet.
• Cardholder data is not stored electronically by the merchant after authorisation.
• The payment application is PA-DSS- or PCI-SSF-validated (or otherwise meets the secure-software requirements).
• No e-commerce; the POS environment is the sole acceptance channel.
• The merchant has administrative responsibility for the POS environment.

The requirement subset

SAQ C is mid-sized — typically 130+ control questions. It adds Requirement 5 (anti-malware), Requirement 6 (secure SDLC and patch management), Requirement 10 (logging) at full strength over SAQ B-IP, plus Requirement 8 access control for the POS environment.

Anti-malware on POS systems is a load-bearing control here. Patch management on the POS OS, the payment application, and any integrated middleware needs evidence. Logging of POS admin actions and payment events needs to land in a tamper-resistant log store.

Common SAQ C pitfalls

• POS app that buffers card data to a local log file "for debugging" — silently stores cardholder data and pushes you to SAQ D.
• Using a non-validated payment application — the secure-software validation is the foundation of the whole SAQ.
• Domain admins or shared admin accounts on the POS systems — Req 8 fails.
• Skipping anti-malware because "the POS is locked down" — Req 5 is explicit.
• No logging on the POS systems because they are "appliances" — Req 10 still applies.

A worked example

A coffee shop chain runs a vendor POS app on dedicated tablets at each location. The vendor app is PCI-SSF-validated; cardholder data is not stored; anti-malware runs on the tablets; logs are forwarded to a central log store; the tablets are patched on a managed schedule. Network segmentation isolates the POS tablets from staff WiFi.

The SAQ C walks the Req 5/6/10/11 controls in detail, the Req 8 admin-account controls on the tablets and the central management console, and the Req 12 programme. Total: 6-10 weeks first time, 3-4 weeks revalidation.