Most merchants land in one of five buckets: a fully outsourced online store typically qualifies for SAQ A, a merchant-controlled payment page usually needs SAQ A-EP, an internet-connected POS terminal generally falls under SAQ C, and any business storing card data or running a complex environment should expect SAQ D. The immediate next step is not guesswork. Confirm your specific SAQ with your acquiring bank or payment brand, and verify your third-party service provider's own PCI attestation before you assume anything.
TL;DR:
- Most merchants must carefully confirm their SAQ category with their acquiring bank or payment brand before starting, especially when switching payment solutions or adding new integrations.
- Environment changes such as storing card data, connecting a POS to the network, or moving to a new processor can immediately alter SAQ eligibility, requiring prompt reassessment.
- Techniques like tokenization, P2PE, and network segmentation significantly reduce scope, often decreasing audit complexity by up to 95 percent if validated properly.
- Eligibility depends on how card data flows through systems, with the critical step being mapping the data journey and verifying third-party attestations beforehand.
- Using payment solutions with built-in compliance support, like PaySec, simplifies evidence gathering and mapping, preventing costly mistakes and rework during PCI attestation.
Table of Contents
- What Are the Current PCI SAQ Types?
- How Do You Determine Which SAQ Applies to Your Environment?
- Why Scoping and Segmentation Change Your SAQ
- What Changed With PCI DSS v4.0.1 for SAQs?
- How Do You Complete and Submit an SAQ?
- What Mistakes Force You to Redo Your SAQ?
- How PaySec Supports Merchants Through SAQ Work
- Why the Standard SAQ Advice Misses the Point
- Get Direct Help Choosing and Documenting Your SAQ
- Where to Verify These SAQ Rules Directly
- Sources
- FAQ
What Are the Current PCI SAQ Types?
The PCI Security Standards Council maintains ten SAQ categories, and each one corresponds to a specific way a business accepts, stores, or transmits card data. Picking the wrong one wastes hours on controls that don't apply to your setup, or worse, leaves you attesting to a lower bar than your environment actually requires.
Here is the full lineup of PCI DSS SAQ categories and who each one fits:
- SAQ A covers merchants that outsource all cardholder data functions to PCI DSS validated third parties and never store, process, or transmit account data on their own systems. Think a Shopify or Squarespace store using a fully hosted checkout redirect.
- SAQ A-EP applies to e-commerce merchants whose website directs the payment but doesn't itself store cardholder data. This is the merchant-influenced iframe or JavaScript checkout page that still touches the transaction path, even if a third party processes the actual card number.
- SAQ B fits merchants using only standalone, dial-out payment terminals with no internet connection. Rare today, but still relevant for some brick-and-mortar shops using older imprint or dial-up hardware.
- SAQ B-IP covers standalone, PTS-approved payment terminals with an IP connection to the payment processor, isolated from other systems. Common in small retail locations using a dedicated terminal that connects only to the processor.
- SAQ C applies to merchants with payment application systems, such as a networked POS, connected to the internet, provided the systems don't store electronic account data and stay isolated from other networks.
- SAQ C-VT is for merchants who manually key transactions into a virtual terminal on an isolated, dedicated computer with no card data storage. A common fit for phone-order or mail-order businesses using a web-based terminal.
- SAQ P2PE / P2PE-HW applies to merchants using a validated point-to-point encryption solution where the encrypting terminal is the only device that ever sees unencrypted card data. This dramatically limits what auditors need to review.
- SAQ SPoC is one of the newer additions, built for merchants using a commercial off-the-shelf mobile device paired with a validated SPoC solution. Per the SAQ SPoC announcement, it is not applicable to e-commerce or unattended payment channels.
- SAQ D for Merchants is the catch-all for any environment that doesn't fit the narrower categories, including businesses that store cardholder data or run custom payment applications. It carries the most extensive control set of any merchant SAQ.
- SAQ D for Service Providers applies to third-party providers that store, process, or transmit cardholder data on behalf of merchants and must validate against the full service provider control set.
A handful of these, notably SAQ C and P2PE, may require an Approved Scanning Vendor scan if the environment includes internet-facing components. SAQ A and A-EP generally don't require external scanning since the merchant itself doesn't handle raw card data, but confirm this with your acquirer since requirements can vary by processor.
How Do You Determine Which SAQ Applies to Your Environment?
Eligibility comes down to how card data physically and logically moves through your systems, not how your business describes itself. Two merchants selling the same product online can land on completely different SAQs depending on whether their checkout page is hosted entirely by a third party or embedded through an iframe they control.
Work through this sequence before assuming an answer:
- Do you store, process, or transmit cardholder data on your own systems? If no, and everything is outsourced to validated providers, SAQ A is likely in play.
- Is your checkout a full redirect, or does your page influence the payment flow? A true redirect off your domain points toward SAQ A. An iframe or JavaScript-based field that your page controls points toward SAQ A-EP, since the FAQ on new SAQ A eligibility criteria treats susceptibility to page-tampering scripts as a key distinguishing factor.
- Is your POS system connected to the internet or to other internal systems? Internet-connected but isolated points to SAQ C. Connected to broader internal networks or storing data pushes you toward SAQ D.
- Are you using validated P2PE hardware? If the encrypting device is the only thing that touches unencrypted card data, P2PE-HW likely applies and can meaningfully shrink your questionnaire.
Before finalizing anything, collect your evidence: your TPSP's Attestation of Compliance, a current network architecture diagram, and the specific eligibility notes from the PCI SSC's own SAQ documents for your suspected category.
Pro Tip: Print your data flow diagram and physically trace where a card number enters and exits your systems. If you can't draw that line cleanly, you probably haven't nailed down your SAQ yet.
The two-step confirmation process that works best in practice: map your data flows and gather TPSP attestation first, then run your conclusion past your acquirer or payment brand before you submit anything.
Why Scoping and Segmentation Change Your SAQ
Your cardholder data environment, or CDE, is every system, network segment, and person that stores, processes, or transmits card data, plus anything connected to those systems. PCI SSC scoping guidance instructs merchants to assume the entire environment is in scope until they can prove otherwise, and incorrect scoping is one of the most common reasons businesses land on the wrong SAQ entirely.
Three techniques tend to shrink scope the most:
- Tokenization replaces card numbers with non-sensitive tokens once the transaction is processed, so downstream systems never touch real data.
- P2PE encrypts card data at the point of capture, meaning your network never sees a readable card number.
- Network segmentation uses firewalls, router configurations, and host-based access controls to isolate payment systems from everything else on your network.
A layered approach combining tokenization or P2PE with segmentation can reduce audit scope by an estimated 85 to 95 percent in many merchant environments compared with a flat, unsegmented network. That reduction isn't automatic. Segmentation controls need to be validated and documented, not just implemented, or an assessor will treat your environment as flat regardless of what you built.
What Changed With PCI DSS v4.0.1 for SAQs?
The PCI SSC's bulletin on SAQs for PCI DSS v4.0.1 confirmed several updates that directly affect which questionnaire merchants use and how they complete it:
- SAQ A and A-EP eligibility clarifications, including how merchants demonstrate their checkout pages resist tampering scripts, whether through technical controls or documented confirmation from their TPSP.
- The introduction of SAQ SPoC, filling a gap for merchants using COTS mobile devices with validated software-based PIN entry solutions.
- Wording alignment across all SAQs to match the updated PCI DSS v4.0.1 control language, which changes some Not Applicable justification requirements.
Acquirers don't all move to a new SAQ version on the same day. Check with your acquiring bank on which version they require before you submit, since submitting against the wrong version can send your attestation back for rework.
How Do You Complete and Submit an SAQ?
Completing an SAQ well is mostly about the prep work you do before opening the document.
- Inventory your systems and confirm TPSP compliance. Pull attestation documents from every processor, gateway, and hosting provider touching your transaction flow.
- Map your data flows and document your scope. This becomes the backbone of your answers and your defense if an assessor questions a Not Applicable response.
- Answer each control and commission ASV scans where your SAQ requires them. Document why any control is Not Applicable rather than leaving it blank.
- Submit through your acquirer or payment brand, since as the PCI SSC bulletin notes, they set the specific validation requirements and confirm your SAQ eligibility.
Pro Tip: Keep every piece of evidence, scan reports, attestations, network diagrams, in one folder tied to a date. When your SAQ eligibility changes next year, you'll thank yourself.
What Mistakes Force You to Redo Your SAQ?
The most common mistake is trusting a TPSP's compliance claim without requesting its actual Attestation of Compliance. Others overlook connected-to systems entirely, or misclassify an iframe checkout as a simple redirect.
Certain events force immediate reassessment: adding a new payment integration, beginning to store card data, connecting a previously isolated POS to your broader network, or switching processors. SAQ eligibility can change immediately when your technology changes, so don't wait for your annual renewal to notice. Document every architecture change the day it happens.
How PaySec Supports Merchants Through SAQ Work
Compliance gets easier when your processor already builds toward it. PaySec maintains PCI DSS Level 1 and SOC 2 compliance, and its detailed transaction reporting gives merchants a cleaner data trail when documenting scope for an SAQ.
A payments partner that centralizes evidence, provides clear TPSP attestation documentation, and supports tokenization choices removes a lot of the scattered paperwork that slows SAQ completion down. Merchants using PaySec's integrated reporting have a head start when it comes time to map data flows for their next assessment.
Why the Standard SAQ Advice Misses the Point
Most guidance on PCI SAQ types treats the questionnaire as a paperwork exercise: pick the category, answer the questions, file it away. That framing gets the priority backwards. The SAQ is the output of your architecture decisions, not an input you choose independently of them.
The merchants who struggle most aren't confused about which document to fill out. They're confused because nobody mapped their data flow before someone added a new payment integration or connected a POS terminal to the corporate network. By the time they're staring at ten SAQ options, the real problem already happened months earlier.
Prioritize scoping before you prioritize the questionnaire. A business that genuinely isolates its cardholder data environment through segmentation and tokenization will usually qualify for a shorter, simpler SAQ almost automatically. That is worth more than any amount of careful box checking on a form built for a messier environment.
— PaySec Marketing Team
Get Direct Help Choosing and Documenting Your SAQ
Some payment processors offer transparent Network Offset Pricing that passes through wholesale interchange rates, helping merchants keep more revenue while staying compliant. Such transparency can extend to compliance work as well. Detailed transaction reporting and compliance certifications can help merchants have a more organized evidence trail when completing an SAQ, rather than scattered records.
If your business processes payments online, in person, or both, PaySec's merchant services cover POS integration, eCommerce gateways, and mobile payments, all built with PCI-related documentation in mind. There are no long-term contracts and no minimums, so you're not locked into a setup that no longer matches your environment after a technology change. Review Network Offset, Flat Rate, and Custom Enterprise pricing and reach out to get your specific merchant environment mapped against the right SAQ before your next attestation deadline.
Where to Verify These SAQ Rules Directly
For the authoritative source on any SAQ decision, go straight to the PCI SSC's own documents: the SAQ A and SAQ C PDFs, the v4.0.1 SAQ bulletin, and the scoping and segmentation guidance. Each document contains the exact eligibility language your assessor will reference.
Sources
- PCI Security Standards Council Bulletin: SAQs for PCI DSS v4.0.1 Now Available
- Self-Assessment Questionnaire A and Attestation of Compliance (PCI DSS v4.0)
FAQ
What Is the Difference Between SAQ A and SAQ D?
SAQ A applies when a merchant outsources all cardholder data handling to validated third parties and touches no card data directly. SAQ D applies to merchants or service providers with more complex environments, including anyone storing card data, and it carries the broadest set of controls of any SAQ.
How Is SAQ A-EP Different From SAQ A?
SAQ A covers merchants using a full payment page redirect with zero influence over the transaction. SAQ A-EP applies when the merchant's website controls or influences the payment page, such as through an iframe, even though a third party still processes the actual card number.
Which SAQ Do Most E-Commerce Merchants Need?
Merchants using a fully hosted checkout redirect typically qualify for SAQ A, while those embedding a payment page through their own site usually need SAQ A-EP. The determining factor is whether your page can influence or be tampered with during the transaction, per PCI SSC's eligibility clarifications.
How Often Do I Need to Complete an SAQ?
Most SAQs require annual completion, but eligibility isn't fixed for the year. It can change immediately after a technology change, so reassess whenever you add a new payment integration or change processors.
Can PaySec Help Me Figure Out Which SAQ I Need?
PaySec's merchant services team supports compliance documentation alongside PCI DSS Level 1 and SOC 2 maintained infrastructure, which simplifies gathering the evidence your SAQ requires. Current pricing details for Network Offset, Flat Rate, and Custom Enterprise plans are available directly on PaySec's site.