The PCI Scoping Discussion Is Over. Now It's On To SAQ Roulette

A 403 Labs QSA, PCI Columnist Walt Conway has worked in payments and technology for more than 30 years, 10 of them with Visa.

Any discussion of whether a particular system or device is or is not in scope ended at the recent PCI Community Meeting. The PCI Council made it clear that any device "connected to" the cardholder data environment (CDE) is in scope, and that includes what the Council termed any "connected to connected to" system. Given that the PCI Council's guidance is final in all matters related to PCI scoping, it is time to shift the discussion to helping merchants that qualify to use a self-assessment questionnaire (SAQ) pick the right one.

We can do this by posing a question: When is a merchant that has just validated its PCI DSS compliance not compliant? There are many answers, but a very common one is when that merchant uses the wrong SAQ and is exposed to an expensive and reputation-damaging cardholder data breach.

In this QSA's experience, merchants frequently select the wrong SAQ. In particular, it's merchants believing they qualify for SAQ C or C-VT. The cause usually is a too casual reading of the qualifications to use one of those shortened SAQs, coupled with a misunderstanding the PCI Council's unchanged position on what constitutes "in scope" systems.

With the recently enlivened discussion about proper PCI scoping and what constitutes effective scope reduction, choosing the right SAQ has popped to the forefront of any PCI compliance discussion. The guidelines for the SAQs can appear complicated, and understanding those guidelines can mean doing some research and asking some tough questions.

The unfortunate result is that most merchants get it wrong. These merchants honestly believe they qualify for a particular shortened SAQ, but most do not. They simply do not meet all the requirements.

Originally, there was only one SAQ for everyone, and it included every PCI DSS requirement. Eventually, the PCI Council introduced several shortened versions to meet the particular needs of merchants outsourcing their processing (SAQ A), using dial-up POS terminals or imprinters exclusively (SAQ B), or processing cards over the Internet either directly (SAQ C) or using a virtual terminal product (SAQ C-VT). Each shortened SAQ included only those PCI DSS requirements relevant to the target merchant. The original version became SAQ D, and it still includes each PCI DSS requirement.

The shortened SAQs made PCI compliance more approachable for many small and midsize merchants by simplifying the PCI validation process. We can debate the relative merits of this approach, but almost everyone would agree the shortened SAQs benefitted all parties except the bad guys. Facing a 49-page SAQ D with well over 280 questions can be daunting. And if a merchant's business fits one of the shortened SAQs, compliance validation could be as simple as answering 13 questions (SAQ A).

But the shortened SAQs work only as long as the merchant actually qualifies to use one of them. For example, a common element among all the shortened SAQs—and the one that gets the most emphasis—is that the merchant does not store electronic cardholder data. If cardholder data is stored, even for an instant, then all shortened SAQ bets are off and the merchant must use SAQ D.

Remember, though, that not storing electronic cardholder data is only one requirement. There are others, and they have to do with scoping and the PCI Council's definition of what constitutes a "connected" system.

Too many merchants, at least in this QSA's experience, stop reading at the requirement not to store electronic cardholder data. They ignore the additional requirements needed to qualify for a shortened SAQ.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.