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:

Objectives	Top level Requirements
Build and maintain a secure network and systems	1. Install and maintain network security controls 2. Apply secure configurations to all system components
Protect cardholder data	3. Protect stored account data 4. Protect cardholder data with strong cryptography over open, public network
Maintain a vulnerability management program	5. Protect all systems and networks from malicious software 6. Develop and maintain secure systems and software
Implement strong access control measures	7. Restrict access to system components and cardholder data by business need to know 8. Identify users and authenticate access to system components 9. Restrict physical access to cardholder data
Regularly monitor and test networks	10. Log and monitor all access to system components and cardholder data 11. Test security of systems and networks regularly
Maintain an information security policy	12. Support information security with organizational policies and programs

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:

Questionnaire	How do you accept payment cards?
A	Card-not-present merchants (e-commerce or mail/telephone-order) that have fully outsourced all cardholder data functions to PCI DSS–compliant third-party service providers, with no electronic storage, processing or transmission of any cardholder data on the merchant’s systems or premises. Not applicable to face-to-face channels.
A-EP	E-commerce merchants who outsource all payment processing to PCI DSS–validated third parties, and whose website doesn’t directly receive cardholder data but can impact the security of the payment transaction. No electronic storage, processing or transmission of any cardholder data on the merchant’s systems or premises. Applicable only to e-commerce channels.
B	Merchants using only imprint machines with no electronic cardholder data storage and/or standalone, dial-out terminals with no electronic cardholder data storage. Not applicable to e-commerce channels.
B-IP	Merchants using only standalone, PTS-approved payment terminals with an IP connection to the payment processor, with no electronic cardholder data storage. Not applicable to e-commerce channels.
C-VT	Merchants who manually enter a single transaction at a time via a keyboard into an Internet-based virtual terminal solution that is provided and hosted by a PCI DSS–validated third-party service provider. No electronic cardholder data storage. Not applicable to e-commerce channels.
C	Merchants with payment application systems connected to the Internet; no electronic cardholder data storage. Not applicable to e-commerce channels.
P2PE-HW	Merchants using only hardware payment terminals that are included in and managed via a validated, PCI SSC–listed P2PE solution, with no electronic cardholder data storage. Not applicable to e-commerce channels.
D (merchant)	For merchants: All merchants not included in descriptions for the above types.
D (service provider)	For service providers: All providers defined by a payment card brand as eligible to complete a Self-Assessment Questionnaire.

Source: https://www.pcisecuritystandards.org/pci_security/completing_self_assessment

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