How to Choose the Right PCI DSS Self-Assessment Questionnaire for Your Business

The fact is, it's not just your size or your revenue that influences which SAQ you should use (if any). The primary consideration should always be how your business operations interact with card data: how payment information flows through your systems, and what your software and hardware do with that data.

The SAQ isn't about your size, it's about your data flows

There is a common misconception that small business owners will get an easy self-assessment questionnaire (SAQ) and big ones get hit with the long version. But the PCI Security Standards Council didn't create four SAQs that correspond to the four merchant levels that way. The SAQ you must choose is based solely on whether you store, process, or transmit cardholder data, and through which systems that happens.

A five-employee online store that uses a fully outsourced payment page may be eligible to take the shortest SAQ. A 200-store retail chain with pristine, segmented processing systems may also be on that low-impact, best-behavior track. Meanwhile, a small business with one sloppy web payment page or one unsegmented processing network could get steered into the longest, most onerous SAQ D, even if they only do a few credit card transactions a year. Revenue and personnel numbers don't play a part in SAQ eligibility.

Walking through the common SAQ types

Here is a simple guide to narrow down options based on your current state.

If you have zero electronic storage of card data and you've fully outsourced all payment processing to a validated third party, you're an ideal SAQ A candidate.

For a similar scenario where you've outsourced to a validated third party but you've maintained some e-commerce website and are able to affect how your customers get to and interact with the payment page, usually via use of an iFrame or a redirect the merchant implements, use SAQ A-EP.

If all you're using is a parchment carbons machine or a standalone terminal and you're not storing any card data electronically, you could be eligible for SAQ B.

Instead, if all you're using is that same standalone, PTS-approved PIN entry terminal but it's connected to your network or elsewhere via the internet, then use SAQ B-IP.

If your website allows you to log into a web-based program where you key in the details of your customer's payment card over the internet, consider SAQ C-VT.

SAQ C is used for merchants with POS systems that are directly connected to the internet that do not store card data electronically.

Finally, there's SAQ D, which is what all Level 1 merchants use and any situation where you don't meet the above criteria. Many merchants in borderline situations bring in pci compliance services to confirm scope and verify which SAQ actually fits their setup before committing to the wrong one.

Getting it wrong costs you either way

Choosing to complete a shorter Self-Assessment Questionnaire (SAQ) than the one you truly qualify for is sometimes viewed as a compliance shortcut, a simple way to minimize the time and expense involved. Unfortunately, it's not a victimless decision. You leave gaps in your security controls that were simply not part of the SAQ you selected, leaving associated vulnerabilities unaddressed until something starts going wrong. Meanwhile, selecting a longer SAQ results in spending time, money, and personnel on controls you didn't need to implement – and, worst of all, exposing the pieces of your environment that do pose a risk.

It's not just a theoretical problem. According to Verizon's 2023 Payment Security Report, only 28.7% of organizations maintained full PCI DSS compliance throughout 2022, falling significantly from the 44.9% that did so the year before. Many of those non-compliant cases tie back to the organization's selection of a shorter SAQ or complete oversight of the PCI Card Production Life Cycle mandate.

Segmentation decides more than people realize

Network segmentation plays a bigger role in your SAQ than you might expect. If the part of your network that handles card data is sufficiently walled off from the rest of it, you can qualify for a much shorter SAQ. Even if you're not, but you assume you are because you haven't done the necessary checks to confirm the full scope of your card data environment, you end up in SAQ D by default. It's really a no-win scenario since you can't know what you're not protecting until you're breached.

P2PE also helps with this, since the P2PE application solution provider takes a lot of the CDE out of your hands for you. If you actually don't have card data on your systems in the first place, and you have a P2PE attestation certified by a QSA to this effect, you might not even have to do an SAQ.

Your acquirer has the final say

All of this occurs in a larger context. Your acquiring bank or payment processor makes the final call on whether to even allow the SAQ classification you'd like to use in the first place, and they verify your Attestation of Compliance when you're done. Plus, each card brand (and your processor, and your bank) has different deadlines for compliance, required validation types, levels, and reporting requirements on top of that. Make sure the SAQ you have in mind is acceptable to your acquirer before diving in with it. Submitting the wrong one means redoing the work, and it can hold up your Attestation of Compliance at a point where that social contract really matters.

When to bring in outside help

If your environment is on the fence – whether due to a custom payment page, multiple sales channels, a network update, or all of the above – trying to self-determine which SAQ to tackle is hazardous. A QSA can review your environment and let you know your SAQ eligibility right up front. Many merchants in this category engage a QSA to confirm scope, verify segmentation, and compare the particulars of the requested SAQ to what's realistically happening with their processing or storing of cardholder data so they don't put the cart before the horse.

Getting the SAQ right the first time saves you from redone paperwork, exposed vulnerabilities, and wasted effort on controls you never needed. It's worth the extra hour of verification before you start filling anything out.