Note: This is educational guidance, not a formal compliance determination — always confirm your eligibility with your acquirer or a Qualified Security Assessor before self-certifying. This guide also contains affiliate links; if you buy through them Oreaxe may earn a commission at no extra cost to you, and it never affects our guidance. See How We Evaluate.
PCI SAQ A is the shortest, most sought-after path to PCI DSS compliance — and the one merchants most often use incorrectly. It’s built for e-commerce and mail/telephone-order businesses that hand off all card handling to a compliant provider, shrinking compliance from hundreds of controls to roughly thirty. But the line between qualifying for SAQ A and being bumped into SAQ A-EP (with its ~150 requirements) is narrower than most merchants realise, and a 2025 rule change moved it again. This guide is the complete, current picture.
New to SAQ types in general? Start with our overview of which PCI SAQ applies to your business, then come back here for the SAQ A deep dive.
What is PCI SAQ A?
SAQ A is a Self-Assessment Questionnaire for merchants who have fully outsourced all cardholder data functions to PCI DSS compliant third parties. If card data never touches your systems — because a compliant payment provider captures, processes, and stores all of it — you carry the smallest compliance burden the standard offers. That’s why SAQ A is the most popular questionnaire among small merchants: it’s the lightest, at around 30 requirements versus the full standard’s 300-plus.
But “lightest” is conditional. SAQ A has strict eligibility criteria, and meeting most of them isn’t enough — you must meet all of them.
SAQ A eligibility criteria
To validate under SAQ A for an e-commerce or MOTO payment channel, you must be able to confirm every one of the following:
- You accept only card-not-present transactions (e-commerce or mail/telephone order). SAQ A never covers in-person, card-present payments.
- All processing of account data is entirely outsourced to a PCI DSS compliant third-party service provider (TPSP).
- You do not electronically store, process, or transmit any account data on your own systems or premises — you rely entirely on the TPSP.
- You have confirmed that every TPSP handling account data is PCI DSS compliant.
- Any account data you retain exists only on paper (such as printed receipts or reports) and is not received electronically.
- (New in 2025, for embedded/iframe merchants): you have confirmed your site is not susceptible to script attacks that could affect your e-commerce systems.
If even one of these doesn’t hold — for example, your checkout page receives or touches card data in any way — SAQ A is off the table.
The distinction that decides everything: redirect, iframe, or Direct Post
This is where merchants get it wrong, and it’s worth getting exactly right because it determines your entire scope. SAQ A eligibility hinges on how your checkout connects to your payment provider:
| Integration method | What it means | Your SAQ |
|---|---|---|
| Full redirect | Your site sends the customer to the provider’s hosted payment page; card data is entered on the provider’s domain | SAQ A |
| iframe (embedded) | A payment form served entirely from the compliant provider’s domain is embedded in your page via an inline frame; card data goes straight to the provider, never your server | SAQ A |
| Direct Post / JavaScript form / payment widget | Your own page elements collect or control the card data flow before sending it on | SAQ A-EP (~150 requirements) |
The security difference is real, not bureaucratic: with a redirect or a true iframe, card data is entered in a context your server can’t touch, so a script on your page can’t transparently steal it. With Direct Post or a JavaScript form, your code is in the data path — which is exactly why those methods carry the heavier SAQ A-EP scope.
A critical, frequently-missed nuance: even a single analytics tag, retargeting pixel, or any script loaded from your own domain on the checkout page can change your scope. “We use a hosted checkout, so we’re covered” is the misconception that costs merchants the most. Eligibility is precise, and your acquirer has the final word.
SAQ A vs SAQ A-EP vs SAQ D: the cost of getting it wrong
The stakes of misclassification are not abstract:
- SAQ A — ~30 requirements.
- SAQ A-EP — ~150 requirements, including external vulnerability scanning, penetration testing, and change management.
- SAQ D — the full standard, for anyone storing cardholder data or not eligible for a lighter SAQ.
A merchant who wrongly self-certifies under SAQ A when they should be SAQ A-EP skips over a hundred security controls. If a breach follows, that gap turns a compliance shortcut into a liability — your attestation was invalid, and the controls that might have caught the attack were never in place. Under-scoping doesn’t reduce your risk; it just hides it.
The 2025 SAQ A change older guides still get wrong
If you’re reading SAQ A advice written before 2025, assume it’s out of date on this point. In January 2025, ahead of the PCI DSS v4.0.1 mandatory date of March 31, 2025, the PCI Security Standards Council revised SAQ A:
- It removed Requirements 6.4.3 (payment-page script authorization and integrity) and 11.6.1 (change-and-tamper detection on payment pages), along with 12.3.1 (the targeted risk analysis supporting 11.6.1).
- It added a new eligibility criterion: the merchant must confirm their site is not susceptible to script attacks affecting their e-commerce systems.
The Council then issued FAQ 1588 to clarify it, and the clarification matters:
- The new criterion applies only to iframe/embedded merchants — it does not apply to merchants who fully redirect or fully outsource (e.g., emailing a payment link).
- Iframe merchants can satisfy it two ways: by deploying script-protection techniques themselves (such as those formerly in 6.4.3 and 11.6.1), or by obtaining confirmation from their compliant payment provider that the provider’s embedded solution protects against script attacks.
The practical effect is a quiet trap: SAQ A looks simpler because two technical requirements were removed, but iframe merchants still need equivalent protection to qualify — just expressed as an eligibility bar rather than a numbered control. And note that SAQ A-EP merchants, SAQ D merchants, and service providers must still comply with 6.4.3 and 11.6.1 in full.
What SAQ A actually requires you to do
Even at ~30 requirements, SAQ A isn’t a formality. The control families you’ll attest to include:
- Third-party service provider management (Requirement 12.8): maintaining a list of your TPSPs, written agreements acknowledging their responsibility for the cardholder data they handle, and due diligence on their PCI DSS compliance. This applies to every SAQ A merchant.
- External vulnerability (ASV) scanning (Requirement 11.3.2): quarterly scans of the webserver that hosts your redirect mechanism or iframe page. This is one of the most commonly overlooked SAQ A obligations — many merchants don’t realise their redirect/iframe server is in scope for scanning.
- Webserver protection (Requirements 2 and 6): managing vendor default accounts and vulnerability management on the server that delivers the payment-page URL or iframe to the customer’s browser.
- Access control (Requirement 8): strong authentication for any administrative access to the in-scope webserver — unique IDs, no shared logins, and MFA.
- Protecting paper records (Requirements 3 and 9): if you retain printed receipts or reports with account data, securing them and destroying them when no longer needed.
- Security policies (Requirement 12): documented policies and an incident response capability.
Where SAQ A meets real-world controls
Identifying SAQ A is the start; operating the controls is the work — and authentication is where small teams most often slip. Strong, unique credentials and MFA on your webserver and provider accounts map directly to Requirement 8; our guide to PCI DSS 4.0.1 authentication requirements covers exactly what an assessor checks. Enforcing that credential hygiene across a small team — unique passwords, no sharing, MFA everywhere — is precisely where a tool like Proton Pass earns its place. SAQ A tells you what you’re accountable for; disciplined process and the right tools are how you actually deliver it.
How to complete SAQ A, step by step
- Confirm eligibility with your acquirer. Before anything else, verify that SAQ A is the right questionnaire for your payment channel and that your transaction volume permits self-assessment.
- Scope your environment. Identify every system that touches the payment flow — including the server delivering your redirect or iframe, and any scripts on your checkout page.
- Confirm the script-protection criterion (if you use an iframe), either by implementing controls or getting your provider’s written confirmation.
- Complete the questionnaire, answering each requirement honestly with In Place / Not Applicable responses and documenting any “Not Applicable” justifications.
- Run quarterly ASV scans of the in-scope webserver if applicable, using a qualified scanning vendor.
- Complete the Attestation of Compliance (AOC) and submit it, with any required scan reports, to your acquirer or the requesting entity.
Common SAQ A mistakes to avoid
- Assuming a hosted checkout automatically means SAQ A — scripts on your own page can change everything.
- Confusing a true iframe with Direct Post or a JavaScript form — the latter is SAQ A-EP.
- Forgetting the ASV scan on the redirect/iframe-hosting server.
- Relying on pre-2025 guidance that still treats 6.4.3 and 11.6.1 as SAQ A requirements.
- Self-certifying without acquirer confirmation — your bank, not you, has the final say.
- Skipping TPSP due diligence under Requirement 12.8.
Frequently asked questions
What is PCI SAQ A? A Self-Assessment Questionnaire for merchants who fully outsource all cardholder data handling to PCI DSS compliant providers, with around 30 requirements — the lightest PCI DSS validation path.
Who qualifies for SAQ A? Card-not-present (e-commerce or MOTO) merchants who store, process, and transmit no card data themselves, use a redirect or compliant iframe, and (if using an iframe) can confirm their site is protected against script attacks.
What’s the difference between SAQ A and SAQ A-EP? SAQ A is for merchants whose payment page is fully controlled by a compliant provider (redirect or iframe). SAQ A-EP — roughly 150 requirements — applies when your own page controls the card data flow, such as Direct Post or JavaScript forms.
Did SAQ A change in 2025? Yes. Requirements 6.4.3, 11.6.1, and 12.3.1 were removed and replaced with a new eligibility criterion requiring iframe merchants to confirm their site isn’t susceptible to script attacks.
Do SAQ A merchants need ASV scans? Yes — quarterly external scans of the webserver hosting the redirect or iframe are typically required.
Bottom line
SAQ A is the lightest PCI DSS path, but it is also the easiest to claim incorrectly. Qualifying comes down to a precise question — does any part of your own environment touch the card data flow? — and the 2025 changes mean iframe merchants now also have to prove their site is protected against script attacks. Map your checkout honestly, treat a single stray script as a scope-changer, run your ASV scans, and confirm your answer with your acquirer before you sign the attestation. Get SAQ A right and compliance is genuinely manageable; get it wrong and it’s the kind of mistake that only surfaces when it’s most expensive.
Muhammad Saqlain is the founder of Oreaxe and a digital transformation and cybersecurity consultant. He helps small and mid-sized businesses modernise their operations and meet real security and compliance requirements — PCI DSS, ISO 27001, and SOC 2 — without the jargon or the fear-selling.
Mubbashir Ali has spent 17+ years in the engine room of enterprise IT — running multi-cloud infrastructure, hardening Linux fleets, and hunting vulnerabilities with OpenVAS and Nessus. A Certified Ethical Hacker (CEH v12) and AWS Solutions Architect, he leads IT operations by day and brings the hands-on technical depth — the actual scanning, hardening, and incident response — to Oreaxe's security coverage.