The PCI Scoping Discussion Is Over. Now It’s On To SAQ Roulette
Written by Walter ConwayA 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.