This is the third part in a series on the path to PCI compliance. Previously, we covered scope and the 12 PCI-DSS requirements. In this part, we will discuss the Self-Assessment Questionnaire, or SAQ, and Attestation of Compliance. We’ll also review how to understand which version of the SAQ you need to fill out. The SAQ is a questionnaire for you to fill out based on your own assessment of how well you are abiding by the 12 PCI-DSS requirements. Your answers to the SAQ become your Attestation of Compliance, or AOC.
The aim of the PCI-DSS SAQ and AOC (wow – lots of acronyms there) is to secure card data. In the case of a data breach, or a suspected data breach, in which you are allegedly the source of the breach, you will need to prove – with certainty – that you not only kept to the PCI-DSS requirements, but that you also had no lapses in control.
Let’s start by explaining what you can’t do when answering questions in the SAQ. You cannot answer ‘no’ to any question and pass. That is not possible*. For the most part, and generally with very few exceptions, for you to be in compliance you will answer ‘yes’ or ‘n/a.’ And with every ‘n/a’ you must have an acceptable explanation of non-applicability. The acquirer – First Data for NISC Members – decides what is acceptable and what is not. Also, they are the judge and jury for which SAQ you should fill out. There are several different SAQs, and exactly how the card data is captured and processed determines which SAQ you need to fill out.
The SAQs vary from the SAQ A with 22-responses to the SAQ D with 328-responses. Probably the most common for our Members at this time is the SAQ B-IP, which has about 86 responses, of which about 40 can be answered N/A. Most of the other 45 or so questions are related to security and incident response policies you have in place.
The SAQ is simply the PCI-DSS standards in question form. Each version of the SAQ only includes a subset of the full requirements that affect the scope of security measures necessary to protect the card data in that particular environment. Let’s take a look at an example.
This example is requirement 2.1. First let’s look at what the PCI-DSS says.
Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network.
This applies to ALL default passwords, including but not limited to those used by operating systems, software that provides security services, application and system accounts, point-of-sale (POS) terminals, payment applications, Simple Network Management Protocol (SNMP) community strings, etc.).
This requirement seems simple enough on the surface. You just need to make sure that before you install a system on the network that all default passwords are changed and unused accounts are disabled. In the case of Verifone devices, our practice has always been to provide recommendations for changing passwords, but doing so is something which can only be done on premise by you and your staff.
And while NISC does not fill out and submit the SAQ for our Members, we do try and supply solutions and tools that make it easy to answer the questions. The SAQ will test you on whether or not you followed through with the guidance. This is requirement 2.1, but from the SAQ this time:
- Are vendor-supplied defaults always changed before installing a system on the network?
- Are unnecessary default accounts removed or disabled before installing a system on the network?
Your answer options are Yes, Yes with CCW (Compensating Control Worksheet), No, or N/A. In the case of this requirement, a case doesn’t really exist where N/A is a reasonable answer because there will always be a password of some sort. You either change the passwords from the default or you do not. Since no is never acceptable for compliance, that only leaves you with Yes or Yes with CCW. A CCW, or Compensating Control Worksheet is described as follows: “Compensating controls may be considered for most PCI DSS requirements when an entity cannot meet a requirement explicitly as stated, due to legitimate technical or documented business constraints, but has sufficiently mitigated the risk associated with the requirement through implementation of other, or compensating, controls.”
In the case of requirement 2.1 it is possible that a vendor supplied password or unused account cannot be changed or deactivated. In those cases, you may need to “sufficiently mitigate the risk” by implementing other controls. Mind you, these other controls must be very stringent. Not only must they “meet the intent and rigor of the original PCI DSS requirement,” but also “Be ‘above and beyond’ other PCI DSS requirements.” All of these quotes come directly from the PCI-DSS.
Depending on which SAQ you are required to fill out, you may need to perform an external or internal vulnerability scan – or both. The PCI requirement is to do so “at least quarterly” and “after any significant change in the network.”
We hope you have a better understanding now about the SAQ’s relationship to PCI-DSS. In the next installment, we will review the SAQ and AOC submission process.
*If your organization is subject to a legal restriction that prevents the organization from meeting a PCI DSS requirement, check the “No” column for that requirement and complete the relevant attestation in Part 3.