PCI SAQ C cost 2026: 160 controls, and what decides your bill

Where SAQ C sits, in controls

Every count below is published, in the SAQ document itself in the PCI SSC library, under v4.0.1. Counts are approximate and shift slightly with how sub-requirements are counted, so confirm yours in the document. This is the table to reason about, because the number of controls you have to evidence is what any firm quoting you will price against.

Source: the SAQ documents in the PCI SSC document library, v4.0.1. Older figures still circulate from the retired v3.2.1, where SAQ D-Merchant was 329; v4.0 consolidated many sub-requirements, so the current counts are lower.

The SAQ C qualification criteria

SAQ C applies to merchants with a payment application system connected to the internet where the payment system is not isolated from other systems on the network. The typical case is a restaurant or retailer running POS software on a Windows or Linux PC that is also used for software updates, email, staff web browsing, or general office work.

The qualification test is whether the POS environment shares network connectivity with other systems that have unrestricted internet access. If it does, SAQ C applies. If the POS environment is meaningfully isolated, meaning a dedicated segment with restrictive firewall rules and a PC used only for POS functions, SAQ B-IP may apply. If all card acceptance runs through a PCI-validated P2PE solution, SAQ P2PE may apply and the count drops to 33. The formal criteria live in the SAQ Instructions and Guidelines and at the front of the SAQ C document itself.

For merchants on the boundary between SAQ B-IP and SAQ C, confirming which one applies is worth doing deliberately rather than by default, because the difference is 78 controls a year, every year. Your acquirer or your processor's portal can confirm it, and a QSA can give a scoping opinion. If your processor disagrees with your reading, PCI SSC FAQ #1158 covers the route: confirm the payment flow in writing, share architecture diagrams, and escalate through your acquirer.

The route down a tier

For SAQ C merchants the highest-leverage conversation is whether the POS environment can be segmented to qualify for SAQ B-IP. The requirements are specific: the POS system on a dedicated network segment, outbound connections restricted to what it genuinely needs such as the payment processor and the POS vendor's update server, and no general browsing capability. The PC must be used only for POS functions.

Expressed honestly, the prize is 160 controls down to 82. That is the number to weigh the work against, and it is published, so you can check it. What the segmentation itself costs depends on your existing estate: whether your switches already support VLANs, whether you have a firewall that can carry the rules, and whether the configuration work is done in-house or bought. Nobody publishes those prices because they are quoted against your environment, so get the quote and weigh it against 78 controls a year, every year, plus the reduction in what a compromise of your office network could reach.

One thing to price in rather than be surprised by: where segmentation is used to reduce scope, Requirement 11.4.5 asks for a segmentation validation test at least every 12 months for merchants, and after any change to the segmentation controls. That bill arrives because you segmented. The six-month cadence under Requirement 11.4.6 applies to service providers, not merchants, and it is widely misreported, so if a firm quotes you twice a year as a merchant, ask which requirement they are citing.

When SAQ C is the right answer

Sometimes it simply is. A small restaurant where the POS PC is also the manager's email and supplier-ordering machine, where staff run shift scheduling on it, and where the network has no managed switches, is genuinely an SAQ C environment. Attesting to SAQ B-IP because it is cheaper, when the operational reality does not support it, is misclassification, and it surfaces during an acquirer review or a post-incident investigation, which is the worst moment to discover your attestation was inaccurate.

For those merchants SAQ C is the legitimate path, and the useful work is running it efficiently rather than wishing it away. Check what you are already paying for before you buy anything: a PCI programme fee on your monthly processing statement often bundles a compliance portal and an SAQ tool already, and it is charged whether or not you use them. Read the fee schedule on the statement rather than the summary total.

The other route worth evaluating is a PCI-validated P2PE solution, which takes a card-present merchant to SAQ P2PE at 33 controls. It has to be a validated solution from the PCI SSC's list rather than a terminal marketed as encrypted, and that distinction is the entire benefit. For a merchant with several terminals it is the largest single control reduction on the table, and it is worth a quote from your terminal vendor or acquirer.

The questions that make two proposals comparable

• ›Write your scope down once, meaning locations, terminals, network layout, payment channels and external target count, and give the identical brief to two or three firms. Different assumed scopes are why quotes for the same estate differ by a multiple
• ›Ask each firm what is included, and specifically whether remediation and re-testing are inside the fee or billed afterwards. That single answer moves proposals more than any headline number
• ›Ask how many consultant days the fee assumes. A firm that will not say is not comparable to one that will
• ›For scanning, ask whether rescans after a failed scan are unlimited or metered, and whether disputing a false positive is included
• ›Confirm the company signing your ASV report is on the PCI SSC ASV list. Several vendors recommended for PCI scanning are not ASVs
• ›Read your merchant agreement, because your acquirer can require more than the SAQ does, and that is where the requirement will be written