PCI DSS Self-Assessment Questionnaire (SAQ): Types and Selection

I'll never forget sitting across from a frustrated restaurant owner in 2017. He'd just received a letter from his payment processor threatening to terminate his merchant account. The reason? He hadn't completed his annual PCI DSS compliance validation.

"I have no idea what they're talking about," he said, waving the letter. "They want me to fill out something called an 'SAQ-C-VT' but I don't even know what half these letters mean. I just want to accept credit cards!"

That conversation happens more often than you'd think. The PCI DSS Self-Assessment Questionnaire—or SAQ—is one of the most misunderstood requirements in payment security. Merchants receive a generic link to complete "PCI compliance," fill out the wrong questionnaire, and wonder why they're still non-compliant six months later.

After fifteen years of helping businesses navigate PCI DSS compliance, I've learned that choosing the right SAQ is half the battle. Get it wrong, and you'll waste hours answering irrelevant questions while missing critical security controls. Get it right, and compliance becomes a manageable process that actually improves your security posture.

Let me show you how to navigate this maze.

What Exactly Is an SAQ? (And Why Should You Care)

Here's the simple truth: the SAQ is your ticket to accepting payment cards without a full, expensive PCI audit.

The Payment Card Industry Security Standards Council (PCI SSC) created SAQs as a streamlined compliance validation method for smaller merchants and service providers. Instead of hiring a Qualified Security Assessor (QSA) to conduct a comprehensive audit—which can cost $15,000 to $50,000+—you can self-assess using the appropriate SAQ.

Think of it like this: if a full PCI audit is like hiring an accountant to prepare your taxes, an SAQ is like using TurboTax. You're still responsible for the accuracy, but the process is more accessible and affordable.

"The SAQ isn't about avoiding compliance—it's about making compliance accessible to businesses of all sizes. But only if you choose the right one."

The Stakes Are Real

Before we dive into SAQ types, let me share what happens when you get this wrong.

In 2019, I consulted for an e-commerce company that had been completing SAQ A for three years. They processed about 80,000 transactions annually through their website, all handled by a payment gateway. SAQ A seemed perfect—it's designed for merchants who outsource all payment processing.

During a routine audit trigger (they'd crossed the 1 million transaction threshold), their acquiring bank discovered they were storing transaction logs that contained full credit card numbers. Technically, they had cardholder data in their environment.

The correct questionnaire? SAQ D—the most comprehensive one, with 329 security requirements instead of SAQ A's 22.

The consequences:

• $45,000 in PCI non-compliance fines

• Mandatory QSA audit at $28,000

• Three months of intensive remediation work

• Threat of losing payment processing capabilities

• Significant reputation damage with their acquiring bank

All because they selected the wrong SAQ.

The SAQ Landscape: Understanding Your Options

As of PCI DSS version 4.0, there are nine different SAQ types. Yes, nine. The PCI Council didn't make this simple, but there's logic to the madness.

Each SAQ is designed for specific payment processing scenarios. Here's the complete breakdown:

Don't let these numbers intimidate you. We'll break down exactly which one applies to your business.

SAQ Type Breakdown: Finding Your Match

Let me walk you through each SAQ type with real-world scenarios I've encountered. This is where experience matters—I've seen every possible payment configuration, and I'll help you identify yours.

SAQ A: The Holy Grail (If You Qualify)

Who it's for: E-commerce merchants who completely outsource payment processing and never touch cardholder data.

Real-world scenario: You run an online bookstore. Customers click "checkout," get redirected to PayPal or Stripe's hosted payment page, complete the transaction, and return to your site. You never see, store, or transmit card data.

Key requirements:

• All payment processing fully outsourced to PCI DSS validated third parties

• No electronic storage of cardholder data

• Merchant website doesn't receive cardholder data

• Redirect or iframe payment methods only

My experience: This is the easiest SAQ—only 22 questions—but I've seen countless merchants incorrectly claim eligibility.

I worked with a subscription service in 2020 that swore they qualified for SAQ A. During my review, I discovered their customer service team could view the last four digits of credit cards in their CRM system. That disqualified them immediately.

"SAQ A is like a VIP pass—amazing if you have it, but the bouncer checks carefully. One misstep and you're in the general admission line with everyone else."

Insider tip: If you're building a new e-commerce platform, architect it for SAQ A eligibility. Use redirect-based payment flows. Never let cardholder data touch your servers. It's the difference between 22 questions and 329.

SAQ A-EP: E-Commerce with More Control

Who it's for: E-commerce merchants who outsource payment processing but maintain the payment page on their own website.

Real-world scenario: Your online store has a checkout page that looks like part of your website, but card data is captured via JavaScript and sent directly to your payment processor without touching your server.

Key requirements:

• Payment page hosted on merchant's website

• Payment data captured via iframe or JavaScript

• No electronic storage of cardholder data

• All payment processing outsourced to validated third party

• Website must be secured and regularly scanned

My experience: This is where most modern e-commerce platforms land. Think Shopify, WooCommerce with payment gateway integration, or custom solutions using Stripe.js.

I helped a fashion retailer transition from SAQ D to SAQ A-EP in 2021. The change required:

• Implementing Stripe Elements for card capture

• Removing all card data from application logs

• Quarterly vulnerability scanning

• Annual penetration testing

The effort was substantial—about 200 hours—but reduced their annual compliance burden by approximately 60%.

The catch: With 181 questions, this isn't a walk in the park. You need proper web application security, network segmentation, and strong access controls.

SAQ B: The Dinosaur (But Still Relevant)

Who it's for: Merchants using only imprint machines (knuckle-busters) or standalone dial-out terminals.

Real-world scenario: You run a small repair shop with a standalone terminal that dials out via phone line to process transactions. No internet connection, no computer integration.

My experience: I haven't seen a pure SAQ B environment since 2015. Most terminals are now IP-connected, which bumps you to SAQ B-IP.

However, if you're one of the rare merchants still using old-school technology, SAQ B's 41 questions are manageable. The key requirements focus on physical security and proper terminal handling.

Reality check: If you're using dial-out terminals, you should seriously consider upgrading to modern payment technology. The security benefits (and SAQ simplification) are worth the investment.

SAQ B-IP: The Small Merchant Sweet Spot

Who it's for: Brick-and-mortar merchants with standalone, IP-connected payment terminals.

Real-world scenario: You own a coffee shop with a Clover terminal on the counter. Customers insert their chip cards, and the terminal connects directly to the payment processor via your internet connection. The terminal never communicates with your computer systems.

Key requirements:

• Standalone IP-connected terminal only

• No card data stored electronically

• Terminal not connected to any other systems

• Isolated network segment for payment processing

My experience: This is incredibly common for small retail and restaurant businesses. I've helped dozens of merchants achieve SAQ B-IP compliance, and it's one of the most straightforward paths.

The critical factor? Isolation. Your payment terminal must be truly standalone.

Here's a real mistake I see constantly:

I audited a retail store in 2022 that insisted they qualified for SAQ B-IP. Their terminal was connected to their Square POS system for inventory management. That integration meant they needed SAQ D. The owner was devastated—until I showed him how to properly segment his network and qualify legitimately.

SAQ C-VT: The Virtual Terminal Reality

Who it's for: Merchants who manually key card-not-present transactions into a web-based virtual terminal.

Real-world scenario: You run a phone-order business. Customers call, provide their card information, and you type it into a secure web portal (like Authorize.net's virtual terminal) to process the payment.

Key requirements:

• Only use isolated, dedicated computer for virtual terminal

• No electronic cardholder data storage

• Computer hardened and secured

• Strong password policies

• Anti-virus and security patches current

My experience: This SAQ causes more confusion than almost any other. Merchants think "virtual terminal" means any web-based payment processing. Wrong.

The "VT" stands for Virtual Terminal—specifically, manually keying transactions. If you also process in-person transactions, store card data, or integrate payments with other systems, you don't qualify.

I consulted for a HVAC company in 2020 using a virtual terminal for phone orders. Their technicians also carried mobile card readers for on-site payments. Two processing methods = no SAQ C-VT eligibility = SAQ D requirement.

The isolation requirement is serious:

I've seen businesses fail PCI audits because their "dedicated" virtual terminal computer was also used for:

• Email

• Web browsing

• Social media

• File downloads

• Shared network drives

One computer. One purpose. Virtual terminal only. That's the rule.

SAQ C: Internet-Connected Payment Applications

Who it's for: Merchants using payment applications on computers connected to the internet.

Real-world scenario: You use payment software installed on your computer that processes transactions through an internet connection. Think older POS systems or booking software with integrated payment processing.

Key requirements:

• Payment application on internet-connected computer

• No card data storage

• Application must be PA-DSS validated

• Computer and network properly secured

• Segmented from other business systems

My experience: SAQ C is becoming less common as merchants move to cloud-based solutions, but I still encounter it frequently in legacy environments.

A dental practice I worked with in 2021 used practice management software with built-in payment processing. The software was PA-DSS validated, but their network configuration was a nightmare. Patient management computers, payment processing computers, and guest WiFi all on the same flat network.

We spent three months properly segmenting their network, implementing firewalls, and restricting access. The SAQ C validation took 40 hours of work, but more importantly, their overall security posture improved dramatically.

SAQ P2PE-HW: The Modern Solution

Who it's for: Merchants using hardware-based Point-to-Point Encryption solutions.

Real-world scenario: You use payment terminals that encrypt card data at the moment of swipe/dip/tap, and the data remains encrypted until it reaches your payment processor. You never have access to unencrypted card data.

Key requirements:

• Use only PCI-listed P2PE solutions

• Hardware must be tamper-resistant and regularly inspected

• Terminals must be physically secured

• No other payment channels (everything through P2PE)

My experience: This is the future of payment security, and I recommend it whenever possible.

I helped a restaurant chain with 12 locations transition to P2PE in 2019. The upfront cost was higher—P2PE terminals run $400-800 each vs. $150-300 for standard terminals—but the compliance simplification was dramatic.

They went from SAQ D (329 questions, annual QSA audits) to SAQ P2PE-HW (35 questions, self-assessment). The annual savings in audit fees alone justified the hardware investment within 18 months.

Important: Not all encryption is P2PE. The solution must be listed on the PCI SSC website as a validated P2PE solution. I've seen merchants assume their "encrypted" terminals qualify, only to discover during an audit that they don't.

SAQ D: The Comprehensive Catch-All

Who it's for:

• All other merchants who don't fit into SAQ A through P2PE-HW

• Any merchant storing, processing, or transmitting cardholder data

• Service providers handling card data

Real-world scenario: You operate a full-service restaurant with integrated POS, online ordering, phone orders, and delivery. Your POS system stores card data for tab management. Multiple payment channels, data storage, complex integrations.

My experience: SAQ D is where approximately 40% of merchants actually belong, even though many try to squeeze into simpler SAQs.

Here's the reality: SAQ D is essentially a full PCI DSS compliance program, covering all 329 requirements across 12 major categories:

I worked with a regional e-commerce company processing 2 million transactions annually that needed SAQ D compliance. The full implementation took:

• 9 months from start to compliance

• $180,000 in consulting, technology, and audit costs

• Dedicated project team of 4 people

• Network redesign and application remediation

• Quarterly vulnerability scanning ($1,200/quarter)

• Annual penetration testing ($15,000)

Was it worth it? Absolutely. They avoided merchant account termination, reduced fraud by 73%, and improved overall security posture. Three years later, they're processing 6 million transactions annually on the same infrastructure because they built it right.

"SAQ D isn't a punishment—it's an opportunity to build enterprise-grade security that scales with your business. Done right, it becomes a competitive advantage."

How to Choose Your SAQ: The Decision Framework

After years of helping merchants navigate this decision, I've developed a simple framework. Answer these questions honestly:

Question 1: Do you ever see, store, or transmit cardholder data?

If NO: You might qualify for SAQ A or A-EP If YES: Continue to Question 2

Question 2: What payment channels do you use?

Question 3: Are all your payment systems isolated?

If NO: You probably need SAQ D If YES: Continue to Question 4

Question 4: Do you use PCI-validated solutions?

For SAQ A/A-EP, your payment provider must be PCI compliant. For SAQ P2PE-HW, your solution must be on the PCI SSC P2PE list. For SAQ C, your software must be PA-DSS validated (or PCI-SSC listed if post-2018).

Common SAQ Selection Mistakes (And How to Avoid Them)

Let me share the mistakes I see most frequently:

Mistake #1: Assuming Outsourcing = SAQ A

A merchant told me: "We use Stripe, so we're SAQ A, right?"

Not necessarily. If you're using Stripe Checkout (redirect), yes. If you're using Stripe.js on your payment page, it's SAQ A-EP. If you're using Stripe API to create charges from your server, it might be SAQ D.

The fix: Understand exactly how your payment integration works. Draw a diagram of where card data flows. If it touches any of your systems—even temporarily—you're not SAQ A.

Mistake #2: Ignoring Multi-Channel Reality

I consulted for a restaurant using standalone terminals (SAQ B-IP qualified) for in-person transactions. Perfect, right?

Except they also took phone orders and manually keyed those into the terminal. That manual keying = virtual terminal = different SAQ requirements = SAQ D.

The fix: Consider ALL payment methods you use, not just the primary one. Multiple methods usually mean SAQ D.

Mistake #3: "We Don't Store Cards" (But Actually Do)

The number of times I've heard "we don't store cardholder data" only to find:

• Full PANs in application logs

• Card numbers in backup systems

• Data in development/test databases

• Numbers in email confirmations

• Information in crash reports

The fix: Conduct a thorough card data discovery. Search logs, databases, backups, and archives for card numbers. You might be surprised what you find.

Mistake #4: Confusing Encryption with P2PE

A retail client insisted they qualified for SAQ P2PE-HW because their terminals "encrypted card data."

All modern terminals encrypt data. That's not P2PE. P2PE requires:

• PCI SSC validated solution

• Tamper-resistant hardware

• Encryption at point of interaction

• No clear-text data access anywhere in your environment

The fix: Check the PCI SSC website for validated P2PE solutions. If yours isn't listed, it's not P2PE.

The Selection Process: A Real-World Example

Let me walk you through how I helped a client determine their correct SAQ.

The Business: Regional medical practice with 8 locations Payment Methods:

• In-person co-pays via countertop terminals

• Online bill payments via patient portal

• Phone payments via virtual terminal

Initial Assumption: "We use standalone terminals, so SAQ B-IP, right?"

My Analysis:

Multiple channels + virtual terminal on shared computer = SAQ D requirement

The Solution:

I presented two options:

Option 1: Simplify to Qualify for Easier SAQ

• Eliminate virtual terminal; use countertop terminal for phone payments

• Ensure patient portal uses redirect (SAQ A)

• Properly isolate counter terminals

• Result: SAQ A + SAQ B-IP (two simple questionnaires)

• Cost: Minimal, mostly procedural changes

• Time: 2 weeks

Option 2: Accept SAQ D Reality

• Implement comprehensive PCI program

• Properly secure all environments

• Quarterly scanning, annual penetration testing

• Result: Full compliance with flexibility

• Cost: $45,000 implementation + $8,000/year ongoing

• Time: 6 months

They chose Option 1. We eliminated the virtual terminal, retrained staff on procedures, and achieved compliance in three weeks. The simplification also improved their security posture because each payment channel was properly isolated.

"Sometimes the best compliance strategy is simplification. Fewer payment channels means less complexity, lower cost, and easier ongoing management."

SAQ Completion Tips: Making the Process Easier

Once you've identified the correct SAQ, here's how to complete it efficiently:

Before You Start

1. Gather evidence: Don't just answer questions. Collect proof.

   • Network diagrams

   • System configurations

   • Policy documents

   • Training records

   • Vendor attestations

2. Understand the questions: Each question includes detailed testing procedures and guidance. Read them carefully.

3. Be honest: A "yes" when the answer should be "no" creates false compliance and liability.

During Completion

I've completed dozens of SAQs. Here's my process:

Week 1: Documentation Review

• Review all testing procedures

• Identify gaps in current practices

• Document required evidence

Week 2-3: Evidence Collection

• Screenshot configurations

• Gather policy documents

• Collect vendor attestations

• Document procedures

Week 4: Question Response

• Answer each question methodically

• Attach supporting evidence

• Note any "No" responses for remediation

Week 5: Internal Review

• Second-pair-of-eyes review

• Verify all evidence is attached

• Check for completeness

Week 6: Remediation (if needed)

• Address any "No" responses

• Implement corrective measures

• Re-document and verify

Red Flags That You're Doing It Wrong

I can spot a problematic SAQ submission from a mile away. Warning signs:

• ❌ Completed in under an hour (unless SAQ A with clear evidence)

• ❌ All questions answered "Yes" with no supporting documentation

• ❌ Generic responses like "We have firewalls" without specifics

• ❌ No evidence attachments

• ❌ Unclear on what systems are in scope

• ❌ No named individuals responsible for each control

A proper SAQ completion takes time:

If you're finishing faster, you're probably missing something.

Validation and Attestation: The Final Steps

Completing the SAQ isn't the end. You need to validate compliance and attest to it.

Attestation of Compliance (AOC)

The AOC is your official declaration that you're PCI compliant. It includes:

• Company information

• SAQ type completed

• Compliance status

• Validation date

• Executive signature

Critical mistake I see: Merchants signing AOCs without proper evidence or remediation of non-compliant items. That's fraud, and it can void your merchant agreement.

I worked with a merchant who signed an AOC with 12 outstanding non-compliant items. During a breach investigation, this was discovered. The acquiring bank terminated their account immediately, and they faced legal action for fraudulent attestation.

My rule: Never sign an AOC unless you're genuinely compliant. Period.

Quarterly Scanning (Where Required)

Many SAQs require quarterly vulnerability scanning by an Approved Scanning Vendor (ASV).

Required for:

• SAQ A-EP

• SAQ C

• SAQ D

• Others depending on specific circumstances

Cost: $250-500 per quarter per IP address Frequency: Every 90 days Requirement: All scans must pass with no vulnerabilities rated 4.0 or higher (CVSS)

I helped a client who kept failing ASV scans due to outdated WordPress plugins on their company blog—on the same domain as their payment processing. We segmented the blog to a subdomain, fixed the vulnerabilities, and scans started passing.

Maintaining Compliance: It's Not One-and-Done

Here's the reality nobody tells you: completing your SAQ once doesn't mean you're done.

PCI compliance is an annual requirement, but security is continuous.

What Changes Require SAQ Re-evaluation

You must reassess when:

• Adding new payment channels

• Changing payment processors

• Implementing new systems that touch card data

• Changing network architecture

• Experiencing a breach or incident

• Moving to new office/data center

• Significant business changes

I worked with a merchant who completed SAQ B-IP in January. In March, they added e-commerce. In July, they started taking phone orders. By August, they should have been on SAQ D but were still claiming B-IP compliance.

When their acquiring bank discovered this during a routine review, they faced:

• $25,000 in non-compliance fines

• Mandatory forensic audit

• Enhanced monitoring for 12 months

The lesson: Your SAQ must reflect your current environment, not your environment when you last completed it.

Annual Revalidation

Even if nothing changes, you must:

• Complete a new SAQ annually

• Conduct quarterly scans (if required)

• Update all documentation

• Review and update policies

• Submit new AOC

I recommend setting up a compliance calendar:

The Bottom Line: Choose Wisely, Document Thoroughly

After fifteen years in this field, here's what I know for certain about SAQs:

The right SAQ makes compliance manageable. The wrong SAQ creates confusion, wasted effort, and potential non-compliance.

The merchants I've seen succeed with SAQs share common traits:

• They honestly assessed their environment

• They chose simplicity over complexity when possible

• They documented everything thoroughly

• They treated compliance as ongoing, not one-time

• They invested in proper implementation rather than paper compliance

The ones who struggled?

• They guessed at the right SAQ

• They rushed through questions

• They took shortcuts

• They ignored "No" responses

• They signed AOCs they couldn't support

Your Action Plan

If you're facing SAQ selection and completion, here's your roadmap:

This Week:

• Map your complete payment environment

• Identify every point where card data appears

• List all payment channels and methods

• Document your current security controls

Next Week:

• Use the decision framework in this article

• Select your appropriate SAQ(s)

• Review the specific questions and requirements

• Identify gaps in your current state

Month One:

• Remediate any compliance gaps

• Implement required controls

• Document all security measures

• Collect supporting evidence

Month Two:

• Complete the SAQ methodically

• Attach all required evidence

• Conduct internal review

• Address any outstanding items

Month Three:

• Final review and validation

• Sign AOC only if genuinely compliant

• Submit to acquiring bank

• Set up ongoing compliance program

A Final Word of Advice

I'll leave you with something a payment processor told me early in my career: "PCI compliance isn't about filling out a form. It's about protecting your customers' data and your business's future."

That stuck with me. The SAQ isn't bureaucratic busy-work—it's a roadmap to security practices that actually protect you from breaches, fraud, and the devastating consequences of payment card compromise.

Choose the right SAQ. Answer honestly. Implement properly. Document thoroughly.

Your customers trust you with their payment information. The SAQ helps you honor that trust.

And when that 2 AM breach call comes—and statistically, for many merchants, it will—you'll be prepared, protected, and capable of responding effectively because you took compliance seriously.

"The best time to choose the right SAQ was when you started accepting cards. The second-best time is today."