A Thing
The Green SheetGreen Sheet

The Green Sheet Online Edition

March 24, 2008 • Issue 08:03:02

SAQ changes: Knowing them is imperative

By Ross Federgreen and Ken Musante
Humboldt Merchant Services

In the payments industry, extra efforts are constantly being made to ensure small and mid-sized merchants maintain compliance with the Payment Card Industry (PCI) Data Security Standard (DSS). Policies and regulations are being created, or revised, to best secure today's payments world.

On Feb. 8, 2008, the PCI Security Standards Council announced the latest version of the PCI DSS Self Assessment Questionnaire (SAQ), known as SAQ version 1.1. The revamped SAQ represents a complete evolution from the previous one.

The most critical change under the new format is the categories merchants fall into are now determined by how they process transactions, not by transaction volume. Also under the new rule, an attestation statement is required from all merchants. The statement serves to certify that merchants are eligible to perform and have completed the appropriate SAQ.

The category or validation level that merchants fall into determines which SAQ must be completed. There are five validation levels and associated SAQs.

In addition, it is important to note that a certain number of merchants and service providers are required to undergo on-site examinations based upon a series of factors, described in the PCI SAQ Security Audit Procedure, or as required by their acquirers or payment brands.

Security launch

The PCI DSS was first promulgated in 2004 as a common set of requirements for merchants to fulfill to be compliant with each of the card brands. Prior to that, each of the card brands had its own compliance program.

The initial PCI DSS categorized merchants purely by their number of transactions. There was a small distinction between e-commerce and card-present transactions, but otherwise the system was purely quantitative.

Security professionals quickly realized that to truly secure merchants, the requirements should be driven by qualitative rather than quantitative terms. In other words, the SAQ should focus on how merchants process their transactions. So was born the basis for the new SAQ and validation levels.

The only distinguishable process characteristic used in the original SAQ was whether the merchant processed e-commerce transactions.

Also, a card brand was able to sign a merchant to a higher level based upon a past breach or indiscretion. SAQ 1.1 is a fresh approach that speaks to the inherent risk posed by merchants' activities and relative security.

Two major concepts were taken into consideration for SAQ 1.1: Make the set of questions more pertinent to merchants, and align the questions more directly with the specific components of the standard. The result of this effort yielded SAQ 1.1 sections A through D.

In the new SAQ, each section increases in length, and the number of questions swells from 11 in A to 227 in D.

Each segment represents a building block of complexity, and therefore all of the questions that appear in the shorter questionnaire emerge in the next longer questionnaire and so on. For example, all of the inquiries in section A will appear in sections B through D.

It is important to keep in mind that for merchants to justify a specific SAQ, they must attest to the SAQ's fact pattern as it pertains to the handling of their cardholder data.

Four plus one more

SAQ 1.1 divides merchants into five validation levels. Even though there are technically five levels, two utilize the same SAQ (levels 2 and 3 use section B).

SAQ validation level 1 is for merchants who transact in a card-not-present manner and who outsource all cardholder functions.

For example, this level would pertain to an e-commerce merchant utilizing a PCI compliant shopping cart, hosting service and payment gateway.

Validation level 2 merchants use imprint-only technology with no electronic cardholder data storage or transmittal. These merchants still physically send their drafts to their processors.

Merchants under validation level 3 use a stand-alone dial-up terminal with no electronic storage.

Validation level 4 merchants have payment application systems that connect to the Internet and have no electronic cardholder data storage. Internet Protocol terminal merchants fall into this validation level.

All other merchants not included in descriptions for validation levels 1 through 4 and all service providers defined by a payment brand as eligible to complete a SAQ fit under validation level 5. Moreover, merchants must attest to the completion of the appropriate SAQ based on the determined validation level. There are specific statements merchants must confirm in writing. The attestation form is a vital component of the SAQ.

For validation level 1, section A, the following needs to be confirmed:

  • The merchant handles only card-not-present (e-commerce or MO/TO transactions).
  • The merchant does not store, process or transmit any cardholder data on the business's premises, but relies entirely on a third party to handle these functions.
  • The merchant has confirmed that the third party handling storage, processing and/or transmission of cardholder data is PCI DSS compliant.
  • The merchant retains only paper reports on receipts with cardholder data, and these documents are not received electronically.
  • The merchant does not store any cardholder data in electronic format.

For validation level 2, section B, the following needs to be confirmed:

  • The merchant uses only an imprint machine to take customers' payment card information.
  • The merchant does not transmit cardholder data over either a phone line or the Internet.
  • The merchant retains only paper copies of receipts.
  • The merchant company does not store cardholder data in electronic format.

For validation level 3, section B, the following needs to be confirmed:

  • The merchant uses only dial-out terminals (connected via a phone line to the merchant's processor).
  • The stand-alone, dial-out terminals are not connected to any other systems within the merchant's environment.
  • The standalone, dial-out terminals are not connected to the Internet.
  • The merchant retains only paper reports or paper copies of receipts.
  • The merchant does not store cardholder data in electronic format.

For validation level 4, section C, the following needs to be confirmed:

  • The payment application system is on a personal computer that is connected to the Internet.
  • The payment application system is connected to the Internet to transmit cardholder data.
  • The merchant has a payment application system and an Internet connection on the same device.
  • The payment application system/Internet device is not connected to any other systems within the merchant's environment.
  • The merchant retains only paper records or paper copies of receipts.
  • The merchant does not store cardholder data in electronic format.
  • The merchant's payment application software vendor uses secure techniques to provide remote support to the payment application system.

For validation level 5, section D, the following needs to be affirmed:

  • A confirmation has been obtained from the POS vendor that the POS system does not store sensitive authentication data after authorization.
  • The merchant has read the PCI DSS and recognizes the requirement to fully maintain PCI compliance at all times.
  • No evidence of magnetic stripe, card authentication value 2, card verification code 2, card identification number or card verification value 2 data or PIN data storage subsequent to transaction authorization is found on any systems reviewed during the assessment.

In addition to these individual attestation statements and driven by the validation level and the specific SAQ, various work-around plans along with estimated completion times must be given. These may include - in the case of validation level 5 - an action plan for noncompliance status, requiring an individual sign-off for each of the following:

  • Installation and upkeep of a firewall configuration to protect cardholder data
  • No use of vendor-supplied defaults for system passwords and other security parameters
  • Protection of stored cardholder data
  • Encryption of cardholder data transmission across open public networks
  • Use of and a regular update of anti-virus software
  • Development and support of secure systems and applications
  • Restriction of access to cardholder data by businesses that need to know
  • Assignment of a unique identification number to each person with computer access
  • Restriction of physical access to cardholder data
  • Regular testing of security systems and processes
  • Maintaining information security policies

Clearly, this system is very complex and nuanced. Each ISO must be highly knowledgeable in the specifics of, at a minimum, the validation levels, the various SAQ requirements, the specifics of the attestation statements, and aware of the cases in which corrective plans are necessary as part of the individual merchant filing.

The primary intent and purpose of the PCI DSS is to provide framework and guidance for merchants to accomplish the many tasks necessary to protect sensitive cardholder data. The critical issues ISOs face include how to attract new businesses while simultaneously educating merchants on the rules and motivating them to continue to comply.

Many ISOs today, while vested in these concepts, lack the tools necessary to accomplish the goals effectively and efficiently. So, the questions that need to be asked are: What does the ISO need? How does the ISO measure success? Stay tuned. More revisions are sure to come. end of article

Ross Federgreen is founder of CSRSI, The Payment Advisors, a leading electronic payment consultancy specifically focused on the merchant. He can be reached at 866-462-7774, ext. 23, or by e-mail at rfedergreen@csrsi.com. Ken Musante is President of Humboldt Merchant Services. Contact him at kmusante@hbms.com or by phone at 707-269-3200.

The Green Sheet Inc. is now a proud affiliate of Bankcard Life, a premier community that provides industry-leading training and resources for payment professionals. Click here for more information.

Notice to readers: These are archived articles. Contact names or information may be out of date. We regret any inconvenience.

Prev Next
Facebook
Twitter
LinkedIn

Current Issue

View Archives
View Flipbook

Table of Contents

Views
Education
New Products
Departments
A Thing