The PCI DSS self-assessment questionnaire (SAQ) you complete depends on how your business accepts card payments, not on your size or industry. Fully outsourced online checkout points to SAQ A. A website that influences the payment page points to SAQ A-EP. Standalone terminals point to SAQ B or B-IP. Virtual terminals point to C-VT. Anything that stores, processes or transmits card data on your own systems usually lands on SAQ D. This guide walks through each type, the questions that decide it, and how to confirm your choice before you spend time on the wrong form.
TL;DR
- The SAQ is chosen by your payment environment: who handles card data, which devices you use, and how your checkout page is built.
- Current SAQs are A, A-EP, B, B-IP, C-VT, C, P2PE, SPoC and D. Each has eligibility criteria you must meet in full.
- SAQ A and A-EP depend on payment-page design, so a change to your website can change your SAQ.
- Before you start, confirm eligibility with the organization that receives your questionnaire, usually your acquirer.
- Scope errors cause more wasted effort than the questionnaire itself. Define scope first, then pick the form.
Table of Contents
- What a PCI DSS SAQ is and who can use one
- The current SAQ types at a glance
- SAQ A: fully outsourced card-not-present
- SAQ A-EP: partially outsourced e-commerce
- SAQ B and B-IP: standalone terminals
- SAQ C-VT and SAQ C
- P2PE and SPoC: validated solutions
- SAQ D: everything else
- How the payment page and card data flow decide your SAQ
- How to confirm which SAQ applies
- Common mistakes that lead to the wrong SAQ
- Our perspective
- Get help choosing and completing the right SAQ
- FAQ
- Sources
What a PCI DSS SAQ is and who can use one
A self-assessment questionnaire is a validation tool for merchants and service providers that are not required to produce a full Report on Compliance (ROC). The ROC is completed by an external Qualified Security Assessor (QSA) or, in some cases, a qualified internal security resource. The SAQ lets an eligible organization document its own assessment against a shortened set of requirements that match its payment environment.
The PCI Security Standards Council (PCI SSC) published the SAQs for PCI DSS v4.0.1 on 15 October 2024. PCI DSS v4.0.1 itself is a limited revision released in June 2024 that provides minor updates, clarification and guidance, so the SAQ structure you may know from earlier versions still applies.
One point trips up many compliance teams. The SAQ eligibility criteria are not a shortcut for a ROC assessment. According to the PCI SSC, merchants may use SAQ eligibility criteria as a guide for scoping a ROC only if they and their QSA agree that it is an acceptable approach to securing the environment. If you are working with a QSA, settle that question with them first.
The current SAQ types at a glance
The PCI SSC's SAQ instructions and guidelines list the current types and the environments they cover. The table summarizes them in plain terms.
| SAQ | Payment environment it covers | Typical fit |
|---|---|---|
| A | Card-not-present merchants that fully outsource account data functions to a PCI DSS-compliant third party, with no electronic storage, processing or transmission on merchant systems | E-commerce or phone-order business using a hosted payment page |
| A-EP | Partially outsourced e-commerce where the merchant's website affects the security of the payment transaction | Website that controls how the payment form is built or delivered |
| B | Imprint machines or standalone dial-out terminals | Small shop with a basic terminal on a phone line |
| B-IP | Standalone, PCI-listed approved PTS POI devices with an IP connection to the processor | Retail counter with an IP-connected card reader |
| C-VT | Manual entry into a third-party virtual terminal, on an isolated device | Office staff keying in phone or mail orders |
| C | Internet-connected payment application systems | Merchant with a payment application on a networked system |
| P2PE | Validated point-to-point encryption solution with no clear-text access to account data | Merchant using a listed encrypted terminal solution |
| SPoC | Validated mobile payment solutions | Mobile acceptance on a commercial device |
| D | Other eligible merchants; eligible service providers also use D | Everything that does not fit the shorter forms |
Two cautions apply to the table. First, it is a summary, and the official criteria contain more conditions than a single row can hold. Second, you must meet every criterion of a type to use it. Meeting most of them does not qualify you.
SAQ A: fully outsourced card-not-present
SAQ A is the shortest form for e-commerce and mail or telephone order merchants. It is intended for card-not-present merchants that hand all account data functions to a PCI DSS-compliant third party, with no electronic storage, processing or transmission of account data on the merchant's own systems.
In practice, this describes a business whose customers are redirected to a payment provider's hosted page, or whose checkout is delivered inside a provider-controlled frame. The merchant's systems never see the card number.
Under v4.0.1 the PCI SSC clarified the eligibility criteria for SAQ A, and updated its completion guidance. Read the current criteria in full, particularly anything about how the payment page is embedded and how your site protects it. A site that once qualified under an older version should be re-checked, not assumed.
What keeps a merchant in SAQ A
- Your payment provider hosts the card entry fields, and your pages never receive the data.
- Your service providers are PCI DSS compliant, and you can show it.
- You hold no cardholder data on paper or in electronic form, apart from what the criteria allow.
- Your own website components cannot alter how the payment page works.
Anything on your site that touches the payment page, from a tag manager to a custom script, deserves a review. Your vulnerability scanning and patching routine matters as well. Our guide on what vulnerability scanning involves explains how a regular scanning program is set up.
SAQ A-EP: partially outsourced e-commerce
SAQ A-EP applies when you outsource payment processing but your website still affects the security of the payment transaction. The typical example is a checkout where your site builds the page or controls the redirect to the provider, so a compromise of your site could lead to compromised card data even though the data itself goes to a third party.
The difference from SAQ A comes down to control. If your page only links out to a provider-hosted payment form, you are likely in A territory. If your server generates the payment form, or code you manage collects or influences the data on its way to the provider, you are closer to A-EP. The PCI SSC also clarified eligibility for A-EP under v4.0.1.
Expect a longer questionnaire than SAQ A, because your web servers and the code on them are in scope. That usually means secure configuration, patching, access controls and testing of the site. For many merchants, moving from A-EP to a fully hosted checkout is a design decision worth weighing, because it can reduce the number of systems in scope. Whether that is possible depends on your platform and provider, so raise it with them directly.
SAQ A or A-EP: a quick test
Ask your web team three questions:
- Does our server create or deliver the page where the customer types the card number?
- Can scripts we control run on that page?
- Would a compromise of our website let an attacker change how card data is captured?
A "no" to all three suggests SAQ A. A "yes" to any of them means you should review A-EP criteria, and confirm with your acquirer.
SAQ B and B-IP: standalone terminals
SAQ B covers merchants who use only imprint machines or standalone dial-out terminals. There is no IP connection to the processor and no electronic storage of account data.
SAQ B-IP covers merchants who use only standalone, PCI-listed approved PTS POI devices with an IP connection to the processor. The key words are standalone and approved. A terminal that is connected to your point-of-sale system, or one not on the PCI SSC's approved list, does not qualify.
These forms suit small retail, restaurant and service businesses with simple counters. Trouble starts when the setup grows. Adding a networked register, a loyalty system that captures card numbers, or a shared network between the terminal and office computers can move you out of B-IP and into a longer questionnaire.
SAQ C-VT and SAQ C
C-VT: virtual terminals
SAQ C-VT is for merchants who key transactions by hand into a third-party virtual terminal, using an isolated device. Think of an office clerk entering a phone order into a provider's web portal. The PCI SSC clarified C-VT eligibility in the v4.0.1 SAQs, so review the current wording. The word isolated matters: a general-purpose workstation used for email and browsing is a poor fit for the criteria.
C: internet-connected payment applications
SAQ C covers merchants whose payment application systems are connected to the internet. It is more demanding than the B family because your network, and the controls around the application, come into play. Merchants in this group often discover that the network around the payment system is flatter than they believed. Our article on PCI DSS segmentation testing explains what assessors look for when you claim that systems are separated from the rest of your network.
P2PE and SPoC: validated solutions
SAQ P2PE applies to merchants using a validated point-to-point encryption solution, where there is no clear-text access to account data in the merchant environment. The SPoC SAQ covers validated mobile payment solutions. Both rely on a listed, validated product, so the choice of provider drives your eligibility. Keep the provider's documentation, because you will need it to show that you deployed the solution as validated.
SAQ D: everything else
SAQ D is the broadest and longest form. It applies to eligible merchants who do not fit any shorter type, and eligible service providers use it as well. If your own systems store, process or transmit cardholder data, if you run your own payment application over a flat network, or if your environment mixes several payment channels, expect SAQ D.
SAQ D is where PCI DSS v4.x future-dated requirements matter most. Of the 64 new v4.0 requirements, 51 were future-dated and became effective on 31 March 2025. If you complete SAQ D, assume those requirements apply to your assessment and plan the evidence you need, such as documented procedures, access and authentication controls, and testing records. Our penetration test requirements guide covers what testers and assessors expect on that front.
How the payment page and card data flow decide your SAQ
The PCI SSC's guidance says eligibility depends on how the payment page is implemented and on meeting the SAQ criteria: SAQ A is fully outsourced, A-EP is partially outsourced e-commerce where the site affects payment security, and D covers other eligible merchants. So map the flow before reading any questionnaire.
- List every way you accept cards. Website, phone, in person, mobile, mail, recurring billing.
- Trace each channel. Where does the card number enter, which devices and systems touch it, and who processes it?
- Identify third parties. Payment gateways, hosting companies, agencies that built your checkout, and terminal providers.
- Record where data is stored. Include spreadsheets, email, call recordings and paper forms. Surprise storage is a common reason a merchant is not eligible for a short form.
- Match each channel to a type. Then check the full criteria for each.
If you take payments through several channels, you may have to address more than one environment, and your acquirer will tell you how it wants that reported. Our PCI DSS readiness roadmap puts scoping first for this reason, and it sets out a 30 to 90 day plan for v4.
An example from energy retail
A fuel and convenience operator might have pay-at-pump terminals, an in-store register, a loyalty app and an online account portal. That is four environments, and possibly three or four different answers. Our article on PCI DSS for energy retail operations covers how those channels interact. Treating the business as one SAQ type is exactly how teams end up with the wrong form.
How to confirm which SAQ applies
The PCI SSC tells merchants to compare their environment with the SAQ criteria and to contact the organizations that manage their compliance program, such as their acquirer or payment brand, to confirm eligibility and reporting instructions. The October 2024 bulletin adds that merchants should confirm they meet all criteria before starting, and that entities are encouraged to contact the organization receiving the SAQ to confirm eligibility and any specific instructions.
In practice, that conversation covers four things:
- Which SAQ type your acquirer expects you to complete.
- What evidence, if any, you submit with it, including the Attestation of Compliance that accompanies the questionnaire.
- How often and by when you must validate. The schedule is set by the organization that receives your validation, so ask instead of assuming.
- Whether any compensating arrangements or third-party documentation are acceptable.
A practical PCI compliance checklist for B2B merchants can help you prepare the questions for that call and gather what your acquirer will ask to see.
Common mistakes that lead to the wrong SAQ
- Choosing by price or length. A shorter form is only available if you meet every criterion.
- Ignoring the website. A redesign, new plug-in or tag can change an e-commerce environment from A to A-EP overnight.
- Trusting that the provider handles everything. Outsourcing moves some responsibility, not all of it. You still need to show your providers are compliant and manage them. Our guides on vendor cybersecurity assessment and vendor security due diligence outline how to do that.
- Forgetting stored data. Card numbers in email, notes fields and shared drives can disqualify a short form.
- Copying last year's answer. Criteria were clarified in v4.0.1, and your environment may have changed.
Our perspective
Most merchants we meet ask which questionnaire is the easiest. We think the better question is which environment they actually run, and whether they can prove it.
A questionnaire is only as reliable as the scope behind it. When a firm tells us it is SAQ A, we start by tracing the card data flow, listing the scripts on the payment page and confirming what each provider documents. In regulated sectors such as law, oil and gas and energy retail, we often find a second payment channel nobody counted, such as retainer payments by phone or a loyalty program at the pump.
That is where a vCISO is useful. A virtual CISO owns the scope decision, the provider oversight and the evidence calendar, without the cost of a full-time executive. Our approach pairs hands-on advisory with a platform that automates penetration testing, compliance intake and reporting, so the evidence your acquirer or assessor asks for is already organized.
The result we aim for is simple: the right form, completed once, with a defensible basis for every answer.
vCISO
Get help choosing and completing the right SAQ
If your card environment spans several channels, or you are unsure whether you qualify for a shorter form, our team can map your payment flows, confirm scope and prepare your evidence. CISOSafe combines virtual CISO, compliance program management and security risk assessment services with an AI-powered platform built for regulated organizations.
To start, book a scoping conversation through cisosafe.com. If you complete SAQ C or D, we can also help with penetration testing and audit readiness.
FAQ
How many SAQ types are there?
The PCI SSC's current instructions list A, A-EP, B, B-IP, C-VT, C, P2PE, SPoC and D. Older guidance and some articles describe a different number because earlier versions of the standard had fewer or differently named forms. Use the current SAQ instructions as your reference.
Can I choose the SAQ I prefer?
No. You must meet all the criteria of a type to use it, and the organization receiving your validation can confirm which one it expects. Confirm eligibility before you begin, so you do not complete the wrong form.
What is the difference between SAQ A and SAQ A-EP?
SAQ A is for merchants that fully outsource payment functions, so card data never touches their systems. SAQ A-EP is for e-commerce merchants that outsource processing but whose website still affects the security of the payment transaction. A-EP is longer because your web environment is in scope.
When does SAQ D apply?
SAQ D applies to eligible merchants that do not fit another type, for example when card data is stored, processed or transmitted on your own systems. Eligible service providers also use it. Expect the most requirements and the most evidence.
Do I need a QSA to complete an SAQ?
Not necessarily. An SAQ is designed for organizations that are not required to submit a ROC. If your acquirer or payment brand requires a ROC, or you want a QSA's guidance on scope, a QSA can help. Ask your acquirer what it requires.
Sources
- Self-Assessment Questionnaire Instructions and Guidelines, PCI DSS v4.0.1 (PCI SSC, April 2025)
- PCI SSC Bulletin: SAQs for PCI DSS v4.0.1 (15 October 2024)
- PCI SSC Bulletin: Update to FAQ 1331 (23 May 2025)
- Now is the Time for Organizations to Adopt the Future-Dated Requirements of PCI DSS v4.x (PCI SSC blog)
- PCI Compliance Checklist for B2B Merchants