Why The SAQs Will Change This Year

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

October is likely to see significantly revised Self-Assessment Questionnaires (SAQs) from the PCI Council. Few merchants will be more surprised than those E-Commerce merchants who have outsourced their card processing. Effective with PCI DSS version 3.0, many E-Commerce merchants will learn that their Web servers are in scope for PCI compliance and that SAQ A got a bit longer and a bit more complicated.

These merchants typically use the simplest SAQ, SAQ A. They also always (in my experience) consider their Web server out of their PCI scope, because that server does not "store process, or transmit" cardholder data. Instead, the server redirects the user to a PCI-compliant third-party service provider that processes the card transaction for the merchant. The conclusion is understandable. An E-Commerce merchant's SAQ A addresses a very small subset of PCI DSS. It includes parts of only two requirements: physical security of backups and paper records that may contain cardholder data; and managing the PCI service provider.

Processing is outsourced, and it is outsourced to a PCI-compliant service provider. What could be simpler? Oh, and I should add: What could be more wrong with that conclusion?

This fall will see the release of PCI DSS version 3.0. I expect to see (finally) a recognition that an E-Commerce merchant's server will be officially declared to be in PCI scope, even if it never stores, processes or transmits a single payment card.

At the recently completed RSA Conference, the PCI Council staff presented a session describing how merchants should determine which people, processes and systems are in their PCI scope. The PCI Council staff explored the outsourcing scenario described above. They then described a "redirection mechanism compromise," whereby the bad guys compromise the merchant's Web server. They either redirect the customer to a different site or intercept the cardholder data as it is passing through to the service provider.

Regular readers of this column know I have hoped the PCI Council would update SAQ A to reflect precisely the type of compromise described by the Council's staff and by Visa Europe. In truth, all the SAQs are due for an overhaul, and I expect they will receive that treatment.

I am not privy to any PCI Council or card brand discussions of how SAQ A or any of the SAQs will change. Looking at the slide deck the PCI Council presented at RSA and the recently released E-Commerce Guidelines, it may be that at least parts of several PCI DSS Requirements will be added, for example:

    Requirement 6 (Develop and Maintain Secure Systems and Applications), for the shopping cart (and maybe require it to be PA-DSS validated).
  • Requirement 7 (Restrict Access to Cardholder Data by Business Need to Know), applied to the merchant's Web servers and network.
  • Requirement 8 (Assign a Unique ID to Each Person with Computer Access), especially 8.3 governing remote access.
  • Requirement 11 (Regularly Test Security Systems and Processes), especially 11.2, which requires passing both internal and external vulnerability scans quarterly.

What do you think? I'd like to hear your thoughts. Either leave a comment or E-mail me.