Common Misconceptions About PCI DSS Self-Assessment Questionnaires (SAQs). Is your organization PCI compliant? Are you sure?
The PCI Data Security Standard applies equally to all organizations that handle cardholder data in any manner. But while the standard itself is the same for all companies, the process for validating compliance depends on a variety of factors. It’s important to understand that validating compliance (i.e. submitting paperwork to your merchant bank) does not equal compliance, which means actually doing all the various things specified in the DSS on an ongoing basis, and having evidence to show these things are being done.
Currently, only Level 1 merchants are required to have an onsite assessment by a QSA (though the rules are changing for Level 2 merchants effective June, 2011 due to changes announced by Mastercard). Other organizations are allowed to self-assess compliance. To assist in this process, the PCI Security Standards Council provides a series of Self-Assessment Questionnaires (SAQ Type A through D).
There are several common misconceptions regarding the use of these SAQs. The most common mistake, and the most significant, is thinking that only the requirements listed in the SAQ apply to the organization, and that answering yes to all items in the questionnaire means full compliance with the DSS. This is not the case.
The PCI Security Standards Council provides a PCI DSS SAQ Instructions and Guidelines Document (available here). On page 8, in the section titled “Selecting the SAQ and Attestation that Best Apply to Your Organization”, the first line is as follows:
“According to payment brand rules, all merchants and service providers are required to comply with the PCI Data Security Standard in its entirety.”
Somehow, most organizations seem to overlook that. For example, a company completing a SAQ Type C, which has 41 questions, believes that only those 41 requirements from the DSS apply, but this is incorrect. It is true that some requirements may be non-applicable, but there are many more than 41 that do apply.
The second most common mistake has to do with organizations completing a SAQ Type C. To keep this article from getting too long, I won’t go into the details of each SAQ type, but see page 12 in the PCI DSS SAQ Instructions and Guidelines Document (here) for a nice overview of that.
Many organizations believe they can qualify for a SAQ Type C as long as they don’t store any electronic cardholder data. This is not correct, as it ignores several other criteria. The PCI DSS SAQ Instructions and Guidelines Document, page 10, shows the specific criteria for using a SAQ C, which are as follows:
- Your company has a payment application system and an Internet connection on the same device
- The payment application system/Internet device is not connected to any other systems within your environment;
- Your company retains only paper reports or paper copies of receipts;
- Your company does not store cardholder data in electronic format; and
- Your company’s payment application software vendor uses secure techniques to provide remote support to your payment application system.
# 2 is the one most often overlooked. If your payment application is connected to a network with other systems on it, then SAQ C does not apply – SAQ D should be used. A good example of the proper use of SAQ C would be for a small business that has a single POS terminal with a DSL connection directly attached to that system.
Unfortunately, this misconception has been propogated in part because many of the banks and processors have this same misunderstanding, and so they allow their merchants to submit a SAQ C even when these criteria are not met. Since it is your merchant bank (aka acquiring bank) that has the final authority to determine what documentation you must submit, if they tell you to do a SAQ C, you can certainly go ahead and submit that to them. But if you want to actually be compliant with the DSS, understand that the entire standard applies. For example, the SAQ C does not ask about penetration testing (requirement 11.3). But if you’re not doing penetration testing at least annually and after significant changes to the environment, then you’re not PCI compliant. Your bank may be satisfied, but you will not pass the forensic audit that occurs if there is a security breach. This investigation will be expecting to find all applicable DSS requirements in place.
So remember, just as the PCI Council explains in their instructions, the SAQs are intended as a tool to assist in self-assessing compliance with the DSS. The actual DSS is what all organizations ultimately need to comply with. Checking those boxes in the SAQ can give a false sense of security if these responsibilities are not properly understood.
Jeremy Simon, PCI QSA, CISSP, CISA
Practice Lead, PCI Compliance Services
HALOCK is headquartered in Schaumburg, IL, in the Chicago area and advises clients on reasonable information security and conducts PCI preparedness assessment, scoping, remediation, validation, and compliance maintenance services throughout the US.
