Choosing the right PCI DSS SAQ for your self-assessment
If your business stores, processes, or transmits cardholder data from at least one of the leading card networks (e.g. Visa, Mastercard, etc.), then you must prove Payment Card Industry Standard Data Security Standard (PCI DSS, or PCI) compliance in one way or another.
This post will look at the Self Assessment Questionnaire (SAQ), a tool used by card-accepting organizations and third-party service providers (TPSP, or service providers) to validate the necessary controls required for PCI compliance levels 2-4. (Level 1 organizations must submit a PCI DSS Report on Compliance (ROC) to validate their controls).
What are the PCI Levels?
Levels bucket and assess merchants based on their risk profile. For example, the cardholder environment (CDE) of large merchant processing 6 million transactions annually is a much juicy target for hackers than a small business processing only 1,000 transactions. In the context of this blog, the levels tells a merchants which methods of assessment they may use to validate its PCI compliance.
While the exact level varies between card brands and other factors, the generally accepted thresholds look a little something like this:
- Level 1: Processing over 6 million transactions per year
- Level 2: Processing 1 million to 6 million transactions per year
- Level 3: Processing 20,000 to 1 million per year
- Level 4: Processing fewer than 20,000
What is an SAQ?
An SAQ is a form provided by the PCI Security Standards Council (PCI SSC) to assist organizations in validating PCI DSS. There are nine These questions range from “Is a list of service providers maintained?” to “Do coding techniques address insecure cryptographic storage?”.
Organizations download SAQs through the PCI website or use the form provided by an organization’s acquiring bank or payment service provider (PSP; e.g., Stripe or Adyen).
There are multiple versions of the PCI DSS SAQs. Each type of SAQ has been tailored to meet common implementation scenarios, allowing organizations to validate a much smaller scope of the over 300 PCI requirements. Which SAQ to use and how many questions you must answer depends on where and how your organization processes, stores, or transmits cardholder data. More on this in a sec.
Who fills out the SAQ?
For levels 3 and 4, most organizations will use a person in compliance, risk, or security responsible for your PCI efforts. For level 2, your acquiring bank may require an Internal Security Assessor (ISA) complete its annual assessment. ISAs receive their certification through a PCI SSC training program and conduct formal assessments on their own organization.
While organizations may also engage a Qualified Security Assessor (QSA) to assess Level 2 compliance, these external and independent assessors are more well-known for auditing and reporting on compliance for Level 1 organizations.
Once completed, the organization must submit the SAQ to their acquiring bank directly or their PSP that processes its credit card and debit card payments.
Which PCI DSS SAQ should you choose?
The best way to determine which SAQ is right for you is ask yourself a few simple questions:
Do you only accept card-not present transactions (i.e., receive payments without the physical presence of the actual cardholder)?
- If yes, you'll likely be filling out the SAQ A, its sister the SAQ A-EP, or the SAQ D.
- If no, you accept payments face-to-face (i.e., card-present) or a hybrid of card-present and card-not-present, you'll fill out SAQ B, SAQ B B-IP, SAQ C-VT, SAQ C, SAQ D, or SAQ P2PE HW.
PCI DSS Self Assessment Questionnaire (SAQ) for card-not-present
Unlike brick-and-mortar stores, organizations can remove a significant amount of scope by using solutions offered by service providers. These could be payment service providers, like Stripe, or cardholder data environments and tokenization platforms, like Basis Theory.
These service providers offer organizations the required infrastructure and tools to get the same outcome that storing, processing, and transmitting cardholder data provides. These abstraction services, like Basis Theory, satisfy nearly 90% of PCI’s required controls and is the main reason the SAQ A and SAQ A-EP have so few questions. (The logic is that the service provider has already proven its compliance posture via its PCI assessments).
What is an SAQ A?
The PCI SAQ A features 24 questions and can only be filled out by organizations that have fully outsourced all cardholder data functions to PCI DSS-compliant third-party service providers. That means none of your systems store, process, or transmit any plaintext cardholder data.
The main ways to achieve this limited scope:
- Use a link to redirect a customer to the third-party service provider to complete a purchase,
- An iframe and form inputs hosted by the service provider that the organization embeds into its existing website or application, or
- Sell all your goods and services through a compliant third-party marketplace, like Etsy, and use their payment processing engine.
What is an SAQ A-EP?
Like SAQ A, SAQ-A EP only applies to card-not-present transactions and organizations that have outsourced their payment processing to a PCI DSS-compliant third-party service provider. Unlike the SAQ A, the SAQ A-EP organizations play some role in directing the customer's payment information to the service provider.
This might look like a merchant-controlled checkout that collects payment information online and uses an API to post cardholder data directly to its service provider’s system. The same is valid for e-commerce merchants that use a transparent redirect service where scripts facilitate the transmission of payment information from the customer’s browser to the PCI-compliant service provider.
In these situations, you may not store the plaintext value on your servers, but you do create additional system risk. As such, more questions and controls needed to be validated to be considered PCI compliant.
What’s the difference between an SAQ A vs. SAQ A-EP?
The table below serves as a quick SAQ A vs. SAQ A-EP reference and was inspired by PCI's SAQ guide.
SAQ A All cardholder data functions completely outsourced |
SAQ A-EP Partially outsourced e-commerce payment channel |
|
---|---|---|
Applies to | Card-not-present merchants (e-commerce or mail/telephone-order)* | E-commerce |
Number of questions | 22 | 195 |
Functions outsourced to Service Provider | Originate only and directly from a PCI DSS validated Service Providers | Originates from either a) the merchant’s website or b) a PCI DSS compliant Service Provider(s) |
Third-party Compliance | Organization has validated that cardholder data is stored, processed, and transmitted using a PCI DSS compliant Service Provider. | |
Organization Systems | Never store, process, or transmit cardholder data. Organizations may store, process, and transmit tokens to their provider to avoid scope. |
When to fill out an SAQ D as a card-not-present organization?
Not all organizations and use cases fit neatly into a PSP’s existing product set or capabilities. Often, a digital business requires storing its card data to process a payment or facilitate a business operation.
For example, imagine you're an insurance marketplace selling auto policies to consumers. Today, when a customer purchases one of your policies, your system populates your PSP’s iframe and collects the payment information on your behalf. The PSP returns a harmless undecipherable token that you can store and use to reference the card for monthly charges. No problem.
Now, let’s say you plan to add another insurance partner that specializes in motorcycle insurance. This carrier, however, requires card details sent to its PSP for processing. That creates challenges for your payment workflow. While you could eject the customer out of your payment flow and into your partner’s, the disjointed experience poses a lot of risk to conversion. And unfortunately, your token is specific to you and your PSP, meaning your token is worthless to your partner’s PSP.
Suppose you want to onboard the partner and keep a unified payment experience. In that case, you’ll need to use a tokenization provider, like Basis Theory, to maintain SAQ A or SAQ A-EP eligibility. If not, you’ll need to store the cardholder data and send it in plaintext to the new PSP. In situations where your systems store the plaintext value, you’ll need to use the SAQ D—the most expansive and intensive set of questions of all the SAQ.
Of course, SAQ D may also apply to brick-and-mortar that haven’t implemented point-to-point encryption and service providers processing under a certain threshold.
PCI DSS Self Assessment Questionnaire (SAQ) for brick-and-mortar retailers
If you are a physical retailer who processes card-present transactions, then PCI SAQ A and SAQ-A EP do not apply to you. Instead, you’ll need to choose from one of these self-assessment questionnaires:
(Note: Some mail and telephone order organizations may also fall into the below categories.)
- SAQ B: Applies to face-to-face retailers using standalone payment terminals that connect to their payment processors through dial-out connections and do not store cardholder data storage. Also, if you have an imprinting machine in your business, it shouldn’t have electronic storage capabilities; otherwise, PCI SAQ B doesn’t apply to you.
- SAQ B-IP: This applies to retailers using standalone payment terminals that connect to their payment processors via the internet and do not store cardholder information. The payment terminal should be approved under the PCI-PTS program and listed on the PCI SSC website.
- SAQ C-VT: Applies to organizations that use a keyboard to record each transaction into a web-based virtual terminal solution provided and hosted by a PCI DSS-validated third-party service provider. The organization should not store cardholder information electronically.
- SAQ C: This applies to organizations that do not electronically store cardholder information and use payment application systems that are connected to the internet.
- SAQ P2PE HW: This applies to retailers who do not electronically store cardholder data and only use hardware payment terminals that are included in and managed via a validated PCI SSC-listed P2PE solution.
How will SAQs change in PCI 4.0?
PCI DSS version 4.0 is out, and although it won’t be effective until March 31, 2024, organizations should start familiarizing themselves with the updates. The standards have undergone significant changes and will require teams to re-assess and alter their compliance posture and assessment strategy.
Luckily, however, the SAQs themselves haven’t changed significantly. Let’s take a look at a few highlights.
- The qualifying criteria for SAQ A will now include call centers.
- SAQ A, which featured five requirements split into 21 specific controls, will grow to 7 requirements with 31 specific controls. This includes a new requirement for password policies that prohibit users from setting a new password that’s similar to their last four passwords.
- With PCI version 4, authenticated quarterly external vulnerability scans are now a requirement for SAQ A merchants.
These are just a few of the larger changes to come with PCI version 4. We recommend you review the official PCI DSS website documents to see all changes.
How to reduce your PCI scope?
Service providers, like Basis Theory, provide the Cardholder Data Environment (CDE) and developer tools to collect, store, and transmit this sensitive information without a PSP. By decoupling your cardholder information from your processor, you receive the flexibility and control highlighted in our insurance and SAQ D example while enjoying the time-savings and costs of filling out an SAQ A or SAQ A-EP.
Want to get started? Talk with an expert or check out our PCI Blueprint to set up your own compliant environment in as little as 5 minutes.