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.
Pages: 1 2
-Marc
October 17th, 2012 at 1:17 pm
I think this is a very strict interpretation of “connected” systems. You may be right in that PCI SSC views scoping in this purist view, but this is one of the problems with PCI. SAQ-C for example, creates a catch-22 for merchants. A requirement for SAQ-C is “Use and regularly update anti-virus software.” Well, to do this, the AV application must have connectivity to another “connected” system. Yes, I know, a merchant can manually copy AV definitions to removable media and manually update the CDE, but how many are really going to do this and for the few that do, how up-to-date are they really? So this strictest view of “connected” makes SAQ-C invalid so why does PCI even have the SAQ? This sounds like nothing more than a PCI/card brand liability trap for merchants.
October 17th, 2012 at 8:36 pm
A related problems for retailers can be the payment equipment supplied by the bank, ISO or integrator. For example, consider a dial-up terminal/PINPad without an integrated printer.
This means receipt printing on a printer attached to the POS workstation which is in turn connected to the in-store LAN and thus may/may place the entire ‘typical’store network in scope – because PAN is often printed on merchant receipts during offline/SAF modes as a result of business requirements of Acquirers. The decisions made by the Acquirers can affect the scope and compliance of merchants, even those apparently suitable for SAQ A. And the Acquirer has made the validation process move from SAQ A to SAQ D for many small retailers. I’d prefer that Acquirers and ISOs et al design their solutions with the end user’s PCI DSS compliance in mind. Then PCI DSS will have even greater benefits.
October 18th, 2012 at 12:00 am
Steve, Lyal,
Thank you both for the thoughtful comments.
Steve, I agree my position is a strict interpretation of the PCI SSC’s guidance, but that is exactly what I as a QSA am supposed to do. The same goes for merchants, too. The only position that matters is that of the PCI Council’s or maybe the merchant’s acquiring bank. That is, if the acquirer wants to give the merchant a pass on a particular SAQ, I would have no problem with that. Otherwise, we all have to play by the house’s rules.
I have some sympathy for your point of about how the rules for SAQ C may not make sense in the real world that many merchants live in. You are right about the difficulty of meeting SAQ C if a merchant or retailer has any meaningful security or IT infrastructure. But as I pointed out, that appears to be the Council’s intent. That is, they aimed the shortened SAQs at the small merchant, not one with extensive scope or multiple locations. It isn’t for me to agree or disagree with this (and I, too, have been very critical of SAQ C). Rather we all have to live with the PCI rules the Council has laid out. If merchants want to change things, they need to get involved and have their views heard individually or through their associations.
Lyle, you make a powerful point about how acquirers can make a merchant’s situation easier or harder. I disagree, though, with your point about PAN data printed on batch tapes or other “requirements of Acquirers.” Take a look at the excellent Visa publication on this topic (http://usa.visa.com/download/merchants/PAN_truncation_best_practices.pdf). My advice based on Visa’s position is that if an acquirer makes the merchant keep cardholder data, I’d think about getting a new acquirer.
October 18th, 2012 at 12:06 pm
I agree that you, as a QSA, you must use a strict interpretation. But with this strict interpretation, I argue that in the real world, with this strict interpretation, no merchant can qualify for SAQ-C and still comply with SAQ-C. Either PCI SSC needs to relax their “connected systems” definition, or drop SAQ-C — the latter being a boom for alternative payments.
October 20th, 2012 at 10:18 am
Agreed on excellent thoughts above. I don’t have a single customer that qualifies for the shortened SAQ any more. I think the SAQ is getting to be such a burden that businesses are making decisions to not upgrade to new equipment and technologies. This stifles business growth and inhibits moving to solutions that encourage more secure practices, as well as other benefits.
For example, I regularly encounter business to business companies that say they don’t store credit data because of risk. But when employees are probed, they really do store data. They have all sorts of excuses- we only hold it for 30 days and it’s in a locked file drawer, etc. I’ve heard it all.
What’s really needed is a simpler method for merchants to identify the correct SAQ, including case studies or merchant scenario’s so they can more easily identify the correct SAQ. How about adding a simple logic tree?
November 8th, 2012 at 3:05 pm
I disagree; this is an issue of scoping as it applies to the unencrypted cardholder data. If the data is encrypted, and the retailer does not hold any of the keys or ability to access the keys, then the data is out of scope, and therefore the system that data is on is also out of scope.
November 12th, 2012 at 4:33 am
Walter,
You wrote “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”.
This seems to be a key clarification, but I’m a little confused as to what a “connected to connected to” might mean. Three possibilities come to mind:
1. “connected to connected to” describes a device which cannot connect with a system component that stores, processes or transmits cardholder data, but which *can* connect with a device directly connected to such (e.g. on the same [V]LAN). That is, what the Open PCI Scripting Tookit refers refers to as Category 2a, 2b and 2c devices.
OR
2. “connected to connected to” describes a device in the sense of Open PCI Scripting Tookit Category 2x, i.e. which is completely isolated from any device that stores, processes or transmits cardholder data and from any device directly connected to such (e.g. on the same [V]LAN), however, it’s still possible to administer one of these devices via a connection to an intermediate device that *can* connect with it.
OR
3. both of the above
Did they use specific language as I have above, or did they just speak generally in language affirming that scope of assessment extends out to two degrees of separation as a rule of thumb?
Was this a formal written clarification (e.g. a FAQ)?
Sounds like the details on this could make a good article 8-)