PCI DSS SAQ Complete Guide
The PCI DSS SAQ (Self-Assessment Questionnaire) is how merchants prove they meet PCI DSS requirements without a full QSA-led audit. If your business processes credit card payments and you handle a small enough transaction volume, you self-attest to PCI compliance using one of nine SAQ types. This guide covers all nine SAQ types, how to pick the right one, what each one requires, and the most common mistakes that lead to PCI DSS SAQ failures.
The SAQ exists because the cost of a full PCI audit (with a Qualified Security Assessor) is too high for small merchants. The PCI Security Standards Council created the SAQ as a tiered self-assessment path: low-risk merchants answer fewer questions, high-risk merchants answer more. The right SAQ for your business depends entirely on how you accept and process card data.
If you are new to PCI DSS, start with the PCI DSS compliance guide for the framework basics. For the underlying control list, see PCI DSS 4.0 requirements. If you are weighing PCI DSS against SOC 2, read PCI DSS vs SOC 2.
What is the PCI DSS SAQ?
The Self-Assessment Questionnaire is a validation tool published by the PCI Security Standards Council. Merchants use it to attest annually that they meet the PCI DSS requirements that apply to their card data environment. The completed SAQ, signed by an executive officer, is sent to your acquiring bank or payment processor as proof of compliance.
The SAQ replaces a full Report on Compliance (ROC) for Level 2, 3, and 4 merchants who qualify. Level 1 merchants (those processing 6 million-plus card transactions per year, or any merchant Visa or Mastercard requires) must complete a full ROC with an external Qualified Security Assessor (QSA), not an SAQ.
The SAQ is not "PCI lite." Every question in your applicable SAQ must be answered "Yes" or "Compensating Control" to attest compliance. A single "No" makes you non-compliant for the year. Acquiring banks can fine non-compliant merchants $5,000 to $100,000 per month, and processors can suspend your merchant account.
The nine SAQ types: which one applies to you?
The PCI Council defines nine SAQ types. The right one depends on your card acceptance method, whether you store card data, and whether you use a PCI-compliant third-party processor. The table below summarizes each type.
| SAQ type | Who uses it | Typical questions |
|---|---|---|
| SAQ A | E-commerce merchants who fully outsource card processing (iframe or redirect to PCI-compliant processor) | ~22 |
| SAQ A-EP | E-commerce merchants whose website partially manages payment pages but does not store, process, or transmit card data | ~191 |
| SAQ B | Merchants using only standalone, dial-out terminals (no internet connection) | ~41 |
| SAQ B-IP | Merchants using only standalone IP-connected terminals (validated PTS POI) | ~83 |
| SAQ C | Merchants with payment application systems connected to the internet | ~160 |
| SAQ C-VT | Merchants who manually key in card data through a virtual terminal on a single isolated computer | ~80 |
| SAQ P2PE | Merchants using a validated point-to-point encryption (P2PE) solution | ~33 |
| SAQ D-MER | All other merchants who do not qualify for any other SAQ (default catchall) | ~330 |
| SAQ D-SP | Service providers (not merchants) eligible for SAQ instead of ROC | ~370 |
The SAQ A is the easiest path. If you fully outsource card processing to a PCI Level 1 service provider (Stripe, Adyen, Braintree, Authorize.net) using an iframe or redirect, you complete SAQ A and answer about 22 questions. This is the right path for almost every modern e-commerce business.
The SAQ D is the hardest path. If you store card data in any form, even encrypted, you complete SAQ D with over 300 questions. Most merchants who land here did not realize they had a path to a simpler SAQ.
How to pick the right SAQ
Picking the wrong SAQ is the most common PCI DSS mistake. Merchants self-select SAQ A because it is the easiest, then fail an audit when they realize their checkout flow does not actually qualify. The decision tree below maps your card acceptance method to the right SAQ.
Step 1: Do you store cardholder data anywhere in your environment?
If yes, you complete SAQ D. Cardholder data includes the primary account number (PAN), cardholder name, expiration date, and service code. Even encrypted PAN counts as stored data.
Step 2: Is your only card acceptance method a payment terminal?
If yes and the terminal is dial-out only with no internet, you complete SAQ B. If the terminal is IP-connected and PCI PTS-validated, you complete SAQ B-IP. If the terminal uses a validated P2PE solution, you complete SAQ P2PE.
Step 3: Do you take card data through a web checkout?
If your checkout fully redirects to or fully iframes a PCI Level 1 provider's hosted payment page, and your servers never see card data, you complete SAQ A. If your servers receive any card data (even briefly through Direct Post integration), you complete SAQ A-EP.
Step 4: Do you key in card data through a virtual terminal?
If you key cards through a vendor-provided web application on a single dedicated computer with no other use, you complete SAQ C-VT.
Step 5: Do you have a payment application connected to the internet?
If you run a payment application (POS system, custom checkout) connected to the internet, you complete SAQ C.
Step 6: None of the above?
Default to SAQ D-MER. This is the catchall for merchants whose environment does not fit any simpler SAQ.
What SAQ A actually requires
SAQ A is the most common SAQ for e-commerce merchants in 2026. It has the fewest questions because the merchant outsources virtually all PCI scope to a third-party processor. To qualify, your e-commerce site must redirect customers to the processor's hosted payment page, or embed the processor's iframe so card data flows directly from the customer's browser to the processor without touching your servers.
The 22 questions in SAQ A cover policy, training, vendor management, and basic account security. You will be asked about:
- Whether you have a written information security policy reviewed annually.
- Whether you maintain a list of third-party service providers and have written agreements.
- Whether the third-party processor handles all storage, processing, and transmission of cardholder data.
- Whether your merchant ID and processor account credentials are protected with strong passwords and MFA.
- Whether you train employees on PCI requirements at hire and annually thereafter.
- Whether you have an incident response plan and contact information.
You do not need a vulnerability scan, a penetration test, or network segmentation evidence for SAQ A. You do not need to encrypt anything (the processor does it). You do not need a firewall (the processor's environment has them). The lift is mostly documentation.
What SAQ A-EP actually requires
SAQ A-EP is for e-commerce merchants who use a third-party processor but whose own website is involved in serving the payment page. The most common case is "Direct Post" integrations where the merchant's HTML form posts card data to the processor's API. Even though the merchant never stores or processes the data, the merchant's web server is in scope because it could be compromised to redirect or skim card data.
SAQ A-EP has about 191 questions, almost ten times more than SAQ A. It requires:
- Quarterly external vulnerability scans by an Approved Scanning Vendor (ASV).
- Annual penetration testing of your web environment.
- Network segmentation between your card environment and the rest of your business.
- File integrity monitoring on web servers.
- Daily review of security logs.
- Anti-malware on all systems with access to card data.
If you can move from SAQ A-EP to SAQ A by switching from Direct Post to iframe or redirect integration, do it. The compliance lift drops by 80 percent or more.
Common PCI DSS SAQ mistakes
Most SAQ failures and self-attestation issues come from a handful of recurring mistakes. The list below covers what acquiring banks and processors flag most often.
Self-selecting the wrong SAQ. Merchants pick SAQ A because it is the easiest, then fail QSA review when their checkout actually qualifies for A-EP or D. If your servers see card data at any point, even briefly, you do not qualify for SAQ A.
Storing card data without realizing it. A surprising number of merchants store cardholder data in CRM notes, email backups, customer service tickets, or call recordings. Any storage of full PAN forces you into SAQ D. Use a tokenization service or DLP scanning to find and remove stored card data.
Skipping the annual ASV scan. SAQ A-EP, B-IP, C, C-VT, D, and D-SP all require quarterly external vulnerability scans by a PCI-approved scanning vendor. Merchants forget to schedule these, then submit an SAQ with the "external scan" question blank. This invalidates the attestation.
Skipping penetration testing. SAQ A-EP, C, D-MER, and D-SP all require annual penetration testing. SAQ D environments require both internal and external pen tests. The pen test must be performed by a qualified party (internal or external) and documented.
No incident response plan. Every SAQ requires a documented incident response plan. Many small merchants have nothing written down. Use the PCI SSC's incident response guidance to draft a basic plan, then test it once per year.
Lapsed third-party agreements. Every PCI-related third party (processor, hosting provider, customer service vendor with card data exposure) needs a written agreement that explicitly addresses PCI responsibilities. SAQ Section 12.8 requires a current list of all such providers and their AOC (Attestation of Compliance).
How often do you need to complete the SAQ?
PCI DSS SAQ is an annual exercise. You complete it once per year and submit the signed Attestation of Compliance (AOC) to your acquiring bank or processor. Most processors send you a reminder 30 to 60 days before your renewal date.
If your environment changes during the year (new payment method, new card acceptance channel, acquired company, infrastructure change), you may need to recomplete the SAQ or move to a different SAQ type. Major changes within 90 days of the previous attestation often require a re-validation.
Some processors and acquirers have stricter cadences. American Express requires Level 2 merchants to validate annually with an SAQ or ROC. Visa, Mastercard, and Discover each have their own validation matrix tied to merchant level. Check with your acquirer for the exact requirement.
SAQ vs ROC: when do you need a full audit?
The SAQ is for merchants who qualify for self-assessment. A Report on Compliance (ROC) is required when self-assessment is not allowed. The split is determined by merchant level, set by the card brands.
| Merchant level | Annual transaction volume | Validation requirement |
|---|---|---|
| Level 1 | 6M+ transactions per card brand, or any merchant the brand designates | ROC (full QSA audit) |
| Level 2 | 1M to 6M transactions per card brand | SAQ or ROC (acquirer's choice) |
| Level 3 | 20K to 1M e-commerce transactions per card brand | SAQ |
| Level 4 | Under 20K e-commerce transactions or under 1M total | SAQ |
A full ROC costs $30,000 to $200,000+ depending on company size and scope. The QSA spends 4 to 12 weeks on site or remote, reviews evidence for every PCI DSS requirement, and produces a 100-plus page report. Most SaaS service providers and large merchants land in this bracket.
If you are a Level 2 merchant whose acquirer accepts an SAQ, completing SAQ D yourself with a consultant or internal compliance team typically costs $5,000 to $20,000 in year one, including ASV scans and pen tests. This is one tenth the cost of a ROC.
SAQ completion in six steps
A simple sequence small merchants and SaaS startups can follow:
- Confirm your merchant level with your acquirer (most SMBs are Level 4).
- Pick the right SAQ type using the decision flow above.
- Document your cardholder data flow: where it enters, where it lives, where it leaves.
- Tighten scope: outsource as much as possible to PCI-certified processors so you can use SAQ A.
- Complete the SAQ: answer every control honestly, attach the AOC.
- File annually with your acquirer and run a quarterly ASV scan if your SAQ requires one.
Frequently Asked Questions
How long does it take to complete the PCI DSS SAQ?
SAQ A typically takes 1 to 2 weeks if you have your documentation in order. SAQ A-EP, C, and C-VT take 4 to 8 weeks. SAQ D takes 8 to 16 weeks for first-time completion. Plan for ASV scans and pen tests to add 2 to 4 weeks to any SAQ that requires them.
Do I need an external auditor for the SAQ?
No. The SAQ is a self-assessment. You can complete it without external help. Many merchants engage a QSA or PCI consultant for a few hours of advisory time, especially for SAQ A-EP and SAQ D, but it is not required.
What happens if I fail the PCI DSS SAQ?
Failure means at least one question was answered "No" and you cannot attest to compliance. Acquiring banks can fine you $5,000 to $100,000 per month until you remediate. Repeated non-compliance can result in your merchant account being terminated.
Is the PCI DSS SAQ free?
The SAQ form itself is free from the PCI Security Standards Council website. The cost is in the work required to comply: ASV scans ($1,500 to $5,000 per year), pen tests ($5,000 to $25,000 per year), security tools, and internal time.
Can I use a compliance platform to complete the SAQ?
Yes. Vanta, Drata, and Secureframe all support PCI DSS SAQ workflows. The platform pre-fills evidence collection, maps your environment to the SAQ questions, and generates the AOC for executive signature. This typically cuts SAQ completion time in half.
What is the difference between SAQ A and SAQ A-EP?
SAQ A is for merchants whose website redirects to or fully iframes a PCI-compliant processor. The merchant's servers never see card data. SAQ A-EP is for merchants whose website serves the payment page or hosts code involved in capturing card data, even if the data flows directly to the processor. SAQ A has 22 questions, A-EP has 191.
