This is page 2 of:
The PCI Scoping Discussion Is Over. Now It’s On To SAQ Roulette
In the case of SAQ C, in particular, two subtle requirements are frequently overlooked.
The first overlooked requirement is: “Your company store is not connected to other store locations, and any LAN is for a single store only.” That means if a merchant’s retail or hospitality application supports more than one location, or even more than one “store” at a single location, that merchant has to use SAQ D regardless of whether or not it retains electronic cardholder data.
The second, and more frequently overlooked requirement—and this is where the PCI Council’s scoping guidance comes in—is: “The payment application/Internet device is not connected to any other systems (emphasis provided) within your environment.” To paraphrase what the PCI Council told the assembled masses at the Community Meeting, what is it about “not connected to” that you don’t understand?
Let me give just two examples of connected systems. If a merchant’s payment application can receive an inbound connection from outside the CDE, such as from a patch update or antivirus server (even through a properly configured firewall), that merchant has a “connected to” system, and it cannot use SAQ C. Or, if the payment application initiates an outbound connection to a internal domain name server (DNS) or Active Directory controller, that, too, is a “connected to” system. And forget about any shortened SAQ (and that includes SAQ C-VT for all you virtual terminal users).
The fun does not stop there. In addition to needing to use SAQ D, those “connected to” systems and devices must be included in the merchant’s PCI scope. That is because, to the PCI Council, “segmentation” means “isolation.” It does not matter that there is a firewall between the connected systems. All that matters is whether the payment application can receive a connection from or initiate a connection to another system or device within the merchant environment. If that situation exists, the merchant has not sufficiently segmented its systems to minimize PCI scope.
Therefore, the only way to qualify for SAQ C or C-VT is with an isolated, dedicated device.
The reality is that very few merchants qualify for SAQ C or C-VT, and those that do may be in for a lot of work. The PCI Council recognizes this situation in its instructions that accompany each SAQ: “This shortened version of the SAQ includes questions which apply to a specific type of small merchant environment, as defined in the above eligibility criteria. If there are PCI DSS requirements applicable to your environment which are not covered in this SAQ, it may be an indication that this SAQ is not suitable for your environment.”
What does a “small merchant environment” for SAQ C look like? To this QSA, it would be a standalone merchant with a single, dedicated POS computer. If that description doesn’t match your business, if you have a security infrastructure in place that supports your payment environment or if your application supports multiple locations, all I can say is welcome to SAQ D land.
The PCI Council’s guidance on scoping a PCI DSS assessment has not changed. What the discussion about scoping has done is to make more merchants aware of that guidance and what it means for their own PCI scope.
What do you think? Does your organization qualify to use a shortened SAQ? Did you think you did before reading this column? Either way, I’d like to hear your thoughts. Leave a comment or E-mail me.