Is it time to require every merchant to validate compliance against every single PCI requirement? That is, does it make sense to eliminate self-assessment questionnaires (SAQs) A, B, C and even the new C-VT and to require every merchant to use SAQ D? Doing this may seem dramatic, and it certainly would be a shock to many small and midsize merchants. But it only reflects the PCI Council's own position that every merchant needs to comply with all of PCI.
I am not convinced that requiring every merchant to use SAQ D, with its 280-plus requirements, makes sense. It is just too daunting for a small or midsize merchant. On the other hand, we see increasing numbers of hacking attacks on these same merchants who use these shortened SAQs, so they need to be more secure. Maybe a better course is to upgrade the shortened SAQs or even change them into "guidance" documents.
At a PCI expert panel I recently led, the discussion moved to compliance validation. The senior PCI compliance officer for one of the largest card acquirers told the audience of about 150 Level 2, 3 and 4 merchants that they all should use SAQ D and forget about the shortened SAQs. His reasoning was that such a move made sense from both a security and a business perspective.
My initial reaction—and that of most of the audience—was to reject the recommendation out of hand. After all, didn't the PCI Council itself develop the shortened SAQs to help small and midsize merchants validate their compliance? Haven't the shortened SAQs encouraged many merchants to stop storing cardholder data? Didn't the Council just introduce a fourth shortened SAQ for virtual terminal merchants? And didn't the shortened SAQs make validation easier and cheaper for all the merchants sitting in this audience?
On reflection, though, his recommendation makes a lot of sense. That is, perhaps the issue is not the SAQs themselves but how retailers and other merchants use them.
Readers of this column will know that all but the largest (Level 1) merchants and service providers can self-assess their PCI compliance using an SAQ. The one we know as SAQ D addresses each requirement and sub-requirement of the PCI DSS, which totals about 280 items.A few years ago, the PCI Council devoted a lot of time and effort to come up with three shortened SAQs. The Council created these SAQs by looking at the respective merchant environments and, in effect, marking "Not Applicable" for those PCI requirements that did not seem to apply. What remained became the SAQ.
The one common thread in each shortened SAQ is that the merchant cannot store electronic cardholder data. The simplest is SAQ A, designed for merchants who outsource their card processing. It addresses only two PCI Requirements and has just 13 questions. SAQ B is for POS terminal merchants. It address five PCI Requirements and has 25 questions. SAQ C is for merchants with a payment application connected to the Internet. This one addresses almost all PCI Requirements (11 out of 12), and we are now up to 80 questions. The new SAQ C-VT is aimed at virtual terminal merchants. It addresses only nine PCI Requirements—fewer than SAQ C—and has 51 questions.
Compared to SAQ D's 280 items, any one of the shortened SAQs lives up to its name and is, therefore, attractive to any merchant who qualifies. My experience is that many merchants adopt the mantra "anything but SAQ D." They review their business processes, eliminate storing electronic cardholder data, segment their networks and adopt any number of good security practices that reduce their risk and ease their PCI compliance work.
These are all good results, and I'm sure it is exactly what the PCI Council had in mind when it created the shortened SAQs. Nevertheless, it may be time to ask if we still need the shortened SAQs. After all, PCI has been around for a number of years, and evidence on recent data compromises indicates that the bad guys are targeting many small and midsize businesses—the very ones who could qualify for a shortened SAQ. Therefore, should not these merchants want to be secure and avoid a data compromise?
There is, however, one overarching argument to support requiring every merchant to use SAQ D: It is effectively required already, and mandating SAQ D would resolve the inherent hypocrisy in the whole shortened SAQ process. Here is what I mean.
The Council states in the SAQ Instructions and Guidelines: "According to payment brand rules, all merchants and service providers are required to comply with the PCI DSS in its entirety." If that isn't enough, each of the shortened SAQs comes with this statement:If that isn't enough, each of the shortened SAQs comes with this statement: "If there are PCI DSS requirements applicable to your environment that are not covered in this SAQ, it may be an indication that this SAQ is not suitable for your environment. Additionally, you must still comply with all applicable PCI DSS requirements in order to be PCI compliant."
These provisions mean that regardless of whether merchants answer just 12, 25 or 80 questions, they still are expected to comply with "PCI DSS in its entirety." That was the point the compliance officer was making when he told those merchants they should use SAQ D regardless of their payment environment. The Council has always held this position, and it repeats it (at least to us QSAs) whenever the subject of a shortened SAQ comes up.
Do I think the shortened SAQs will go away? No, or at least not soon. Literally millions of merchants are eligible to use a shortened SAQ. One option might be to use the shortened SAQs as compliance guides. The merchant would still need to go through the entire PCI DSS, but it would be up to them to identify the "additional requirements applicable" to their environment. Requiring everyone to use SAQ D would force merchants to consider explicitly each requirement and mark "N/A" where they think it is appropriate and considering their particular card-processing environment. This approach is consistent with the instructions for each simplified SAQ.
The alternative is to revise the shortened SAQs to more closely reflect the technical and business realities of the merchant and processor environment. For example, SAQs A and C-VT merchants access the Internet, but neither requires vulnerability scans; SAQ C requires the payment application be behind a firewall, but the critical requirements to log administrative access to that firewall or have file integrity monitoring on the application are missing.
Maybe the answer is to take a fresh look at each shortened SAQ to identify the "additional requirements applicable" in the real world. I'll take a shot at that in a follow-up column.
In the meantime, what do you think? Should every merchant have to address the full PCI DSS? Do the shortened SAQs pose too much risk for the benefits of simplified compliance? Should they be downgraded to templates or guidelines rather than SAQs? Or should they be revised to reflect better how merchants operate?
I'd like to hear your thoughts. Either leave a comment or email me at [email protected].