PCI DSS SAQ C for POS systems: who qualifies

Can my POS setup use PCI DSS SAQ C?

SAQ C applies to an in-store point of sale system that is connected to the Internet only when the payment application and the Internet connection sit on the same device or on a single-store LAN, that system is isolated from other merchant systems, and no account data is stored electronically. If any of those conditions fails, SAQ C is the wrong form, whatever the terminal looks like on the counter. The answer depends on how the network is laid out, whether anything in the environment keeps card data, and whether the business runs more than one location on a shared network. The rest of this page works through each of those tests.

Start with a diagram of the actual network, not the one in the original installation document. Confirm which devices share the POS segment, whether a back-office server, a kitchen display, a Wi-Fi guest network or a manager's laptop can reach the register, and where the router or firewall that provides Internet access sits. Then check the data path: look for card data in logs, receipts stored on a file share, exports, or backups that a support vendor pulls from the register. Any electronic storage of account data removes SAQ C from consideration, and encrypted storage does not change that result for this SAQ. Your acquirer can confirm the outcome, but the eligibility decision is yours to document and defend.

The only validation output for this assessment is the SAQ and the Attestation of Compliance that your organization completes and signs, based on the official PCI SSC templates. Your acquirer or payment brand decides whether that validation meets its requirements, and an outside assessor or implementation partner can help prepare systems and evidence, but neither issues the AOC on your behalf. Ask your acquirer which SAQ type it expects for your business before you start, and keep a written record of the network diagram and storage review that supports the choice. If the review shows a second location, a shared network or stored card data, plan for SAQ D from the outset rather than discovering it at submission.

Which eligibility criteria must every POS environment meet for SAQ C?

SAQ C is available only when a set of criteria hold together. Each criterion narrows the environment, and missing one moves the merchant to a different questionnaire, usually SAQ D. Work through the cards in order and confirm each point against your actual network and payment flow.

Payment application and Internet on one device

The payment application system, such as a POS application, must share a device or single-store LAN with the Internet connection. This is the defining feature of SAQ C, so a separate internet gateway serving the terminal or a shared router that also carries other traffic should be mapped and checked. Confirm the connection path on a diagram before you assume the criterion is met.

No connection to other merchant systems

The payment system must not connect to other merchant systems, such as back-office servers, inventory tools or accounting software. Shared file shares, remote management tools or integrations that pass data to another system can break eligibility. Ask your team to list every data path into and out of the POS device, including vendor support access.

Single-store LAN, no other locations

The LAN serving the payment system must be limited to one store and must not connect to other locations. A site-to-site VPN to a head office, a shared network with a sister store or a cloud gateway that bridges locations would make the environment ineligible. For multi-store operators, each location must be assessed on its own terms, and any link between them should be reviewed before choosing SAQ C.

No electronic storage of account data

The merchant must not store cardholder data electronically. This covers logs, spreadsheets, email attachments, screenshots, backups and receipts saved as files. Run a search of POS hard drives, shared folders and support tickets for stray card numbers, because an unexpected copy can change the SAQ. Confirm the answer with your acquirer if storage is unclear.

Encrypted data still counts

Encrypted cardholder data still counts as cardholder data for SAQ eligibility, so encrypting stored card numbers does not keep a merchant on SAQ C. Every SAQ except SAQ D includes an attestation that no cardholder data is stored electronically. A merchant that stores only encrypted cardholder data may therefore need SAQ D, so check whether any encrypted copy exists anywhere in the store.

All criteria hold at once

The four criteria are cumulative. If any one is false, SAQ C does not apply, even if the other three are clearly met. Record the answer to each criterion in writing, with the network diagram and data-flow evidence that supports it, and review the record whenever the POS vendor, network or payment flow changes.

How isolation from other systems keeps a POS on SAQ C

Isolation is what keeps an in-store POS environment on SAQ C. The payment application and its Internet connection must sit on the same device or on a single-store LAN, and that device or LAN must not be connected to other merchant systems. In practice, that means no shared network path from the POS to back-office servers, stock or inventory systems, accounting software, email or any other store or location. If a router, switch, VLAN or wireless access point lets the POS reach those systems, the environment is no longer isolated, and the merchant should expect to be assessed against a broader SAQ. Confirm the actual data paths with a current network diagram that shows every connection into and out of the POS segment, including management interfaces, remote support tools and any Wi-Fi used for handhelds or kiosks.

Administrative access is the part of isolation that teams most often get wrong. PCI SSC FAQ 1442 explains that a merchant may administer a device from another device of the same system type on the same network, a practice described as non-console administrative access, and remain eligible. A different system type is a different matter. Using a back-office server, a general-purpose laptop used for other business tasks or a non-payment system to administer the POS breaks eligibility for SAQ C. Decide who administers each POS, from which device, and over which path, then write that down. Ask your acquirer to confirm in writing whether your administration model fits SAQ C before you rely on it.

Before you complete the SAQ, validate the design rather than assuming it holds. Ask the POS vendor or integrator which remote access tools they use, how updates are delivered and whether any component reaches a shared network. Test the segmentation by attempting connections from the POS segment to back-office addresses and confirm they fail. Keep the diagram, firewall rules and admin access records together as evidence. If you cannot confirm isolation, or if a second store or central system is connected, plan the move to SAQ D early, because the eligibility question will otherwise surface during your acquirer's review.

What PCI DSS v4 added to SAQ C

PCI DSS v4.0.1 is the only active version, and the future-dated requirements are now in force. The additions below cover the technical controls on a POS system and its store LAN, plus the people and response functions that support them. Confirm each item against the current SAQ C document before you map it to your environment.

Malware and phishing protections

SAQ C asks for anti-malware on in-scope systems and mechanisms that detect and block phishing attempts that reach personnel. On a POS terminal sharing an Internet connection with the store LAN, confirm which devices must carry the control and whether it still runs when the terminal is patched or restarted. Keep scan logs, configuration exports and alert records as evidence for the assessor.

Bespoke software controls

Where a merchant or its vendor develops custom payment software, SAQ C expects code review and change control before changes reach the POS application. Ask the software vendor for its review records, release approvals and rollback steps. Store-level changes, such as a local configuration tweak, should pass through the same change record so that the payment application stays in the state the assessor reviewed.

Account and MFA management

The additions tighten how accounts are created, reviewed and removed on the payment system, and they add multi-factor authentication for access paths that lead into the cardholder data environment. For a single-store setup, list every account on the POS device, the store LAN router and any remote support tool, then record who approved each one and when it was last reviewed.

Audit log protection and time sync

SAQ C requires audit logs from in-scope systems to be protected from alteration, reviewed through automated mechanisms, and kept aligned to a common time source. Check whether the POS and router logs leave the device, who can delete them, and whether timestamps match across systems. Without consistent time, an investigator cannot reconstruct a payment-related event in sequence.

Targeted risk analyses

Some v4 requirements let the entity set a frequency or method based on a documented targeted risk analysis. For a SAQ C merchant, this means recording why a control runs at the chosen interval, what threat drives that choice and who signed off on it. Keep the analysis with the SAQ evidence file, and review it when the store adds a new device or connection.

Phishing training and response staff

The additions ask for phishing awareness training for personnel and for incident response arrangements that can act around the clock. A store team needs to know how to report a suspicious email or call, and the merchant needs a named contact or service that responds outside opening hours. Keep training attendance records and the contact procedure in the evidence set, and confirm the response arrangement with your acquirer if it relies on a third party.

When a multi-store or storing environment must move to SAQ D

SAQ C stops being available as soon as any one of its conditions fails. SAQ C covers merchants whose payment application system and Internet connection sit on the same device or single-store LAN, with that system not connected to other merchant systems and no electronic storage of account data. Under the SAQ D for Merchants definition, a merchant that does not meet the criteria for any other SAQ type falls to SAQ D. In practice, four situations trigger the move: several stores that share a network or link their LANs, any electronic storage of cardholder data (encrypted storage included), acceptance of card data on the merchant's own website, and an environment with requirements that go beyond what SAQ C covers. Check each store's network diagram against the SAQ C conditions before assuming a single-store answer still holds.

Encrypted storage counts as storage. Encrypted cardholder data is still cardholder data for SAQ eligibility, and every SAQ except SAQ D includes an attestation that the merchant does not store cardholder data electronically. A POS terminal that writes encrypted receipts, transaction logs or a back-office database therefore moves the merchant to SAQ D even if the data is unreadable. Ask the POS vendor and the store's IT staff to confirm, in writing, whether any component persists card data, including logs, backups and support exports. Ask the acquirer which SAQ or validation level it expects before you change anything.

Moving to SAQ D is a larger job, and it may need a ROC. SAQ D for Merchants contains a broader requirement set than SAQ C, and some requirements can be marked not applicable only when the reason is documented. Expect work on network segmentation between stores, central logging, access reviews and a written scope that covers every location. Confirm with your acquirer whether a Report on Compliance from a Qualified Security Assessor is required for your transaction volume and merchant level, since that decision is made by the payment brands and acquirers, not by the Council. SAQ D for Service Providers is a separate form. A merchant that hosts or manages payment systems for other businesses cannot use SAQ D for Merchants and must use the service provider SAQ instead.

Who owns the SAQ C answer, the controls and the attestation

The merchant owns the payment environment, its controls and the answers it gives on the SAQ. Responsibility sits with the people who run the point-of-sale device, the store network and the business processes around card acceptance. Those people must be able to explain how each SAQ C requirement is met, not only point to a document. The merchant also signs the Attestation of Compliance, which makes it accountable for the accuracy of every answer.

Control ownership: Named owners for POS devices, the store LAN, access accounts, patching and log review, each with a documented duty.
Eligibility confirmation: Internal confirmation that the payment application and Internet connection sit on the same device or single-store LAN, with no link to other merchant systems.
Electronic storage check: Verification that no account data is stored electronically, including in logs, images, spreadsheets or backups.
Attestation signature: An authorized officer signs the SAQ and AOC after the answers have been checked against the evidence.
Ongoing operation: Staff keep controls working between assessments, including device changes, new software and staff turnover.

Before signing, confirm that every owner can show the evidence behind their answers.

How a SAQ C self-assessment runs from scoping to AOC

The sequence turns a single-store POS setup into a documented SAQ C, with eligibility confirmed, isolation tested, each requirement answered on evidence, and an Attestation of Compliance signed and sent to the acquirer. The organization owns every step and every answer, and any outside help prepares evidence without issuing the validation.

Confirm the payment channel and acquirer requirement
Start by confirming that your card acceptance is face-to-face through a payment application on an Internet-connected device or single-store LAN, with no e-commerce, no virtual terminal and no other channel. Ask your acquirer which SAQ it expects and whether it has its own validation or reporting requirements. The output is a short written note naming the channel, the payment application and the acquirer's SAQ requirement, signed off by the merchant owner.
Map the POS network and data flows
Document every device on the POS network, including terminals, the payment application host, the router, the firewall and any Wi-Fi or management connection. Trace where account data enters, whether it is stored electronically at any point, and whether any system outside the store LAN can reach the POS. Your team owns this map, and an implementation partner can help draw it. The output is a current network diagram and data-flow diagram that match what is actually installed.
Test isolation and the eligibility criteria
Verify that the payment system is not connected to other merchant systems and that the store LAN is not connected to other locations. Check that no cardholder data is stored electronically, including in logs, backups, spreadsheets or screenshots, and that the device is used only for the permitted function. Where administration happens from another device, confirm it is the same system type. The output is a documented test record for each criterion, with the result and the person who ran it. Any failure means SAQ C no longer fits, so stop and reassess the SAQ choice.
Perform the Expected Testing for each requirement
Work through each SAQ C requirement and run the Expected Testing listed for it in the SAQ, which describes what must be examined, observed or interviewed to confirm the requirement is met. Pay particular attention to the requirements v4 added, such as malware and phishing protections, change control for bespoke software, account and multi-factor authentication management, audit log protection and time synchronization, targeted risk analyses and incident response staffing. The output is evidence for each item: configuration exports, patch records, training records, policy extracts and screenshots, filed by requirement number.
Record responses and evidence
Enter a response for every requirement in the SAQ, selecting the option that matches the evidence, and complete any appendix that applies, such as the one for compensating controls or a not-applicable explanation. Where a requirement does not apply, record a specific reason tied to your environment rather than a general statement. Keep the evidence index linked to each response so that a reviewer, acquirer or assessor can follow every answer to its source. The output is a completed SAQ with a reviewed evidence index.
Review and sign the Attestation of Compliance
Have someone with authority in the organization review the completed SAQ against the evidence, then sign the Attestation of Compliance that matches the SAQ. The signature confirms the merchant's own statement of compliance, and it does not transfer responsibility to a consultant or assessor. Check that the AOC's merchant details, payment application and acquirer name are accurate before signing. The output is a signed AOC and a retained copy of the SAQ with its evidence.
Submit the SAQ and AOC to the acquirer
Send the signed AOC and the SAQ to your acquirer through the channel it specifies, and confirm in writing that it has received and accepted them. Ask the acquirer how it tracks renewals and whether it requires any further action. Keep the submitted package, the evidence index and the review record together for future audits. The output is the acquirer's written acknowledgment and a stored submission record that matches what was signed.

Which POS setups fail SAQ C without anyone noticing

Most SAQ C failures are not visible at the till. They appear in the network around it: a server that manages the terminal, a shared Wi-Fi network, a dashboard that stores receipts, a support tool with a standing connection, or a second site joined to the same LAN. Each one can quietly move the environment outside SAQ C eligibility.

Back-office server managing the POS

A server that pushes updates, stores sales data or administers the POS software is a second system type sitting on the same LAN. SAQ C assumes the payment application and its Internet connection share one device or a single-store LAN, with no connection to other merchant systems. Check every machine that can reach the POS, including the back-office PC used for reports and inventory. If that server touches the payment application, the self-assessment likely moves to SAQ D. Keep a current network diagram, the list of devices that can reach the POS, and the firewall rules that separate them.

Shared Wi-Fi with store systems

Guest Wi-Fi, staff phones, a digital signage player or a security camera network on the same segment as the POS puts unrelated devices in the payment environment. Many stores add these over time without anyone reviewing the topology. Confirm that the payment network is segmented from every other wireless and wired network, and that guests cannot reach the POS. Keep the segmentation configuration, the wireless network inventory and the test results that show isolation holds. Ask your QSA or acquirer how they expect isolation to be demonstrated.

Cloud dashboards storing receipts

Many POS vendors sync receipts, transaction logs or customer records to a cloud dashboard. If that data includes cardholder data or sensitive authentication data, the merchant is storing account data electronically, which SAQ C does not allow. Even partial data, such as stored card tokens or truncated numbers in exported reports, needs review. Check what the cloud service keeps, where it is held, and whether any stored element falls within PCI DSS cardholder data. Keep the vendor's data flow description and a written confirmation of what is retained.

Vendor remote support tools

A remote access tool that the POS vendor or a field technician uses to connect to the terminal creates an inbound path into the payment environment that is often left running. This is a remote administrative connection that must be controlled, logged and disabled when not in use. Confirm which tool is installed, who holds credentials, whether sessions require multi-factor authentication, and whether the connection stays open between visits. Keep the remote access configuration, session logs and the vendor's statement of how access is granted and revoked.

Second location on the same LAN

A second store, a stockroom office or a seasonal kiosk joined to the same network turns a single-store LAN into a multi-location environment. SAQ C requires that the single-store LAN is not connected to other locations, so a site-to-site VPN, a shared file server or a shared router can change eligibility. This often happens during an expansion or a network refresh. Before connecting any new location, confirm the change with your acquirer and your assessor. Keep the change record, the updated network diagram and a note of the eligibility review.

Questions buyers ask about SAQ C for POS systems

Can a single-store POS merchant use SAQ C?

Yes, if the payment application and the Internet connection sit on the same device or on a single-store LAN, that system is not connected to other merchant systems, the LAN is not connected to other locations, and no account data is stored electronically. Every condition has to hold at once. A payment terminal that links to a back-office server, a second store, or a shared network that reaches other systems usually pushes the merchant out of SAQ C. Confirm the setup with your acquirer before you choose the questionnaire, because the acquirer decides which validation it accepts from you. Read the SAQ C requirements for the full eligibility wording.

Does storing encrypted card data force us into SAQ D?

Usually yes. Encrypted cardholder data still counts as cardholder data for SAQ eligibility, and every SAQ except SAQ D includes an attestation that the merchant does not store cardholder data electronically. A merchant that keeps encrypted card data, even in a log, a receipt file or a back-office database, cannot honestly make that attestation and would normally complete SAQ D for Merchants instead. The fix is often to stop storing the data, which may be a configuration or process change rather than a new control. Check every system that receives transaction records before you decide.

What is the difference between SAQ C and SAQ C-VT?

SAQ C covers an Internet-connected payment application, such as a POS system, that is not connected to other systems. SAQ C-VT covers keying single transactions into an Internet-based virtual terminal supplied by a validated provider, usually from a dedicated computer. The two are not interchangeable. A POS terminal with a card reader and payment software belongs under SAQ C, and it cannot move to SAQ C-VT just because the vendor also offers a web terminal. Neither questionnaire allows electronic storage of cardholder data. Ask your acquirer which channel your business actually uses, because the wrong choice invalidates the attestation.

Can our team complete the SAQ C without outside help?

A merchant can complete an SAQ itself, and the organization, not a consultant, is responsible for the answers and the Attestation of Compliance. The harder part is the evidence. Each requirement needs a documented control, a policy, a record of operation and a clear network diagram, and many merchants lack one of these. Staff who know the store network, the POS vendor's update process and the acquirer's expectations often do most of the work. Outside help is worth considering when the network has changed recently, when the eligibility answers are uncertain, or when no one on the team has reviewed a questionnaire before. Your acquirer may also require a QSA or ISA to sign off, so check that first.

What does outside help cover, and what stays with us?

An implementation partner can help prepare systems, configure network isolation, document data flows, collect evidence and set up logging or patch processes. It does not decide eligibility for the merchant, sign the Attestation of Compliance, or issue validation. Only the merchant's acquirer and an assessor qualified by the PCI SSC, such as a QSA or ISA where the acquirer requires one, can confirm the result. The merchant still owns its controls, its staff training and its ongoing operation after the questionnaire is filed. When you request a quote, ask which deliverables are written into the scope, which evidence the partner will hand over, and what remains your responsibility.

How long does SAQ C work take for a typical network?

The timing depends mainly on how many systems share the store network, how well those systems are documented, and how much of the evidence already exists. A single POS device on an isolated connection with a current vendor update record is far quicker to document than a store with a POS server, a back-office PC, a Wi-Fi guest network and a security camera system. Each additional connected system adds eligibility checks, configuration review and evidence collection. This page does not give a duration because no researched figure was supplied. Ask any provider for a timeline based on a written list of systems and connections, and ask your acquirer for its renewal deadline.

What network changes would move a POS merchant from SAQ C to SAQ D?

Any change that breaks one of the SAQ C conditions can move the merchant to SAQ D. Common triggers include connecting the POS to a second store, linking the payment system to an accounting or inventory server that also reaches other networks, adding an online sales channel that accepts card data on your website, and storing card data electronically in any system. A new device that handles payments on a shared network can also change eligibility. Review the network diagram before each change to the store, and reassess the SAQ at least annually and whenever the environment changes.

How DeployOpen prepares POS isolation and evidence

DeployOpen starts by putting the POS environment scope in writing. Before any hardening, the written scope should name each payment application, the device or single-store LAN it runs on, every path that connects it to the Internet, and every system that could reach it, including back-office servers, remote management tools and any service that pushes software updates. This inventory is what decides whether SAQ C still fits, so it is the first deliverable, and the merchant and its acquirer should agree on it before work continues. DeployOpen does not decide SAQ eligibility on the merchant's behalf.

Once the scope is agreed, DeployOpen hardens and documents the isolation and the administrative paths. In practice this means reviewing the network segment and firewall rules around the payment device, confirming that the payment application has no route to other merchant systems, checking that remote administration uses a same-type device on the same network as the SAQ requires, and recording which accounts, multi-factor methods and audit log settings apply to each device. Where the merchant needs a v4 control such as bespoke software review, change control or log protection, DeployOpen can configure and document it, and the merchant confirms that the control matches its own operating process.

The evidence package is the last step. DeployOpen assembles the configuration records, network and data-flow diagrams, change records and test results that the merchant needs to answer each SAQ C requirement and its Expected Testing, and it flags any answer the evidence does not yet support. DeployOpen does not issue SAQs, Attestations of Compliance or certificates. The merchant completes and signs its own questionnaire, and the acquirer or payment brand decides whether it is accepted. Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope. Ask for the scope document and its exclusions before you compare offers.

PCI DSS SAQ C for internet-connected POS systems