While increasingly coming under attacks, small merchants can ill afford heavy IT security investments. This makes them extremely susceptible to cyber frauds and security breaches involving Personally Identifiable Information (PII), which includes cardholder data.

In this context, the PCI DSS self assessment questionnaire (SAQ) is a validation tool that assists merchants and service providers evaluate payment card industry data security standard (PCI DSS) compliance levels. If a merchant deals with card data, filling an SAQ is mandatory.

Organizations eligible for SAQ are not mandated

to undergo an on-site PCI DSS compliance audit but it’s highly recommended. They only need to fill an SAQ and an attestation of compliance (AOC).

There are multiple validation types of PCI DSS SAQ. Although not required, it is recommended that a QSA be consulted when performing gap analysis and remediation, prior to filing the SAQ to ensure cardholder data environment security.

Points of risks

When defining risk prior to filling up an SAQ, the following should be addressed by merchants:

Network security: Small organizations usually have weak network security controls. Network security must be hardened. Securing wireless access points is critical. Merchants must get their external IP addresses scanned by an approved scanning vendor (ASV), while also ensuring that machines running payment card applications are scoped separately.
Application security: The applications used to process cardholder data applications must undergo vulnerability assessment and penetration testing to ensure application are significantly harderened and reduce exposure of risk.
Securing points of transaction: It is important to use secure card readers. Data gathered at the point of sales (POS) and electronic data capture (EDC) terminals needs to be secured – ensuring secure connectivity to acquirer in the case of EDCs and secure storage in the case of POSs.
Avoid paper records: Small merchants usually keep paper records of cardholder data to avoid charge-backs on card-not-present transactions. Such practices must be avoided and merchants must avoid storing authentication data/card holder data in any form – paper or electronic.
Access to cardholder data: Access to cardholder data should be controlled on the basis of business requirement. All employees do not require access to sensitive PII data.

SAQ validation types

Small organizations are required to adhere to PCI DSS compliance, since they deal with card data – directly or indirectly – and should fill the SAQ as per the category they fall under. The acquirer and/or payment gateway may assist an organization determine its relevant category. The SAQs are divided into five sections by the PCI DSS council: A, B, C, C-VT, and D.

Detailed information on SAQ validation types, including conditions for eligibility are available on the PCI Council Website. Let’s briefly look at the various validation types.

1) SAQ A: Card -not-present transactions with all PCI data functions outsourced 
SAQ A addresses the requirements of organizations that only retain paper receipts of the cardholder data and do not store or process cardholder data. This applies to only card, and not current transactions like e-commerce, mail/telephone, or face-to-face orders.
At the time of validation, the AOC must confirm that the third party is PCI DSS compliant, and that the cardholder data is not stored in electronic format.

2) SAQ B: Transactions involving only imprint machines or only standalone, dial-out terminals
SAQ B addresses the needs of organizations that process cardholder data through imprinting machines or standalone terminals. These machines are usually used by the hospitality industry. The card may or may not be available for transactions, and cardholder data should not be stored in electronic format.

3) SAQ C-VT: Transactions through web-based virtual terminals
SAQ C-VT is for organizations that process cardholder data only through isolated virtual terminals on personal computers over the Internet. A virtual terminal is web-browser based access to an acquirer, processor or third party service provider website to authorize card transactions. Virtual terminals do not read data directly from a card and the transaction data is entered manually. The card may or may not be available for these transactions.

4) SAQ C: Transactions using payment application systems connected to the internet
SAQ C deals with organizations whose payment application systems need to connect to the Internet to transmit cardholder data. This could be through a POS terminal or a payment application system. The card may or may not be available.

5) SAQ D: All other service providers and merchants classed by a payment brand as SAQ eligible
SAQ D concerns organizations that do not fall into any of the above categories, but have been deemed eligible by a payment brand to complete an SAQ.

Merchants should consult with acquirers to completely understand their legal liabilities in their particular jurisdiction.

---

About the author: Nitin Bhatnagar is the Senior Consultant/ Global Head - Business Development and Marketing - Information Security Services, with SISA Information Security Pvt. Ltd. He is a frequent contributor to searchSecurity.in. He has more than four years of experience in information security domain. Nitin has been involved in several intellectual property rights and application security related projects. He holds a master’s degree in information security from IIIT - Allahabad. All view in this article are the author's own.

(As told to Varun Haran)

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.