There seems to be a lot of confusion over SAQ C and when it can and should be used. SAQ C was developed for the franchise industry, particularly the fast food and small retailer. The idea was that the franchisee would implement the franchise preferred point of sale (POS) solution, connect that POS solution to the Internet and start processing transactions.
Before going any further I must add the following caveat to this post. While I have based this post on all of the training and discussion over the years with the PCI SSC regarding SAQ C, this post is only my opinion and does not mean I am correct. The only official answer is the one you get from your acquiring bank. It is up to your acquiring bank to determine what SAQ your organization should use for your PCI assessment.
To refresh everyone’s memory about SAQ C, the criteria for using SAQ C are as follows.
-
“Your company has a payment application system and an Internet connection on the same device and/or same local area network (LAN);
-
The payment application system/Internet device is not connected to any other systems within your environment (this can be achieved via network segmentation to isolate payment application system/Internet device from all other systems);
-
The physical location of the POS environment is not connected to other premises or locations, and any LAN is for a single location only;
-
Your company retains only paper reports or paper copies of receipts, and these documents are not received electronically; and
-
Your company does not store cardholder data in electronic format.”
The key to understanding SAQ C are the second and third bullets. The third bullet indicates that the POS application cannot be connected to any other locations. The second bullet indicates that the payment application cannot be connected to any other systems within the organization’s processing environment. The bottom line is that the solution must be stand alone and fully segmented away from any other applications and systems.
These criteria can be easily met by solutions such as the MICROS e7 POS solution but can run afoul of integrated systems such as the MICROS RES or other similar fully integrated solutions that offer accounting, timekeeping, order management, inventory and other applications in addition to POS.
The MICROS RES solution can use SAQ C if and only if the POS application can be logically or physically segmented from the rest of the MICROS RES applications. However, in my experience, the MICROS RES and similar applications must operate as a single, integrated solution and segmentation is not possible and therefore SAQ C cannot be used.
Another place where SAQ C cannot be used is where the franchisee is linking all of their locations together back to a corporate office. I encounter this a lot where the franchisee has multiple locations and all of those locations are on a wide area network (WAN) connected to their corporate office. Transactions may be flowing directly out from the retail locations or funneled back to corporate and then out to the transaction processor. Corporate may also be monitoring the local location networks and managing the local locations’ systems and applications.
I also encounter situations where the franchisee is connected to the franchise corporate office for the ordering of inventory and the collection of sales information. The most common occurrences of this situation is with fast food franchise operations and in the lodging industry where locations are connected to the franchise corporate networks for passing information to/from the local systems. The corporate franchise may also be managing and maintaining the franchisee systems as well as part of the franchise agreement. All of these situations also preclude the use of SAQ C.
The bottom line is that SAQ C can only be used in situations where you have a LAN-based POS and no other applications or network connectivity other than to the Internet for the sole purpose of processing transactions.
So what does a merchant do when SAQ C is not an option? Sorry, but in my humble opinion, the merchant version of SAQ D is your only option when you have an integrated POS solution on a network.
Again, as a final reminder, it really does not matter what I think as all of this is up to your acquiring bank to officially approve. I am just giving my thoughts as to how I think things should work based on my training.
PCI Guru 
A good place to use SAQ-C is for enterprise call centers. Semafone provides a server-based, on-premises PCI descoping solution for call centers that helps merchants reduce 327+ SAQ-D controls down to SAQ-C. Of the 138 SAQ-C controls, Semafone provides roles & responsibilities documents in which we maintain & monitor ~ 70 of the controls (~50%) for our customers, further reducing payment card scope. We have worked with many different QSAs that have validated & certified this descoping capability (although they are helping their clients to complete RoCs). We are fully validated as a PA-DSS provider by PCI and provide these certificates to our customers. Please let me know if anyone would like further information … We work with huge enterprise call centers – some of the largest companies in the world! :>)
Brilliant article as ever! thanks a lot.
Just one question – can we have multiple POS on a LAN in one location?
That was the whole point of SAQ C was to give SMBs a LAN-based POS solution. Just one that is not integrated with anything else.
Great, many thanks. Its just this statement that confuses me in saq c,
The payment application systems/ internet device are not connected to any other systems within your environment.
And below in saq c vt,
Merchant accesses the virtual terminal via a computer that is isolated in a single location, and is not connected to other locations or systems within your environment
Are we saying that our integrated pos or virtual terminals (regardless of their numbers) can be all in a LAN connected to one internet connection as long as they are not connected to any other systems or LANs and have a personal firewall each preventing them to talk to any other virtual terminals or pos in that LAN as well?
Cheers
Ash
You are correct with the exception that with virtual terminals, they can rely on TLS to “isolate” them from the rest of the LAN.
Hi PCI Guru,
Thanks for your earlier comment. now my next question may be totally stupid.
But does it mean, the underlying computer that is used to access the virtual terminal, can not access any other applications over the network, even if the VT session itself is encrypted? or are we talking about segmenting off that computer from the rest of the network using firewall and TLS?
Cheers.
Ash
You need to answer the question, “What is the risk if I do not segment off that computer?” Some organizations feel that they have effectively mitigated the risks and allow the computer to be on the same network as other computers. Other organizations may feel the risk is too great and will segment any VTs from the rest of their network. Only you and your organization can answer the question as to the risk posed by segmenting those systems or not.
Regardless of your answer, you need to formally document your answer and rationale for the answer so that your QSA can understand how you got to the answer.
True. But I was coming more from the scope point of view.
By just saying that the VT session is encrypted so we don’t need to segment our computers and don’t treat the underlying computers in scope either.
So by not segmenting the underlying computer from the rest of the network only on the basis of secure VT session wouldn’t mean the entire network in scope?
As long as the encryption is strong (i.e., TLS v1.1+) and you are not in control of the keys, then the only systems in-scope for PCI are the ones doing the virtual terminal sessions. That said, not all QSAs nor security professionals will buy into this approach. If you are extremely risk adverse, then you will also want to logically or physically segment those computers from all other systems on your network.
Could the scope be reduced from an SAQ C or D to an SAQ P2PE if a PCI SSC Approved PTS Device with SRED functionality is utilized? As that type of device encrypts at the swipe or dip, would it not effectively take the rest of the network out of scope for PCI DSS compliance?
Only if it is also P2PE validated.
What if the POS is part of a P2PE solution? Since all is encrypted and it is your acquire who has the keys, is the isolation of the POS from the rest of the network is still required?
Thanks
Then you would be doing an SAQ P2PE and not SAQ C.
I’d have to agree. I often come across entities and other QSAs who have incorrectly determined their SAQ applicability as being that of SAQ C, yet I’ve yet to come across an entity that matches this SAQ.
I have to agree. There are very, very few organizations that actually match up to the criteria for SAQ C.
If a non-franchisee merchant has a physically and logically segmented network and VLAN with a stand-alone payment device (i.e. not integrated with the point-of-sale/cash register system), then it appears to meet all of the criteria for SAQ C. By physical segmentation, I mean dedicated firewall ports and dedicated cabling and switches for the payment devices. By logical segmentation, I mean a dedicated VLAN for the payment devices with firewall rules that only allow communication to/from the payment gateway.
This is not the best case for cashier efficiency and speed of customer service. The cashier would be required to type in the payment amount on the payment device and some kind of auth code or last 4 digits would need to be manually typed into the POS system for cross-reference. However, is there something specific about this type of configuration that makes it a requirement to use SAQ D?
This is just my opinion. You can only get an “official” answer from your acquiring bank.
If you are using a card terminal or point of interaction (POI) over a network that only contains the POI, then you should be using SAQ B-IP. From your description I’m not sure if your POS is also on the same network as the POI or not. If the POS shares the same VLAN as the POI, then SAQ B-IP should not be used. However, if the POI are encrypting at the swipe/dip, then I would argue that the risk of the POI being compromised by the POS is low and that SAQ B-IP could be used. But you would need to convince your acquiring bank of that fact.
If your bank does not agree with SAQ B-IP, then my fall back would be to SAQ C as that does make sense. If the bank doesn’t agree to SAQ C, then SAQ D is the only other remaining option.