PCI DSS SAQ Types Explained: Which One Applies to You?

For most merchants, validating PCI DSS compliance means completing a Self-Assessment Questionnaire, or SAQ. The catch is that there are several SAQ types, and picking the wrong one means either answering hundreds of irrelevant questions or, worse, validating against requirements that do not cover how you actually handle cardholder data. This guide explains the PCI DSS SAQ types and how to find the one that applies to you.

There are multiple SAQs because compliance with PCI DSS requirements varies dramatically by how a merchant or service provider accepts payment card account data. The Payment Card Industry Data Security Standard and the card industry data security standard require different controls depending on how cardholder data flows through your environment. Using the wrong SAQ means your data security attestation does not reflect your actual risk or setup.

What an SAQ is

A Self-Assessment Questionnaire is a validation tool for eligible merchants to assess their own PCI DSS compliance, rather than undergoing a full independent assessment by a Qualified Security Assessor (QSA). Each SAQ type contains the subset of PCI DSS requirements relevant to a particular way of accepting payment card account data. The fewer your systems touch cardholder data, the shorter and simpler your SAQ.

The PCI Security Standards Council (PCI SSC) publishes the official SAQ forms and their eligibility criteria. PCI DSS self-assessment is only appropriate for merchants who meet the applicability conditions for a specific SAQ type exactly. Getting this wrong means either over-complying or leaving real PCI DSS requirements unaddressed.

Completing a PCI DSS Self-Assessment Questionnaire accurately requires understanding the security of cardholder data in your environment. A PCI SAQ is a structured way to demonstrate compliance with PCI DSS standards for a given payment setup. The goal is payment processing to PCI DSS standards throughout your environment.

SAQ types at a glance

There are multiple types of SAQs, and understanding the types of SAQs available is necessary before selecting the appropriate SAQ for your environment. The SAQ that applies to you is determined by exactly how you accept and process payment card account data. The table below summarises the main types. Knowing which SAQ is right for your payment setup is the most important step in the PCI DSS self-assessment process:

Question counts are approximate and can vary between PCI DSS versions. The defining variable in every case is how cardholder data flows through your environment, not just the technology you use.

SAQ A: the target for fully outsourced e-commerce

SAQ A merchants are those who have fully outsourced all cardholder data functions to PCI DSS-compliant third parties hosted by a PCI DSS validated third-party service provider, so their systems never store, process, or transmit payment card account data in any form. SAQ A is the shortest and most widely sought SAQ.

For e-commerce, this means the payment page is entirely hosted by the payment provider, and your website has no code that affects the security of that payment page. If you embed an iFrame from a PCI compliant payment gateway and your site does nothing else to the transaction, you are a strong candidate for SAQ A. If your site scripts load on the payment page, or you redirect customers through your own servers, you likely need to consider SAQ A-EP instead.

Qualifying for SAQ A is an architectural goal, not just a paperwork shortcut. The compliance benefit follows from genuinely keeping card data off your systems.

SAQ A-EP: e-commerce with partial involvement

SAQ A-EP applies to e-commerce merchants who outsource payment processing to a third-party service provider but whose website affects the security of the payment transaction. This includes sites that redirect customers to a payment page, host payment fields, or run JavaScript that executes in the browser during the payment flow.

The distinction from SAQ A is that your website does something that could affect the security of the transaction, even if you never see the cardholder data itself. SAQ A-EP is substantially longer than SAQ A because it requires evidence of controls over your website and its supply chain.

SAQ B and B-IP: physical terminals

SAQ B is for merchants using standalone imprint machines or dial-out telephone-line terminals. These are environments where cardholder data is captured at the terminal and transmitted via dial-up; it never touches your internal network electronically in a way that would extend scope.

SAQ B-IP is intended for merchants using standalone IP-connected payment terminals that are not connected to other systems on the merchant network. The key condition for both is that the terminal is standalone. If your terminal connects to a shared network, the cardholder data environment is larger and the applicable SAQ will be different.

SAQ C and C-VT: payment applications and virtual terminals

SAQ C applies to merchants with payment application systems connected to the internet, where the payment application is on a general-purpose computer or device with internet connectivity. It covers the systems that handle the card transaction in your environment.

SAQ C-VT is for merchants who access a web-based virtual terminal, hosted entirely by a payment service provider, through a standard web browser on a general-purpose computer. The key condition is that the virtual terminal is provided by and hosted at a PCI DSS-compliant third-party service provider, and no cardholder data is stored electronically. Completing SAQ C-VT is a significantly lighter process than completing SAQ C or SAQ D for eligible merchants.

SAQ P2PE: validated point-to-point encryption

To qualify for SAQ P2PE, your solution must be a PCI SSC-listed validated point-to-point encryption solution. In a properly implemented P2PE environment, cardholder data is encrypted at the terminal from the moment of capture and never decrypted within the merchant environment. This significantly reduces the scope of PCI DSS requirements applicable to your environment and results in one of the shorter SAQs despite being for physical card-present environments.

A solution that is merely described as P2PE by a vendor, but has not been formally validated and listed by the PCI SSC, does not earn you the SAQ P2PE reduction. The validation status of the P2PE solution is the eligibility gate, not just the technology used.

SAQ D: the comprehensive option

SAQ D is the most comprehensive SAQ and covers all PCI DSS requirements. Any merchant or service provider that does not meet the eligibility conditions for one of the other SAQ types must use SAQ D. It is also used by service providers that are eligible to self-assess.

SAQ D is not a fallback or a catch-all to use when you are unsure. If you complete SAQ D when you genuinely qualify for a simpler type, you are doing significantly more work than required. If you complete a simpler SAQ when SAQ D is warranted, you have a compliance gap. The right SAQ is always the one whose eligibility conditions your setup genuinely meets.

Why choosing the right SAQ matters

The SAQ type drives your effort and your risk. Demonstrate PCI DSS compliance accurately by completing an SAQ whose eligibility conditions genuinely describe your payment setup. Choose one that is too broad and you waste time on requirements that do not apply. Choose one that is too narrow, and you may believe you are compliant while leaving real security requirements unaddressed.

Payment brands and acquiring banks rely on your SAQ to assess whether applicable PCI DSS requirements are met. Determining which SAQ is appropriate requires an honest assessment of how account data flows through your environment. An inaccurate SAQ is a liability, not a shortcut.

How to reduce which SAQ you need

The way to land on a simpler SAQ is to reduce how much your systems interact with cardholder data. Fully outsourcing payment processing to a PCI DSS validated third-party service provider, so account data never touches your environment, is what makes a merchant or service provider eligible for the shortest SAQ. Validated point-to-point encryption similarly cuts PCI DSS scope.

Achieving PCI DSS compliance at the simplest level requires architectural decisions, not just completing an SAQ. Payment processing to a PCI DSS-compliant hosted environment is what makes SAQ A possible. Payment processing to PCI DSS standards throughout your environment is what the SAQ is confirming.

What happens after you complete your SAQ

Completing the SAQ is not the end of the process. Once you have answered all the questions and addressed any non-compliant items, you sign an Attestation of Compliance (AOC) that declares your compliance to your acquiring bank or payment brand. The AOC is typically submitted annually to your acquirer. Keep both the completed SAQ and the AOC on file.

For SAQ types that require quarterly external vulnerability scanning by an Approved Scanning Vendor, you will also need to maintain passing scan results as part of your evidence package. SAQ A-EP, SAQ B-IP, SAQ C, and SAQ D all require quarterly ASV scans; SAQ A, SAQ B, SAQ C-VT, and SAQ P2PE have different or no external scanning requirements. Confirm the specific supporting requirements for your SAQ type against the official PCI SSC documentation.

Common mistakes with SAQ selection

Assuming fully outsourced means SAQ A. Fully outsourcing payment processing does not automatically mean SAQ A. Your website's involvement in the payment flow matters. If your site's JavaScript runs on the payment page, if you pass card data through your servers, or if the payment iFrame does not fully isolate the transaction from your environment, SAQ A-EP or higher may be required. Choosing the right PCI SAQ for your setup requires an honest review of your payment architecture, not just your payment provider's marketing.

Treating SAQ D as the safe default. Some merchants default to SAQ D thinking it is the safest choice. This is not the right approach. Completing a more demanding SAQ than your setup requires does not make you more compliant. To be eligible for SAQ A or SAQ B rather than SAQ D, you need to meet every condition listed for that SAQ type; use the PCI SSC's guidance to confirm you meet the criteria before completing that SAQ rather than defaulting to the criteria for any other SAQ.

Skipping the eligibility conditions. The PCI SSC publishes specific eligibility conditions for each SAQ. These need to be read carefully and matched to your actual environment. If a single condition is not met, that SAQ does not apply to you.

Not understanding the current version of the PCI DSS. SAQ forms are updated when a new version of the PCI DSS is released. Completing an outdated SAQ does not demonstrate compliance with the current PCI data security requirements. Confirm you are using the correct SAQ for the version of PCI DSS your acquirer requires. The PCI SSC website lists current SAQ versions alongside the current PCI standards.

Choosing the right PCI SAQ matters because it is the mechanism by which you achieve PCI compliance and demonstrate to your acquirer that you meet PCI standards. PCI SAQs are how most merchants demonstrate compliance; getting the selection right is fundamental to the compliance process. If you are unsure which SAQ is right for your setup, consult your acquirer or a PCI specialist. Completing an appropriate SAQ and maintaining compliant with PCI throughout the year is the foundation of PCI data security for most small and mid-size merchants.

The bottom line

The PCI DSS SAQ that applies to you is determined by exactly how you accept and process card payments, from the short SAQ A for fully outsourced e-commerce to the comprehensive SAQ D for merchants and service providers that do not fit the other types. There are multiple SAQs, and each SAQ type targets a different profile. Picking the right one matters for both effort and real security, and the most effective way to qualify for a simpler SAQ is to reduce how much your systems touch cardholder data and account data.

How Onyx helps

Onyx works with merchants at every SAQ level. We start by reviewing your actual payment architecture, confirming the eligibility conditions for the SAQ type that fits, and identifying whether architectural changes (hosted payment pages, P2PE, network segmentation) can move you to a simpler validation path. For merchants who need quarterly ASV scanning as part of their SAQ obligations, we run that as a coordinated programme alongside the penetration testing PCI DSS requires at least annually and after significant changes. For merchants preparing a full SAQ D or approaching a QSA-led Level 1 assessment, we provide gap assessment and remediation support to close issues before they become assessment findings. The right SAQ is determined by your payment architecture, and we scope that on a short call.

See also: PCI compliance cost, what is an Approved Scanning Vendor, PCI DSS Level 1: what it takes, and our PCI DSS SAQ compliance service.

FAQ

What is a PCI DSS SAQ?

A Self-Assessment Questionnaire is a validation tool that lets eligible merchants assess their own PCI DSS compliance instead of a full independent assessment by a Qualified Security Assessor (QSA). Each SAQ type contains the subset of applicable PCI DSS requirements relevant to a particular way of accepting payments and handling account data. The PCI Security Standards Council (PCI SSC) publishes the official SAQ forms and eligibility criteria.

How many PCI DSS SAQ types are there?

There are several, including SAQ A, A-EP, B, B-IP, C, C-VT, P2PE, and SAQ D (for merchants and service providers separately). Each corresponds to a specific way of accepting and processing cardholder data, from fully outsourced e-commerce to comprehensive coverage for merchants and service providers that do not fit the other types.

Which SAQ type applies to me?

It is determined by exactly how you accept and process cardholder data. Merchants who fully outsource payments to a PCI DSS compliant third-party service provider may qualify for the short SAQ A; those whose systems touch cardholder data more directly need a longer SAQ up to the comprehensive SAQ D. Confirm against the official eligibility criteria rather than guessing.

What is the difference between SAQ A and SAQ A-EP?

SAQ A is for merchants who fully outsource all cardholder data functions so their systems never affect the payment. SAQ A-EP is for e-commerce merchants who outsource processing but whose website still affects the security of the payment transaction, for example by redirecting or controlling payment page elements, so it covers more PCI DSS requirements.

How do I qualify for a simpler SAQ?

Reduce how much your systems interact with cardholder data and account data. Fully outsourcing payment handling to a PCI DSS validated third-party service provider so cardholder data never touches your environment qualifies many merchants for the shortest SAQ, and validated point-to-point encryption also cuts PCI DSS scope. The SAQ eligibility conditions spell out exactly what each merchant or service provider must do to qualify. Architecture, not paperwork, drives which SAQ you need.

What happens after I complete my SAQ?

You sign an Attestation of Compliance and submit it to your acquiring bank or payment brand, typically annually. If your SAQ type requires quarterly ASV scans, you maintain passing scan results as supporting evidence. Keep both the completed SAQ and the Attestation of Compliance on file.