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
PCI DSS Requirements
PCI DSS Requirement 5.4.1: Anti-spoofing controls such as DMARC, which stands for Domain-based Message Authentication, Reporting and Conformance, Sender Policy Framework (SPF), and Domain Keys Identified Mail (DKIM) can help stop phishers from spoofing the entity’s domain and impersonating personnel.
Clarification on eCommerce Outsourcing PCI DSS requirements 6.4.3 and 11.6.1
Unpacking the New PCI DSS Password Standards
Is Your Organization Prepared for PCI DSS Automation – Requirement 10.4.1.1?
What is the PCI DSS v4 Authenticated Scanning Mandate – Requirement 11.3.1.2?
What is the PCI DSS v4.0.1 Requirement for PoLP – Requirement 7.2.5?
The New PCI DSS v4.0.1 Software Catalog Mandate – Requirement 6.3.2
How to Analyze An Attestation of Compliance (AOC)
PCI Compliance New Requirements and Targeted Risk Analysis (TRA)
RESOURCES & NEWS
Learn more about Penetration Testing and new exploits in HALOCK’s Exploit Insider.
The Dangers of Legacy Protocols
PCI Targeted Risk Analysis & DoCRA
https://www.halock.com/pci-compliance-new-requirements-and-targeted-risk-analysis/
HIPAA & Penetration Testing & Incident Response Plans
Top Threats in Healthcare
https://www.halock.com/top-cyber-threats-in-healthcare/
Cloud Security Risk Management
https://www.halock.com/prioritized-findings-and-remediation-in-cloud-security-reporting/
Penetration Testing Reports to Manage and Prioritize Risk
https://www.halock.com/a-threat-based-approach-to-penetration-test-reporting/
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.
