In my work, I’m often engaged with merchants in different verticals, doing PCI assessments. This frequently involves assisting them with their PCI Self-Assessment Questionnaires (SAQ). It’s an interesting process because the merchants run the gamut from Level 2 through 4, size-wise, in terms of annual number of transactions. Visa defines these merchants as less than or equal to six million transactions annually.
With the larger merchants or enterprises, say a University or Corporation, I’ll often find a well-organized PCI compliance group. They usually treat completing their SAQ like it’s a Report on Compliance (ROC), reserved for Level 1 merchants (6 million + transactions annually) and often appreciate the need (not a requirement) to have supporting evidence for each of the control questions in the 12 PCI Requirements. This supporting evidence includes network diagrams, cardholder environment diagrams, router and firewall Access Control Lists, system build checklists, change management checklists, various screenshots, access control, domain policy, policies and procedures, and many other items. all of these are items I’d request if I was doing an on-site audit.
The smaller merchants, on the other hand, have problems ranging from understanding what the PCI-DSS is and why they have to do a SAQ (because their Acquiring Bank says so) to, more importantly, truthfully answering the control questions. Because the SAQ process is a self-assessment, merchants who don’t understand what the Requirements mean, or are asking, are tempted to simply answer ‘Yes’ to the more-technical questions because they simply don’t know. I’ve found that the latter is often because they have outsourced IT staff and can’t afford the time and cost to engage them in answering the technical questions. Or, they are the IT staff, as well as the Business Owner, especially true for the very small merchants.
Compounding this lack-of-resources problem, in some cases, are the payment application vendors. They often provide their client, the merchant, with their Payment Application Data Security Standard (PA-DSS) Implementation Guide. This tells the merchant basically, ‘if you installed it correctly and did this and that the right way, this is how your application meets PCI requirements’. I usually ask merchants if they have their PA-DSS and while many do, many do not and need to call their vendor. Having the PA-DSS while completing a PCI SAQ is invaluable because it helps answer sections of Requirements 3, 4, 7 and 8 in particular. Remember though, you’ll only see a PA-DSS Implementation Guide with payment applications, not payment hardware like a swipe terminal.
So, a part of my time is engaged in bootstrapping the merchants who need it, by providing basic education on what the PCI Requirements are all about. I’m soft of a ‘tour-guide’ to the PCI-DSS and as a PCI-DSS Qualified Security Assessor (QSA), feel that this is appropriate. In a sense, I’m raising security awareness and hopefully, helping these merchants become not just compliant, but more secure. I work with them to help translate what the technical jargon means and why it matters. During the Remediation phase, I offer suggestions as to how they can meet the control objectives and minimize their compliance burden.
For those merchants who complete their SAQs without assistance from consultants like myself, or in-house resources like a PCI Security Standards Council-trained Internal Security Assessor, I’ve found myself wondering how real their SAQs actually are, in terms of security truth versus wishful thinking and best-guesses. And, since their acquiring, or merchant banks are accepting these SAQs annually, I’m also interested in whether or not these banks follow-up with the merchants. Do any of the banks ever find themselves thinking ‘Seriously?’ when they review the SAQ?
While my job is focused on compliance, be it PCI, GLBA, or HIPAA/HITECH, my overarching goal is security.
And that’s what it’s all about, for all of us.
Be well.
Bill Wildprett
Leave a comment