PCI and the Tale of Alphabet Soup

The following article has been revised on April 12, 2022 to reflect updates to PCI DSS 4.0.

If you are asked by your payment card processor to complete an SAQ, you may think, “SA what?” (It’s a “self-assessment questionnaire.”) Even worse, your processor may inform you that, unless you complete an SAQ by year end, you’ll be charged thousands of dollars in penalties for every month you haven’t submitted one. These are all challenging requirements for any organization, from small mom-and-pop shops to the largest enterprises.

To make matters more complicated, when you start to research the SAQ, you will find that there are nine choices with varying letters behind them. These are all common scenarios Weaver helps our clients with. This overview of the SAQ process is intended to help you understand what’s involved and give you some techniques for picking the correct option for your organization.

First, some background on the Payment Card Industry (PCI) Data Security Standard (DSS). In 2004, the PCI DSS was created by the five founding payment brands — VISA, MasterCard, American Express, JCB and Discover — to codify requirements for cardholder data protection. The DSS is maintained by the Security Standards Council (SSC), and we are currently on version 3.2.1 and 4.0. Version 3.2.1 will expire on March 31, 2024 at which time all assessments will be required to be on version 4.0. The PCI DSS applies to companies that store, process, transmit or could affect the security of cardholder data. It includes six objectives and twelve top-level requirements. The objectives are described by PCI as follows:

You may find relief in knowing that not all requirements will apply to your organization. The scope of requirements varies depending upon how your organization stores, processes or transmits cardholder data.

The SAQs were designed to help organizations that process fewer credit card transactions annually — usually less than six million, but this varies by payment brand — to self-assess their DSS compliance. The questionnaires themselves are a series of “yes” or “no” questions that organizations answer based on their compliance with each applicable requirement. In any instances of noncompliance, the organization must document a remediation plan and timeline.

In total, there are over 250 requirements within the DSS, not including the Appendix requirements, which apply only in certain instances. However, different SAQs will be required, and choosing the wrong one may mean trying to fulfill more requirements than necessary. There are nine different SAQs to choose from, and each one is relevant to very specific payment processing environments:

When selecting an SAQ, first identify the scope of your cardholder data environment. That environment includes any technology, person or process that stores, processes, transmits or affects the security of cardholder data. By “affects the security of cardholder data,” the DSS means systems that connect to, provide security to, or provide segmentation to systems that store, process or transmit cardholder data — secondhand access, in other words. That looks like a large number of systems for most companies, but proper segmentation through techniques like firewall access control lists (ACLs) and VLAN implementations dramatically reduce the number of systems in scope.
 

Once you define the SAQ scope, you can begin to look at each criteria. The place to start is the table of SAQ applicability, above. Each questionnaire has listed criteria that outline typical payment processing scenarios from card-not-present telephone orders, and card-present swipe/tap/insert to e-commerce over the web transactions. In addition to the criteria listed above, it is helpful to read the “Before You Begin” section in each SAQ. These outline specific requirements to ensure the specified SAQ applies to your environment. Generally, for most organizations with a limited payment card foot print, one of the first seven SAQs listed above is sufficient; this usually means a smaller number of requirements are in-scope. However, for organizations that have larger, more complex payment processing channels or have not implemented segmentation within their environments, the SAQ-D is applicable, which deems all PCI DSS requirements as in-scope. So, it is important to work with your payment processor or a QSA to help determine which SAQ applies.

It is important to remember that just because a requirement is considered in-scope in the SAQ, that doesn’t always mean the requirement applies to your organization. For example, Requirement 9 relates to the physical security of cardholder data and systems. However, if your organization only accepts cardholder data through a website that is hosted at a third party provider and no cardholder data is retained in your offices, Requirement 9 may not be applicable. In this case, the SAQ has a section for explanation of non-applicability, which you could use to reduce your compliance burden.

As you can see, scoping your cardholder data environment, choosing the correct SAQ and completing the SAQ can be a daunting task. If you choose the wrong questionnaire or scope your cardholder data environment incorrectly, you could increase your company’s overall security and liability risk.

(If you want to dig into PCI requirements and guidelines, there are more resources in the PCI Document Library.)

Weaver has experience helping clients complete the SAQ, as well as providing the more comprehensive PCI Report on Compliance (ROC) and other PCI consulting services for many clients, ranging from Fortune 50 cloud providers to small merchants. To find out how we can help your organization achieve and maintain PCI DSS compliance, or help strengthen your security program in general, contact us for more information.

© 2019