The SAQ B is designed for merchant environments where all cardholder data is processed using standalone Point-of-Interaction (POI) terminals connected via an analog phone line.
The SAQ-B is one of the simplest self-assessment questionnaires (SAQ) available to merchants. This SAQ is designed for merchant environments where all cardholder data is processed using standalone Point-of-Interaction (POI) terminals connected via an analog phone line.
Likely due to the simplicity of this type of payment channel and the relatively unchanged threat landscape for analog connections, very few changes were made to the SAQ-B during the transition to PCI DSS version 4.0.
This post will highlight changes made to the SAQ-B version 4.0 and provide guidance on how to comply with listed requirements.
The qualifying criteria list for the SAQ-B remains relatively unchanged from version 3.2.1. Some minor wording changes were made to clarify the qualifying criteria, but the substance of the list remains the same.
To qualify to use the SAQ-B, merchants must be either using an imprint/knucklebuster machine to take payment data on paper (which is not really done anymore) or they need to be using a stand alone payment terminal connected via an analog phone line. The terminal cannot be connected to an IP network–the SAQ-B-IP would be used for that scenario–nor can the merchant transmit or store cardholder data electronically.
When the PCI SSC updates the Self-Assessment Questionnaires, they will sometimes choose to include existing PCI DSS requirements that had not been part of a particular SAQ in the past. During the transition to version 4.0, only one requirement was added to the SAQ-B that was not there in version 3.2.1.
One thing to keep in mind is that this requirement is not future-dated. This requirement will need to be validated when performing an assessment using version 4.0 of the SAQ-B.
The following existing PCI DSS requirement was added to the SAQ-B in version 4.0:
Well-documented security policies and procedures can help merchants maintain a PCI DSS-compliant environment if employees working in the environment are aware of policies and procedures that apply to their job responsibilities. PCI DSS requirement 3.1.1 focuses on ensuring policies and procedures related to storage of cardholder data are up to date and are distributed to affected parties.
A merchant should have a defined data retention policy that prohibits any electronic storage of cardholder data within the merchant environment and defines data retention and data destruction procedures for any physical media containing cardholder data.
See also: SecurityMetrics PCI Guide
No new future-dated requirements were added to the SAQ-B.
The SAQ-B pulls controls from Requirements 3, 7, 9, and 12 of the PCI Data Security Standard. Since there is very little technology involved in an SAQ-B merchant environment, most of the controls listed in this questionnaire are focused on policies and procedures in place to ensure the physical security of the POI terminal(s) and any cardholder data on file processed or stored by the merchant.
As stated earlier, for Requirement 3, merchants will need to have a data retention policy in place that defines policies and procedures for stored cardholder data. Merchants will need to ensure that sensitive authentication data is not being stored, either by their POI terminals or on file, after the payment has been authorized (Req 3.3). Sensitive Authentication Data (SAD) includes full track data (data held on the magnetic stripe and the chip on the customer’s card), Card Verification Codes (the 3 or 4-digit number printed typically on the back of the customer’s card), and PIN-block data (typically used in debit card transactions). If CVC is collected by the merchant, these codes need to be shredded or blacked out after the payment is authorized.
To comply with Requirement 3.4, merchants need to ensure that the credit card number (PAN) is masked whenever it is displayed. For most SAQ B-IP merchants, the only display of PAN will be the receipt that is printed out of the POI terminal. For PCI DSS compliance, merchants should ensure the receipt never displays more than the BIN and last four digits of the PAN. For US-based merchants, only the last four digits of the customer’s credit card number should be displayed. This will help ensure compliance with both PCI DSS and FACTA (The Fair and Accurate Credit Transactions Act).
God only knows why the council kept Requirement 7.2.2 in the SAQ-B. The intent of this requirement is to ensure that privileges assigned to user accounts are based on a user's job function and that the assignments of user rights follow the principle of least privilege. In over a decade of field experience as a QSA, I have yet to see one analog terminal with user accounts of varying privilege. There will often be a passcode to prevent some configuration changes but these are typically controlled by the terminal provider and not by the merchant.
If merchants store cardholder data on file, they will need to ensure this data is stored securely and properly destroyed once no longer needed (Req 9.4). Merchants also need to have processes in place to prevent and identify physical tampering of POI terminals (Req 9.5). This would include maintaining an inventory of POI terminals, performing periodic inspections of the terminals, and training staff to be aware of suspicious behavior around the terminals and to report suspicious behavior or signs of tampering to appropriate personnel.
In Requirement 12 we see that the information security policy must be reviewed at least annually and updated as needed (Req 12.1.2). Employees working in the CDE should review and acknowledge related policies annually and receive formal security awareness training at least annually (Req 12.6.1). Merchants are also required to maintain a list of any third party service provider (TPSP) who has access to the merchant’s cardholder data or can affect the security of their CDE (Req 12.8). For each listed provider, the merchant should have a written agreement where the TPSP acknowledges their responsibility to protect the data they are processing on behalf of the merchant. The merchant is also responsible to verify that each provider is maintaining their own PCI DSS compliance.
We finish up the SAQ-B with a requirement that the merchant has an incident response plan in place to address any suspected or confirmed security incident.
Version 3.2.1 of the PCI DSS will be retired on March 31, 2024. After that date, merchants performing self-assessments will be required to use version 4.0 of the Self-Assessment Questionnaires.
Since so few changes have been made to the SAQ-B v4.0, there is little reason for merchants who use the SAQ-B to validate their compliance to wait to adopt the new standard.
.svg)
