Self-Assessment Questionnaires (SAQs) are validation testing for merchants who accept card payments, as required by Payment Card Industry Data Security Standard (PCI DSS), the industry’s regulatory body. Merchants are obliged to take the SAQ chiefly for compliance reasons, and businesses that ignore the assessment or turn-in incorrect submissions might be penalized by the PCI DSS, or are vulnerable to risks of data theft.
The PCI DSS in its latest version 3.0/3.1 has updated the number of SAQs available; at present, there are 9 types of SAQs for merchants to choose from, depending on how they process transactions and handle card information. They are discussed below:
Merchants who accept payments when a card is physically not present to them have to take SAQ A. Typically, these businesses outsource their payment processing to a third-party and hence, don’t store any card information with them. In PCI lingo, they are known as card-not-present (CNP) merchants who transact most often through e-commerce or mail order/telephone order (MOTO).
An important thing for merchants falling in this category is that their outsource partner should also be PCI compliant.
One of the latest additions to the list, this is an extension of SAQ A with some difference. Merchants who outsource their payment processing partially but have some control over the process have to take SAQ A-EP. Because of the PCI update, many vendors who took SAQ A are now required to take SAQ A-EP.
Much like SAQ A, this requirement only applies to e-commerce scenarios where businesses don’t store customer data.
This SAQ type is not applicable to e-commerce channels, because it governs brick-and-mortar businesses that employ imprint-only machines or isolated terminals that are connected to a phone line for processing payments. The vendor might store customer/card information in hard copies, but not in digital formats.
Although the SAQ B type doesn’t apply to e-pay channels, it’s common for businesses falling under this category to perform MOTO payments.
SAQ B-IP is not applicable to e-commerce channels, but apply to merchants that handle in-person card transactions or MOTO requests. Also an addition to the latest PCI Compliance guidelines, SAQ B-IP is for those businesses who process card payments over an IP connection through Point-Of-Interaction (POI) devices.
A catch for vendors under this category is that their payment devices should be kept in isolation from other devices. Also, the vendors don’t store card information electronically.
In simple words, SAQ C is for merchants who handle payment requests over internet connection and do not keep card information electronically. SAQ C does not apply to e-commerce channels, but mostly to small-size businesses who use payment application to process a card payment.
A distinct difference of SAQ C from other SAQs is that the businesses in this category handle either in-person payments or CNP, MOTO payments.
P2PE stands for Point-to-Point Encryption. SAQ P2PE, also known as P2PE-HW, is also a latest addition to the PCI update, and is applicable to vendors who handle card payments through P2PE-validated processing terminals.
This SAQ type is not applicable to e-commerce channels.
SAQ D is a panacea for businesses who fail to meet criteria for other types of SAQs. Apart for being a validation assessment for vendors, SAQ D is the only type that applies to service providers for being PCI compliant. However, it is considered one of the toughest SAQs given that a merchant has to meet over 200 requirements that encompass the entirety of PCI DSS regulations.
What makes it primarily different from other SAQs is that SAQ D applies to vendors who store card information during a payment process.
That’s the complete list for all types of SAQs made available by PCI DSS in its recent version. SAQs are an important part of payment security and serves a more important purpose than just being a standard for compliance. For this very reason, card brands and payment processing parties insist on working with vendors who have taken a relevant SAQ as a proof of caution and data security.
Breach in Website Security?