Which PCI SAQ Do You Need? A 2-Minute Decision Guide
If you are asking “which PCI SAQ do I need,” the answer comes from mapping how your business accepts and processes credit card payments. Your payment channel dictates your required form. If your acquiring bank or payment processor recently notified you that you must validate your compliance, you are likely staring at a confusing list of nine different forms. You do not get to pick the shortest one.
Finding your form means looking at three things: your payment hardware, your e-commerce website, and your internal computer network. Once you map how a credit card number travels from your customer to your bank, the correct questionnaire becomes obvious.
This guide walks you through the exact scenarios that determine your validation path. We cover the different PCI SAQ types, explain the technical requirements behind them, and show you how to reduce your compliance burden by changing how you handle card data.
Key Takeaways
- Your payment channel, not your business size, determines which of the nine PCI SAQ forms you must complete.
- Most small businesses fall into Level 4 and validate with a self-assessment questionnaire (SAQ) rather than a full on-site QSA audit.
- If your systems never see, touch, or store card data, such as with fully outsourced e-commerce, you likely qualify for the shortest form, SAQ A.
- Storing cardholder data electronically, or not fitting any of the other scenarios, means you need SAQ D, the longest and most comprehensive form.
- Reducing your cardholder data environment through network segmentation can move you to a simpler SAQ and cut your compliance workload.
Understanding PCI SAQ Eligibility and Merchant Levels
PCI SAQ eligibility hinges on two questions: how you handle payments, and whether you store card data. PCI DSS stands for Payment Card Industry Data Security Standard. It is a set of security requirements created and maintained by the PCI Security Standards Council. The major card brands (Visa, Mastercard, American Express, Discover, and JCB) founded this council to protect cardholder data across the globe.
PCI DSS applies to ANY business that accepts, processes, stores, or transmits payment card data. It does not matter how small your business is or how few transactions you process. If you touch card data, the standard applies to you.
This is not a government law in the US. It is a strict contractual obligation enforced by the card brands through your merchant agreement with your payment processor or acquiring bank.
Most small and mid-size businesses validate their compliance annually using a PCI DSS self-assessment questionnaire. However, the card brands tier merchants by annual transaction volume. Under the commonly used tiering, published by Visa and broadly matched by the other brands:
| Merchant Level | Annual Transaction Volume | Validation Method |
|---|---|---|
| Level 1 | Over 6 million transactions per year | On-site assessment by a Qualified Security Assessor (QSA), producing a Report on Compliance (ROC) |
| Level 2 | 1 to 6 million transactions | Self-assessment questionnaire (SAQ) |
| Level 3 | 20,000 to 1 million e-commerce transactions | Self-assessment questionnaire (SAQ) |
| Level 4 | Fewer than 20,000 e-commerce transactions, or up to 1 million total transactions | Self-assessment questionnaire (SAQ) |
Most small businesses fall into Level 4 and validate with a PCI compliance SAQ. Exact thresholds and validation requirements are set by each card brand and your acquirer. If you need more details on these tiers, read our guide on PCI merchant levels explained.
The Decision Tree: Which PCI SAQ Do I Need for My Payment Setup?
Three factors determine your SAQ form. Before matching your scenario to the table below, confirm these:
- Do you store cardholder data electronically? Storing card data, PANs, track data, or CVV codes, always pushes you into SAQ D, regardless of your payment channel.
- Does your payment hardware connect to the internet? Internet-connected terminals bring your network security into scope. Dial-out or phone-line terminals keep network security largely out of scope.
- Does your website touch the payment form? Hosting the checkout page yourself (even if you never store the data) requires SAQ A-EP. Redirecting entirely to a processor’s hosted page keeps you at SAQ A.
Match your operations to the correct scenario:
| Payment / Business Scenario | Required SAQ |
|---|---|
| E-commerce payment processing is fully outsourced to a third party | SAQ A |
| Your website code affects the security of the payment page | SAQ A-EP |
| You use standalone dial-out terminals with no internet connection | SAQ B |
| You use standalone IP-connected terminals over the internet | SAQ B-IP |
| You manually type card numbers into a secure web browser | SAQ C-VT |
| You use internet-connected payment application systems | SAQ C |
| You use validated hardware encryption terminals | SAQ P2PE |
| You store card data electronically, or fit none of the above scenarios | SAQ D |
PCI SAQ Types Explained by Scenario
Each SAQ type maps to a specific payment scenario. Confirm your match below. The current version of the standard is PCI DSS 4.0.1 (it superseded 4.0, while version 3.2.1 was retired March 31, 2024). The future-dated requirements introduced with PCI DSS 4.0 became mandatory on March 31, 2025. Make sure you are completing the correct version of your required form.
Here is how the eight scenarios compare before we walk through each one in detail:
| SAQ Type | Merchant Profile | Stores Cardholder Data Electronically? |
|---|---|---|
| SAQ A | Fully outsourced e-commerce, payment page hosted entirely by a third-party processor | No |
| SAQ A-EP | Partially outsourced e-commerce, your website hosts the payment form or posts directly to the processor | No |
| SAQ B | Standalone dial-out terminals connected by telephone line, not the internet | No |
| SAQ B-IP | Standalone terminals connected to your processor over the internet (IP network) | No |
| SAQ C-VT | Manual entry into a hosted virtual terminal, no automated systems | No |
| SAQ C | Internet-connected point-of-sale or payment application systems | No |
| SAQ P2PE | Validated point-to-point encryption hardware terminals | No (encrypted at swipe or dip) |
| SAQ D | Everyone else, including service providers | Yes |
SAQ A: Fully Outsourced E-commerce
Your website redirects customers to a secure payment page hosted entirely by a processor like Stripe or PayPal. Your web servers never see, touch, or process the cardholder data. Because your systems are completely removed from the payment flow, SAQ A is one of the shortest and easiest forms to complete. Processors like Stripe, PayPal, and Square typically provide a pre-filled SAQ A or a compliance attestation document you can submit directly to your acquirer.
SAQ A-EP: Partially Outsourced E-commerce
If you host the payment form on your own website and use an API or direct post method to send the data to your processor, you fall into this category. Even if you do not store the data, your web server is in scope. If a hacker breaches your website, they could alter your checkout page code to steal card data before it ever reaches the processor. This form requires significantly more security controls than SAQ A.
SAQ B: Dial-Out Terminals
These terminals must connect via a standard telephone line, not the internet. Furthermore, you cannot store any cardholder data electronically. Because these machines do not touch your computer network, your network security is largely out of scope.
SAQ B-IP: Internet-Connected Terminals
Unlike SAQ B, these devices touch your internet connection, so your network security matters. Here is the distinction: SAQ B terminals connect over a telephone line and never touch your computer network, so network security stays largely out of scope. SAQ B-IP terminals connect over the internet, which brings your network configuration, firewall rules, and traffic isolation into scope. You must ensure the network traffic is secure and that the terminals are isolated from other network threats.
SAQ C-VT: Virtual Terminals
The virtual terminal must be provided by a validated third-party service provider. This scenario is common for businesses that take phone orders and type the card details directly into a secure web browser window. You cannot use automated systems to read or enter the data under this form.
SAQ C: Internet-Connected Payment Applications
If you run point-of-sale software on a computer that is also connected to the internet, you are in this category. This requires rigorous security controls. A machine taking credit card payments while also being exposed to internet threats like email phishing or web malware presents a massive security risk.
SAQ P2PE: Hardware Encryption
In this setup, the card data is encrypted at the exact moment of swipe or dip inside the hardware terminal itself. It remains encrypted until it reaches the payment processor. Since your computer network only ever sees encrypted data, your compliance burden drops significantly.
SAQ D: The Catch-All and Service Providers
If you store cardholder data electronically, you must complete SAQ D. It is the longest and most comprehensive form. It is also the specific version required for service providers who handle card data on behalf of other businesses.
SAQ A vs. SAQ D: The Two Ends of the Spectrum
The gap between the easiest and hardest form is stark. Here is how the two endpoints compare:
| SAQ A (Shortest) | SAQ D (Longest) | |
|---|---|---|
| Question count | ~25 questions | ~330 questions |
| Scope | Your systems never touch card data | Every system in your cardholder data environment |
| Typical merchant | E-commerce site that redirects to Stripe checkout | Business that stores card numbers in its own database |
| Key burden | Confirm your processor handles everything | Prove you meet all 12 PCI DSS requirements across your entire network |
If you can change how you handle card data to move left on this spectrum, you cut your compliance workload by an order of magnitude.
The Burden of SAQ D and the 12 Requirements
SAQ D covers nearly all 12 PCI DSS requirements under 6 goals set by the PCI Security Standards Council. The full weight of the standard explains why you want to avoid SAQ D if possible — and what you are signing up for if you cannot.
| Goal | PCI DSS Requirements | What This Means in Plain English | Key Action |
|---|---|---|---|
| Build and Maintain a Secure Network | Req 1: Firewalls and router configurations / Req 2: No vendor default passwords or settings | Segment your network. Change every default credential on routers, firewalls, and payment hardware. Hackers actively scan for factory-default admin passwords. | Inventory every internet-facing device and confirm no default credentials remain. |
| Protect Cardholder Data | Req 3: Protect stored account data / Req 4: Encrypt transmission across open networks | You may never store the CVV or full magnetic-stripe data after authorization, even encrypted. Protect PANs with strong cryptography in transit. | Audit what you store. Delete any file containing CVVs, full track data, or unencrypted card numbers. |
| Maintain a Vulnerability Management Program | Req 5: Antivirus and anti-malware / Req 6: Secure systems through patching | Every system touching card data must run current antivirus. Unpatched software is one of the most common entry points for ransomware and data breaches. | Automate OS and application patching. Schedule it. An unpatched POS machine browsing the web is the classic breach vector. |
| Implement Strong Access Control Measures | Req 7: Restrict access by business need-to-know / Req 8: Unique IDs and MFA / Req 9: Physical access controls | Least-privilege access to cardholder data. Every user gets a unique login. Multi-factor authentication is mandatory for access into the cardholder data environment. | Enforce MFA on every system that can reach card data. Restrict physical server-room and terminal access. |
| Regularly Monitor and Test Networks | Req 10: Log and monitor all access / Req 11: Test security systems regularly | Log every access to cardholder data. Run quarterly external vulnerability scans through an Approved Scanning Vendor. Conduct penetration testing. | Schedule quarterly ASV scans. Set up centralized logging with alerting on anomalous access patterns. |
| Maintain an Information Security Policy | Req 12: Information security policy and program | A written, management-approved security policy covering all 12 requirements. Reviewed annually. Communicated to every employee. | Document your security policy. Train staff on it. Review and update it at least once a year. |
For a deeper explanation of the individual rules, you can review our guide to the 12 PCI DSS requirements explained in plain English.
How Scope Reduction Can Move You to a Simpler SAQ
The most effective way to simplify compliance is to shrink your cardholder data environment (CDE). The CDE is the set of systems, people, and processes that store, process, or transmit cardholder data or sensitive authentication data, plus any system connected to them.
What is in scope. Cardholder data includes the primary account number (PAN), cardholder name, expiration date, and service code. Sensitive authentication data includes the CVV or CVC security code, full magnetic-stripe or track data, and PINs. As a reminder, sensitive authentication data may NEVER be stored after authorization under any circumstances.
Network segmentation: the core lever. If your point-of-sale terminals share the same network as your employee workstations and your guest Wi-Fi, your entire network is in scope. Every workstation, every guest device, every server must meet PCI DSS. If you use network segmentation to isolate your payment terminals on their own secure, restricted network, only that isolated network is in scope. By physically or logically separating your payment systems, you can often qualify for a simpler questionnaire.
Here is how your payment channel and your data-storage habits combine to determine your form:
| Payment Channel | Does Not Store Card Data Electronically | Stores Card Data Electronically |
|---|---|---|
| E-commerce, fully outsourced to a processor | SAQ A | SAQ D |
| E-commerce, payment form hosted on your own site | SAQ A-EP | SAQ D |
| Standalone dial-out terminal (phone line, no internet) | SAQ B | SAQ D |
| Standalone IP-connected terminal | SAQ B-IP | SAQ D |
| Manual entry into a hosted virtual terminal | SAQ C-VT | SAQ D |
| Internet-connected POS or payment application | SAQ C | SAQ D |
| Validated point-to-point encryption (P2PE) hardware | SAQ P2PE | SAQ D |
Whichever channel you use, storing card data electronically always pushes you into SAQ D, the catch-all form.
The Cost of Getting it Wrong
Failing to complete your PCI self-assessment questionnaire accurately carries severe business risks. The consequences of non-compliance flow directly through your processor, and they escalate the longer the gap goes unresolved:
| Stage | What Happens |
|---|---|
| Ongoing non-compliance | Non-compliance fees added to your merchant account, with the amount and schedule set by your processor and acquiring bank |
| A breach occurs while non-compliant | Forensic investigation costs, card-brand assessments passed through your acquirer, card reissuance costs, and often higher processing rates, all set by your processor and the card brands |
| Worst case | Loss of the ability to accept credit cards at all, a death sentence for most retail and e-commerce businesses |
How an IT Partner Helps You Answer Truthfully
Business owners frequently ask how to complete a PCI SAQ without spending weeks deciphering technical jargon. The truth is that you cannot just check “yes” on the form to make your processor happy. Checking “yes” means you actually have the technical controls in place. If you suffer a breach and investigators find you lied on your SAQ, the financial fallout will be devastating.
This is where a managed IT provider steps in. LeadingIT operates the technical half of PCI as part of managed IT services. We implement the required network segmentation, enforce multi-factor authentication (MFA), handle the relentless software patching, configure the access logging, and manage scan remediation.
We help clients complete their SAQ correctly by providing the actual evidence, scans, and controls required to answer the questions truthfully. Please note that LeadingIT is NOT a QSA or ASV and does not certify PCI compliance. We help you become and stay compliant by managing the heavy technical lifting behind the scenes.
See Where You Stand
Free 2-minute PCI self-check: 8 plain-English questions, your risk level and the exact gaps to fix. No sign-up to see your result. free PCI compliance risk check
Related Guides
- What Is PCI Compliance? A Plain-English Guide
- The 12 PCI DSS Requirements Explained in Plain English
- PCI Compliance Levels 1-4: Which Merchant Level Are You?
- What Is the Cardholder Data Environment (CDE)? PCI Scope
Frequently Asked Questions
What is an SAQ for PCI compliance?
An SAQ is a validation tool used by small and mid-size businesses to prove they meet the Payment Card Industry Data Security Standard. It is a detailed checklist where you confirm that you have implemented specific security controls to protect credit card data. You submit this document annually to your payment processor or acquiring bank.
What does SAQ stand for in PCI?
SAQ stands for Self-Assessment Questionnaire. It is the official document provided by the PCI Security Standards Council for eligible merchants to self-validate their compliance without needing an expensive on-site audit.
How to complete a PCI SAQ?
You must first determine which of the nine questionnaire types applies to your payment processing method. Then you must review your network and business practices to ensure you meet every requirement listed on that specific form. Most businesses rely on their managed IT provider to implement the necessary technical controls so they can truthfully answer the questions.
What is the purpose of a PCI SAQ?
The purpose is to force businesses to evaluate their own security posture and confirm they are actively protecting cardholder data. It provides your payment processor with documented proof that you are following the contractual security rules set by the major credit card brands.
How often is a PCI SAQ required?
Most merchants who are eligible to self-assess must submit a new, updated questionnaire annually. You must also update your submission if you make significant changes to your computer network or change how you process credit card payments.
Secure Your Business with LeadingIT
Stop guessing on your compliance paperwork and risking your merchant account. LeadingIT is a Chicagoland managed it and cybersecurity provider that has helped Illinois businesses since 2010. We serve roughly 200 organizations and 2,500+ users from our offices in Woodstock and Manteno.
If you need help implementing the technical controls required for your questionnaire, explore LeadingIT’s PCI compliance services (done-for-you path), contact us directly, or book a call today. You can also reach us by phone at 815-788-6041.
