PCI SAQ Types Explained: Which One Actually Applies to Your Business
If you accept credit cards, you’re required to validate PCI DSS compliance every year. For most businesses, that doesn’t mean a formal third-party audit. Instead, it means completing a Self-Assessment Questionnaire (SAQ), a standardized set of questions covering how your business handles cardholder data.
The problem is that there isn’t one SAQ. There are eight, and picking the wrong one is one of the most common and most consequential mistakes merchants make. Choose a shorter, simpler SAQ than your actual payment setup qualifies for, and you’re technically out of compliance even if you filled it out correctly. Choose a longer one than necessary, and you’re spending time and budget answering questions about systems that don’t apply to you.
This post walks through the SAQ types that matter for most businesses, how to tell which one applies to yours, and, more importantly, how your payment architecture determines which SAQ applies to your business. These SAQ requirements align with PCI DSS 4.0 and should be reviewed whenever your payment architecture changes.
Why the SAQ Type Isn’t a Choice, It’s a Consequence
The most common misconception about SAQs is that a business picks the one that looks easiest and fills it out. In reality, the SAQ type is determined entirely by how payment data flows through your systems. It’s not a form you select. It’s a classification your infrastructure has already assigned you, whether you realize it or not.
This is why two businesses selling similar products, at similar volumes, can land on completely different SAQs. The determining factor isn’t revenue or transaction count. It’s architecture: does cardholder data ever touch your servers, your network, or your employees, even briefly?
The SAQ Types Most Businesses Actually Encounter
There are eight SAQ types in total, but most businesses fall into a handful of them. Here’s a quick side-by-side before we go through each one in detail.
| SAQ | Typical Business | Complexity |
|---|---|---|
| A | Hosted payment page / iframe | Low |
| A-EP | Merchant hosts checkout page | Medium |
| B | Dial-out payment terminal | Low |
| B-IP | IP-connected standalone terminal | Low |
| C | Internet-connected payment application | Medium |
| D | Custom processing / call centers / stored card data | High |
SAQ A: Fully Outsourced E-Commerce
This is the shortest questionnaire, and the one every online merchant should be trying to qualify for. SAQ A applies when all payment processing is completely outsourced to a PCI-validated third party, and your business has no direct control over how cardholder data is captured or transmitted.
In practice, this means your checkout page redirects entirely to a hosted payment page, or embeds a payment form through an iframe that’s hosted on someone else’s certified infrastructure. We covered how this works mechanically in Payment Tokenization Explained. The customer sees your branding, but the sensitive payment fields are rendered and transmitted entirely outside your environment.
SAQ A-EP: Outsourced, But Your Page Still Touches the Flow
SAQ A-EP applies when your checkout page doesn’t directly receive cardholder data, but it does control or influence how that data gets to the payment page. For example, your website’s own code may load or redirect to the payment page, even though the payment fields themselves are hosted elsewhere.
This is a meaningfully longer questionnaire than SAQ A because your web server and website code are still considered part of the security chain, even though they never see raw card data. A lot of merchants who believe they qualify for SAQ A actually fall into A-EP because of how their checkout page is implemented. The difference often comes down to implementation details most business teams never see and most engineering teams don’t realize are compliance-relevant.
SAQ B and B-IP: Standalone Terminals
These apply to businesses processing payments through standalone, PCI-validated point-of-sale terminals that are either connected by phone line (SAQ B) or IP connection (SAQ B-IP), with no connection to other systems on the merchant’s network. This is common for small retail and service businesses with a dedicated card terminal that doesn’t integrate with any other software.
SAQ C: Payment Application Connected to the Internet
SAQ C applies to merchants using a payment application connected to the internet, where the payment application itself is on a system that’s isolated from other systems in the environment. This covers many point-of-sale software environments where the payment application has internet connectivity but remains properly segmented from the rest of the business network.
SAQ D: Everyone Else
SAQ D is the longest questionnaire, covering hundreds of individual requirements. It applies to any merchant that doesn’t cleanly fit into the categories above. If your business stores cardholder data directly, processes payments through custom-built systems, or handles card data in ways that don’t match one of the outsourced or segmented models above, you’re very likely looking at SAQ D.
Accepting Credit Cards Over the Phone. Without the right architecture, a call center reading card numbers over the phone and keying them into a system is, from a compliance standpoint, functionally the same as a business storing raw card data on its own servers.
The Real Lesson: SAQ Type Follows Architecture
The businesses that consistently qualify for the shortest, simplest SAQs aren’t the ones with the best compliance teams. They’re the ones that made an architectural decision, often years earlier, to keep cardholder data out of their own environment entirely through hosted payment pages, PCI-compliant iframes, or PCI-compliant IVR for phone payments.
We covered this principle more broadly in Building PCI Compliance into Infrastructure. The SAQ you fill out every year is really a report card on a decision your business made about architecture, not a form you can shortcut your way through.
If your business is currently completing SAQ D, or an SAQ A-EP that feels more complicated than it should, the underlying question isn’t, “How do we fill this out faster next year?” It’s, “What would our payment architecture need to look like to qualify for a shorter SAQ?”
Frequently Asked Questions
What is the easiest PCI SAQ?
SAQ A is generally the simplest because the merchant never handles cardholder data directly.
Can I choose which SAQ to complete?
No. Your payment architecture determines which SAQ applies.
Does an iframe qualify for SAQ A?
It can, depending on how it is implemented.
What happens if I complete the wrong SAQ?
Choosing an SAQ that doesn’t match your payment environment can leave your business out of compliance.
Key Takeaways
- There are eight SAQ types, but most businesses fall into SAQ A, A-EP, B, B-IP, C, or D.
- Your SAQ type is determined by how cardholder data flows through your systems. It’s not a form you choose, it’s a classification your architecture assigns you.
- SAQ A (fully outsourced checkout) and SAQ D (everything else, including most in-house or partially in-house setups) represent the biggest gap in scope and effort.
- Phone and call center payments frequently default to SAQ D unless specific PCI-compliant IVR controls are in place.
- Reducing SAQ scope is an infrastructure decision, not a paperwork strategy.
Not Sure Which SAQ Applies to You?
Misclassifying your SAQ type is a common and costly mistake. It can lead to unnecessary compliance overhead or create gaps that expose your business to real risk. If you’re not confident which SAQ applies to your current setup, or you’re looking to reduce your scope entirely, it’s worth having that conversation before your next PCI attestation is due.
Our PCI specialists can review your payment environment and help determine whether your current architecture qualifies for a simpler SAQ or identify opportunities to reduce your PCI scope altogether.
Learn more at www.HostedPCI.com.