As promised, here is part 2 of my SAQ blog. I’m heading to the PCI Community Meeting in Las Vegas this week, so look out for an upcoming blog about highlights from the meeting. Bluefin is a Participating Organization (PO) with the PCI SSC and as such, we can send two representatives to the annual PCI Community Meeting. This year, Tim Barnett (Bluefin CTO) and I are attending.
The SAQ (often pronounced like “sack”, in the same way that FAQ is often pronounced “fack”) is a self-assessment exercise for organizations that store, transmit, or process cardholder data. It becomes very problematic if gaps are found between the PCI-DSS requirements and the organization’s technical reality.
“Not in Place” is an unacceptable answer for any question on the SAQ. If your organization does not comply, then it must either put a remediation plan in place or offer a Compensating Control. Compensating Controls go above and beyond the original intent of the requirement and are only allowable in cases where there is a legitimate business need to implement them. Furthermore, they must be reviewed and accepted. If you can’t comply with one of the requirements, and wish to provide a Compensating Control, then I strongly suggest that you reach out to a QSA or PCI consultant to obtain approval of the Control.
In my experience, it is best to outsource as much of the storage, transmission, and processing of cardholder data that you can to a fully qualified Level 1 Service Provider. If you are in a retail/card-present environment, where you must accept the card through a POS and then transmit the information to your processor, then I strongly recommend that you consider Point-to-Point Encryption (P2PE), which greatly reduces the scope of your assessment.
1. Identity: Are you a Payment Application Provider, Service Provider, or a Merchant? (I use caps for these terms because they have a very specific meaning in PCI)
- Payment Application Provider: If you only provide software for other organizations and do not store, process, or transmit cardholder data over networks and systems of your own, then you are considered a Payment Application Provider and must comply with the PA-DSS (Payment Application – Data Security Standard). Also, you are not allowed to self-assess and you must hire a specially-certified QSA called a PA-QSA. However, if you “host” the application for other organizations (such as SaaS, ISV, or cloud providers) or if you do a bit of both application development and hosting, then you are considered a Service Provider and can read on to the next section.
- Service Provider: You are considered a Service Provider if you store, process, or transmit cardholder data on behalf of another entity. That can sound confusing since there are many entities involved in bringing together a fully furnished transaction. But generally speaking, if you are the entity that has the Visa/MasterCard/Discover merchant account, then you are the “Merchant” because you are ultimately liable to your Acquiring Bank for what happens with the account. Any other entity involved in the cardholder data transaction flow is providing a service to you and are called Service Providers. Service Providers must register with Visa & MasterCard and be fully PCI Compliant in order to be used by a Merchant and not prohibit the merchant from attaining their own compliance – said another way, Merchants MUST use PCI Compliant Service Providers. You can search out Service Providers (Level 1 only) at http://www.visa.com/splisting/searchGrsp.do and http://www.mastercard.com/us/company/en/whatwedo/compliant_providers.html
- Merchant: As noted above, the Merchant has the merchant account and a signed agreement with an Acquiring Bank to authorize cardholder data and request settlement to their own depository bank. A Merchant may or may not use Service Providers or Payment Applications to store, process, and transmit transactions. But if they do, they must only use entities that are PCI Compliant.
2. Size: If you are a Merchant or Service Provider, how many Visa transactions do you run per year? In practice, it seems that most QSAs and Acquiring Banks primarily use the Visa transaction count, since Visa’s sizing limits are the most stringent and the card is the most widely used. Also, if you hit a limit in one brand, you are usually pushed to the same sizing category within all of the brands. You are likely to process more Visa transactions than any other type and hit their limits first, thus their limits can be used to determine your required compliance level.
- Service Provider: If you process under 300,000 Visa transactions per year, then you are a Level 2 Service Provider and are eligible for self-assessment. If you are in this category, you are obligated to complete the SAQ-D. If you process more than 300,000 transactions in a year, then you are a Level 1 Service Provider and must retain the services of a QSA to complete an annual Report on Compliance (ROC) on your behalf. Currently, only Level 1 Service Providers are listed on the Visa and MasterCard websites. However, if you are a Level 2 Service Provider, you can prove your compliance to Merchants by showing them your compliance letter. Service Providers can determine their level based on transaction count here.
- Merchant: For Merchants, there are four levels that are based on how many Visa transactions are processed per year. Currently, only Level 1 Merchants are required to be assessed by a QSA. All others can self-assess. The Merchant level limits can be found here.
3. Scope: How and to what extent do you store, transmit, or process cards?
- Service Provider: Service Providers that process under 300,000 Visa transactions per year automatically have to complete the SAQ-D; the question of scope doesn’t pertain.
- Merchant: How a merchant accepts and transmits cardholder data determines which SAQ a merchant is eligible for.
Types of SAQs
SAQ A: As I said earlier, ALL entities that touch cardholder data must be assessed. SAQ A is for merchants that do not touch cardholder data but rather have outsourced all processing of cardholder data to a Service Provider. For example, a merchant that allows a call center access to their merchant account in order to accept telephone orders is eligible for SAQ A if this is the only way that they accept cards. In this case, they would be required to only use PCI Validated Service Providers. Another great example is a merchant who uses a payment gateway to host the payment page.
SAQ A is for card-not-present merchants(CNP) where all cardholder data functions outsourced.
SAQ B: If you are a “traditional” (although the use of the word seems to be changing) merchant who uses a credit card processing machine that dials up to your processor to process cards or a merchant who uses paper to obtain cardholder data, and have no Internet connections present, then you are eligible for SAQ B. However, the exception here is that if your credit card machine is connected to your processor via an IP address or a cellular network (which is becoming more common), then you are not eligible for SAQ B.
This is where it can become VERY confusing for small merchants. A bank or processor may sell merchants on the speed and convenience of newer IP or wireless terminals, which then requires the merchant to submit an SAQ D and have quarterly vulnerability scans from an Approved Scanning Vendor (ASV). I personally think this particular SAQ needs to include ANY terminal-based card machine that a processor gives to their merchant (dialup, cellular, or IP), and that the onus of securing that terminal should be on the processor. The counterpoint is that since the dial-out connection is a private connection (not going over the public Internet), it is not subject to as many vulnerabilities.
SAQ B is for merchants with only imprint machines or only standalone, dial-out terminals with no electronic cardholder data storage.
SAQ C: If you are a merchant that uses a payment application or software provided by another company but hosted on your own servers or computers to process cardholder data, then you are eligible for SAQ C. You must use payment applications that are PA-DSS Validated.
Merchants with payment application systems connected to the Internet and no electronic cardholder data storage can complete SAQ C. If the Payment Application stores card numbers, then the Merchant must complete SAQ D.
SAQ C-VT: If you are a merchant that uses payment applications or software provided AND hosted by another company then you are eligible for the SAQ C-VT. The VT stands for Virtual Terminal.
Merchants that use a web-based virtual terminal, with no local electronic storage of cardholder data are eligible for SAQ C-VT.
SAQ D: If you are a merchant who uses self-hosted and/or self-developed payment applications to process cardholder data, then you must complete the SAQ D. This SAQ is the most extensive and covers all aspects including networks and systems infrastructure, development policies, and a myriad of other security topics.
All Merchants not included in descriptions for SAQ’s A-C above and all Service Providers eligible to complete an SAQ must use SAQ D.
SAQ P2PE-HW: This is the new Point-to-Point Encryption (P2PE) SAQ, which Merchants will be eligible to use if they properly implement the solutions offered by a validated P2PE Solution Provider. As of the writing of this blog, there are no validated P2PE Solution Providers. However, Bluefin is currently being audited for our P2PE hardware-based solution and we expect to be completed in a couple of months.
Merchants who use a hardware payment terminal in conjunction with a validated P2PE solution only, and who do not store cardholder data electronically are eligible for the SAQ P2PE-HW.