Evan Schuman's StorefrontBacktalk

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

The PCI Council has stated that it is reexamining its four Self-Assessment Questionnaires (SAQs). Level 2 through Level 4 Merchants use an SAQ to validate their compliance. Although I have no insight into what possible changes or even new versions might come from the Council, I have some suggested changes that reflect both current attack vectors and real-world business practices.

Even though QSAs spend a lot of time preparing Reports on Compliance (ROCs) for their Level 1 Merchants and Service Providers, most of us also work with many merchants who self-assess their compliance. Interestingly, some of these merchants can be quite large organizations but with only limited payment card activity. For these merchants, the PCI Council developed three simplified SAQs that are based on how they process card transactions.

Merchants use SAQ A if they outsource their card processing to a compliant third-party service provider. The requirements to use this SAQ are: You have card-not-present (i.e., MOTO, E-Commerce) transactions exclusively; you do not store, process or transmit any cardholder data yourself; your service provider is PCI compliant; any cardholder data is only on paper; and you store no cardholder data electronically.

The general model of an SAQ A merchant is one with a Web site that links to a hosted order page at a secure third party. Cardholders are transferred to that secure hosted page to enter their card data and then returned to the merchant’s site after the transaction is approved or rejected.

In my perfect world, I would like to see two changes to this SAQ. First, I would like the SAQ to stipulate that the service provider is not just PCI compliant (as a service provider, of course; not as a merchant) but that it is a Level 1 Service Provider. My reasoning is that SAQ A merchants depend on their service providers. I want those service providers to have an outside assessment of their compliance.

My second suggestion deals with the merchant’s own Web server. I would like it to be scanned for external vulnerabilities, and I want the code redirecting the customer to the hosted order page to be inspected. Each of these tests would be done quarterly. The basis for this suggested change is an excellent Data Security Alert posted by Visa Europe. In that alert, Visa describes attacks on SAQ A merchants where the bad guys have hacked the merchant’s server and installed their own code to redirect customers to their criminal site instead of the service provider’s site. I would change SAQ A to make this attack less likely to succeed.

I would also like to see a note in the instructions to SAQ A to address mail order/telephone order (MOTO) transactions. It should say merchants cannot do MOTO and still qualify for SAQ A. For example, if the customer can’t get to the Web or has some other problem, the merchant cannot use its computer to go on the Web and enter that customer’s card number for him or her. In addition, the merchant just turned its workstation into a payment terminal, and heaven knows what has just been done to its PCI scope. I see this situation so often I coined a name for it: SAQ A OMG.

I regret having to make life more complicated for these merchants. But we all need to remember that although you can outsource your processing, you cannot outsource your responsibility.

SAQ B presents a different challenge. Merchants use SAQ B when they either have an imprinter (a.k.a., knuckle-buster or zip-zap machine) or use POS terminals “connected via a phone line” to their acquirer or processor. That terminal cannot be connected to the Internet or to any other system in the merchant’s environment. Like SAQ A, the merchant retains only paper records and does not store electronic cardholder data.