SAQ A Eligibility Checklist — Do You Qualify?

Last updated: 29 May 2026

If you're trying to work out whether your business qualifies for SAQ A, you're already on the right track. SAQ A is the shortest, cheapest, and least painful PCI self-assessment available to merchants — and it's the goal for almost every e-commerce or contact-centre operator who's looked at the 300-question monster that is SAQ D. But the eligibility rules are tighter than most people realise, and getting it wrong means you've been signing the wrong attestation for years. So let's walk through the checklist properly.

We've spent the last decade helping merchants — from FTSE-listed retailers to single-site charities — work out which SAQ they actually qualify for. The pattern is always the same: someone reads the SAQ A header on a PCI Council PDF, sees "card-not-present merchants", and assumes they're in. They submit the SAQ. Then an acquirer audit or a forensic investigation finds card data sitting in a CRM, a call recording, or a webhook log, and the whole thing unwinds. This article exists so that doesn't happen to you.

The one-line rule for SAQ A eligibility#

Here's the rule, pulled straight from the PCI DSS v4.0.1 SAQ A document and translated into English: your business must fully outsource every part of the payment process to PCI DSS-validated third parties, and your own systems must have no access to cardholder data in any form. That's it. Everything else in this article is a way of pressure-testing whether that one sentence is actually true for you.

It sounds simple, but "no access to cardholder data" is doing a lot of heavy lifting. It doesn't mean "we don't store card numbers in our database". It means: card data never enters any system you control, never crosses any network you operate, and is never visible to any of your staff. If a customer reads their card number to one of your agents and the agent types it into a hosted payment form, you've failed the test — the agent's screen, the agent's workstation, and the call recording all touched the data. That's SAQ A-EP territory at best, and SAQ D in many setups.

The PCI Council's own definition is clear: SAQ A is for merchants whose "payment processing functions are fully outsourced to a PCI DSS-validated third-party service provider". If you want the full background on how SAQ A fits into the broader PCI hierarchy, our pillar on SAQ A guide walks through the whole framework. This post is the eligibility decision tree.

The SAQ A eligibility checklist — nine questions, all must be yes#

Run through these nine questions honestly. Every single one needs a clear yes. A single no, or even a "sort of", pushes you out of SAQ A and into one of the heavier questionnaires.

Question 1: Do you only accept card-not-present transactions? SAQ A is exclusively for card-not-present (CNP) merchants. The moment you take a physical card at a point-of-sale terminal, you're out. That means e-commerce checkouts, MOTO (mail-order/telephone-order), payment links, and IVR payments are in scope; chip-and-PIN, contactless, and any face-to-face transaction isn't. If you do a mix — say, web orders plus the occasional terminal transaction at a trade show — the terminal pushes you into SAQ B or SAQ D depending on the setup.

Question 2: Has every payment-processing function been outsourced to a validated third party? "Every" is the operative word. Capture, authorisation, settlement, refund, recurring charges, tokenisation — all of it has to be run by someone who appears on the PCI Council's list of validated service providers. We see merchants who've outsourced the capture but kept the refund flow in-house, or who use a payment service provider for cards but a homegrown system for direct debits where the bank-account details are arguably still in scope. Mixed setups don't qualify for SAQ A.

Question 3: Does your website only redirect, link, or embed an iframe from the payment provider? This is where most merchants trip up. SAQ A allows three interaction models: a redirect (the customer leaves your site for the provider's hosted payment page), a payment link (the customer clicks a URL that lands on the provider's page), and an iframe (the provider's payment form is embedded in your page but served entirely from the provider's domain). What's not allowed is any payment form whose fields are rendered by your code, even if you POST the data to the provider's API. The moment your HTML draws the card-number input box, you've moved into SAQ A-EP because your page is now in scope for client-side attacks like Magecart.

Question 4: Do you have zero electronic storage, processing, or transmission of cardholder data? Nothing on your servers. Nothing in your logs. Nothing in your application database. Nothing passing through your reverse proxy or CDN. Even a transient "we hold the PAN for 200 milliseconds while we forward it" is processing. If your back-end ever sees the digits, you're SAQ A-EP at minimum.

Question 5: Do you have zero paper storage of cardholder data? Often forgotten. If your finance team prints order confirmations with full PANs, or your customer service team writes card numbers on Post-its when phone agents read them out, you have paper-based cardholder data. SAQ A says zero. Pause-and-resume call recording with a paper backup isn't SAQ A; it's not even close.

Question 6: Have you confirmed your service provider's PCI DSS compliance in writing? The PCI Council requires you to hold a current Attestation of Compliance (AoC) from every third party that handles cardholder data on your behalf. Not their marketing page that says "PCI compliant" — the actual signed AoC document, refreshed annually. If your provider can't or won't supply one, they're not actually validated and you don't qualify for SAQ A.

Question 7: Do you have written agreements covering responsibility for cardholder data? Requirement 12.8 of PCI DSS v4.0.1 requires written contracts with all service providers that handle cardholder data, explicitly stating who's responsible for what. "It's in our standard terms" doesn't count if your standard terms don't actually mention PCI DSS, the scope of services, or the division of responsibility. We've seen acquirer audits push merchants out of SAQ A purely on the contract point.

Question 8: Are you maintaining the appropriate logs and monitoring on the systems you do operate? Even with everything outsourced, you still have a website, a network, and user accounts. SAQ A v4.0.1 added a small number of operational requirements around access controls and security awareness training. They're not heavy — think "have an acceptable use policy, train your staff annually" — but they're not zero either. If you've been treating SAQ A as "sign the form and forget about it", you're behind. We cover what's actually expected in our deep dive on SAQ A controls explained.

Question 9: Are you happy to attest to all of the above annually? SAQ A isn't a one-off. You re-attest every twelve months, and the attestation is a legally binding statement to your acquirer. If your setup changes during the year — a new payment channel, a new CRM integration, a new chatbot that handles checkout — you have to reassess. Plenty of merchants drop out of SAQ A eligibility quietly when product teams ship features without telling the compliance team.

The three setups that actually qualify for SAQ A#

In practice, only a small number of architectures meet all nine criteria. Here are the three we see most often.

Setup 1: Pure redirect e-commerce. Your checkout button takes the customer to the payment provider's hosted page (a Stripe Checkout URL, a Worldpay-hosted page, a SagePay redirect). They enter their card details on the provider's domain, the provider charges the card, and the customer comes back to your thank-you page with a transaction ID. Your site never sees a PAN. This is the classic SAQ A setup and the easiest to maintain.

Setup 2: Iframe checkout. Your checkout page embeds the payment provider's iframe — think Stripe Elements (when used in iframe mode), Adyen Drop-in, or a Worldpay iframe. The visible card fields are rendered by the provider, served from the provider's domain, and your page only displays the wrapping iframe element. As long as your code doesn't intercept the field values (and you're not using a JavaScript-only integration where the fields are rendered locally), this qualifies. The PCI Council clarified in 2024 that JavaScript-rendered fields, even when posted directly to the provider, are SAQ A-EP, not SAQ A.

Setup 3: Channel-separated phone payments. For contact centres, the only practical route to SAQ A is full channel separation, where the cardholder uses their own keypad to enter card details and the digits never reach the agent or your call recording. The agent stays on the line, the customer's audio is split, and the digits are routed direct to the payment processor. We've helped merchants like Pinnacle Group achieve a 95% PCI scope reduction this way — dropping from SAQ D-Merchant to SAQ A purely by removing card data from the agent environment. Our channel separation page explains how the audio path works.

The setups that look like SAQ A but aren't#

This is the section that saves people from a forensic investigation. Here are the architectures that merchants commonly think qualify for SAQ A but actually don't.

Direct API integration. If your back end POSTs cardholder data to the payment provider's API — even if your front end collects the data and your server only holds it for a few milliseconds — you've processed cardholder data. That's SAQ D, full stop. The fact that you don't "store" anything doesn't matter; PCI DSS scope covers processing and transmission too.

JavaScript SDKs that render fields in your DOM. Many payment providers offer a "drop-in" JavaScript library that renders the card fields on your page and tokenises the data client-side before sending it. Modern Stripe Elements (when not in iframe mode), Braintree's hosted fields, Adyen's client-side encryption — these are SAQ A-EP territory. Why? Because your page is now exposed to Magecart-style client-side attacks where an injected script can steal card data before tokenisation happens. The PCI Council updated the SAQ A rules in v4.0.1 to make this explicit. If you're not sure which side of the line you sit on, our breakdown of SAQ A vs SAQ A-EP goes through the technical differences.

Pause-and-resume call recording. A surprising number of contact centres think they qualify for SAQ A because they pause recordings when card details are spoken. They don't. The agent still hears the digits, the workstation still displays the payment form (often), and the rest of the call infrastructure is still in scope. Pause-and-resume is a layer of risk reduction, not a route to SAQ A. We've written about this at length in our piece on DTMF masking vs pause-and-resume.

Stored credentials for recurring payments. If you hold any portion of a card on file — even a token issued by your provider — you need to think carefully about scope. A token issued by a PCI-validated third party that can only be used through that third party's systems is fine for SAQ A. A token that you can replay against any acquirer, or that contains the first six or last four digits of the PAN, may not be. The detail matters; talk to your provider about their token format.

Webhook payloads with card data. The provider's webhook fires after a payment and your endpoint receives the response. If that response contains the full PAN, you're back in scope. Most modern providers send tokenised references, but legacy integrations occasionally include the PAN "for convenience". Check your webhook logs.

Decision tree: which SAQ do you actually need?#

Let's run through the decision logic without the formality. Start with this question: can your own systems see, touch, or store a card number at any point? If yes, you're not SAQ A. Move on.

Next: do you accept any card-present transactions? If yes, you're in SAQ B (for standalone terminals), SAQ B-IP (for IP-connected terminals), SAQ C-VT (for virtual terminals), SAQ C (for payment application systems), or SAQ D depending on the setup. SAQ A is out.

Next: is your payment form rendered by client-side JavaScript in your DOM? If yes, you're SAQ A-EP — the "e-commerce-partial" variant that exists specifically for merchants who outsource processing but whose pages still render the card fields. SAQ A-EP requires around 80 controls compared to SAQ A's roughly 30, and it includes vulnerability scanning and stronger access controls. Significant step up in effort.

Next: is everything outsourced to a single, PCI-validated third party with a signed AoC, and do your contracts cover responsibility? If yes, you're SAQ A. If you've got multiple providers, multiple integration models, or contractual gaps, you might still be SAQ A but you need to be very careful about how you scope it. We've seen merchants attest to SAQ A while running three different payment providers across e-commerce, MOTO, and recurring — some of which were SAQ A-eligible and some of which weren't. The strict reading is that if any single payment channel pushes you out of SAQ A, you can't use it as a global attestation.

Finally: if nothing above applies, you're SAQ D. Around 300 questions, full PCI DSS, annual penetration testing, the works.

The SAQ A-EP trap — why most e-commerce merchants don't actually qualify for SAQ A#

SAQ A-EP is the questionnaire that catches almost every modern e-commerce merchant who thinks they qualify for SAQ A. The trap goes like this: you use a payment provider's JavaScript SDK to render card fields on your checkout page. The SDK tokenises the data client-side and sends the token to your back end. Your back end never sees the PAN. So you assume SAQ A applies. Wrong.

The PCI Council's reasoning is that your checkout page is now a target. An attacker who compromises your web server, your CDN, your build pipeline, or one of your third-party scripts (think analytics, chat widgets, tag managers) can inject a script that copies the card data before the provider's SDK gets to it. This is exactly how Magecart attacks against British Airways, Ticketmaster, and Newegg worked — the merchants' back ends never saw the cards, but the malicious scripts running on the checkout page did. Tens of millions of cards stolen, eight-figure fines, regulatory action.

SAQ A-EP exists specifically to mitigate that risk. It requires script integrity checks (often via the new requirement 6.4.3 introduced in v4.0.1), regular vulnerability scanning by an ASV, stronger access controls, and proper change management. It's not as heavy as SAQ D, but it's not the 22-question walk-in-the-park that SAQ A used to be in v3.

The practical implication: if you want SAQ A and you take payments online, you need to use a hosted payment page (redirect) or a true iframe served from the provider's domain. No JavaScript-rendered fields. Most providers offer both modes; you have to pick the right one.

The real-world cost of SAQ A versus the other questionnaires#

It's worth grounding the eligibility question in money, because that's what makes the difference between an academic exercise and a board-level decision. Here's roughly what each SAQ costs a mid-sized UK merchant per year, based on what we see across our client base.

SAQ A: £2,000–£6,000 a year for most UK merchants we work with. That covers internal time to renew the questionnaire, chase provider AoCs, deliver security awareness training, and maintain a small handful of policies and a network diagram. No external ASV scans, no penetration tests, no QSA fees and no dedicated tooling. For a finance team or office manager, it's typically a couple of days of work spread across the year.

SAQ A-EP: £8,000–£25,000 a year. Add quarterly ASV scans (£1,500–£4,000 per year), script-integrity tooling for requirement 6.4.3 (£3,000–£10,000), change management overhead, and a more involved annual renewal. If you're using a managed security service provider to run the scans and review the changes, the bill climbs faster.

SAQ D-Merchant: £30,000–£120,000 a year. Annual penetration testing (£8,000–£25,000), quarterly ASV scans, file integrity monitoring, log management, network segmentation testing, vulnerability management, formal change control, and incident response capabilities. Add a part-time or full-time compliance role and you're easily at six figures for an organisation handling phone payments at any reasonable volume.

The gap between SAQ A and SAQ D is genuinely huge — usually a five-to-ten-fold cost difference. That's why the eligibility checklist matters: a small architectural choice (redirect versus JavaScript SDK; channel separation versus pause-and-resume) is the difference between a few thousand pounds a year and a six-figure compliance budget. The maths usually pays for the architecture change in the first six months.

How channel separation gets contact centres to SAQ A#

For phone payments, the route to SAQ A goes through full channel separation. The buyer calls your agent in the usual way, you stay on the line through the whole call, and when it's time to take payment, the cardholder uses their own phone's keypad. The dial tones (DTMF) are intercepted before they reach your call recorder, your agent's headset, and your CRM — they go straight to the payment processor on a separate audio path. The agent hears flat tones; the recording captures flat tones; nothing in your environment ever touches a card number.

This is the only mainstream architecture that gets a contact centre to SAQ A. Pause-and-resume doesn't work (the agent still hears the digits), agent-typed payments don't work (the agent's workstation is in scope), and post-call payment links work but only for the proportion of customers willing to do them — which is rarely 100%. Channel separation is the only model that handles every call, in-band, with zero card data in your environment.

We've helped contact centres of every size make this transition. Pinnacle Group dropped from SAQ D-Merchant to SAQ A and cut their PCI scope by 95%. Mid-sized insurance and travel operators have seen their annual compliance costs fall by 70–80%. The mechanics are the same regardless of size: route the call through a PCI-compliant capture platform, separate the audio path, route the digits direct to the acquirer, validate annually. Our phone payments page walks through the architecture.

What SAQ A actually contains in v4.0.1#

People often ask, "how many questions is SAQ A?" The answer in v4.0.1 is roughly 30, depending on how you count, up from the 22 questions in v3. The additions are mostly around security awareness training, access controls for your own systems, and the new requirements 6.4.3 (script management) and 11.6.1 (page-change detection) which were aimed primarily at SAQ A-EP merchants but bled into SAQ A in slightly softer form.

The questions cover: confirming you've fully outsourced payment functions, holding written agreements with providers, maintaining a list of in-scope service providers, monitoring the PCI compliance status of those providers annually, basic information security policies, security awareness training for staff who interact with the payment flow, incident response procedures, and a small number of operational controls. If you're starting from a clean sheet, you can complete the SAQ A in a day. Maintaining it through the year is a few hours a quarter. We've covered the full list in our SAQ A documentation checklist.

For comparison, SAQ D-Merchant is around 300 questions, requires annual penetration testing, regular vulnerability scanning by an ASV, formal change control, network segmentation testing, file integrity monitoring, and a host of other technical controls. The cost difference between the two is typically £15,000–£50,000 per year for a mid-sized merchant. That's why the eligibility question matters so much.

Who validates your SAQ A and what evidence do you need?#

SAQ A is a self-assessment, so technically you fill it out and sign it yourself. But the attestation goes to your acquiring bank, and in practice the acquirer reserves the right to audit you. If a fraud event triggers a forensic investigation and the investigator finds you didn't actually qualify for SAQ A, your acquirer can impose retrospective fines, increase your processing rates, place you on a managed reserve, or terminate the merchant account. The scheme rules (Visa, Mastercard) also allow scheme-level fines that pass through the acquirer.

The evidence you should keep on file: a signed AoC from each PCI-validated provider you use, refreshed annually; a network and data-flow diagram showing how payments are handled and confirming no cardholder data touches your systems; written contracts covering Requirement 12.8; records of your annual security awareness training; an inventory of service providers; and your signed SAQ A document with the date of attestation. Most acquirers will accept a SAQ A submission through their merchant portal, but the underlying evidence needs to be retrievable on request.

One thing worth flagging: if your business processes more than six million Visa or Mastercard transactions per year, you become a Level 1 merchant and SAQ A isn't an option — you have to undergo a full Report on Compliance (RoC) audit by a Qualified Security Assessor (QSA) regardless. SAQ A is for Levels 2–4, which covers the vast majority of UK businesses.

The annual lifecycle of SAQ A compliance#

SAQ A isn't a one-and-done. Here's what a healthy annual cycle looks like.

Month 1: Renew your SAQ A. Walk through the questions, confirm nothing in your architecture has changed, confirm your provider's AoC is still current (chase them if not), refresh your written agreements if they're out of date, deliver security awareness training to anyone new in the team, and sign and submit the SAQ to your acquirer.

Months 2–9: Monitor for change. Any time your engineering team ships a checkout-related change — a new payment method, a new third-party script on the checkout page, a CRM integration that touches order data — your compliance team needs to review whether it affects SAQ A eligibility. The most common way merchants quietly drop out of SAQ A eligibility is a product team adding analytics or A/B testing scripts to the checkout page without realising the implications.

Months 10–11: Pre-renewal review. Pull your provider AoCs, confirm they're refreshed for the year, run an internal review of any architectural changes since last attestation, and update your network diagram if needed.

Month 12: Back to month 1. Renew. The cycle restarts.

This sounds heavier than it is. For most SAQ A merchants, the annual time investment is roughly a day or two, plus a few hours a quarter for change reviews. Compared to SAQ D's annual penetration tests, quarterly ASV scans, and continuous control monitoring, it's a fraction of the work.

Common eligibility myths we hear every week#

Myth 1: "We use Stripe so we're automatically SAQ A." Stripe supports both SAQ A and SAQ A-EP integrations depending on which mode you use. Stripe Checkout (the hosted redirect) and Stripe Elements in iframe mode are SAQ A. Stripe Elements with JavaScript-rendered fields, or any direct API integration, is SAQ A-EP. The provider doesn't determine your SAQ level — your integration choice does.

Myth 2: "We don't store cards so we're SAQ A." Storage is only one of the three PCI scope triggers. The others are processing and transmission. If a PAN ever passes through your systems, even for a millisecond, even encrypted, you're processing and transmitting. SAQ A requires zero of all three.

Myth 3: "Our pause-and-resume contact centre is SAQ A." No, it isn't. The agent hears the digits, which means the call infrastructure (PBX, IVR, recording platform, agent workstation, headset) is all in scope. Pause-and-resume reduces some risk but doesn't change the SAQ.

Myth 4: "Our acquirer told us SAQ A was fine." Acquirers sometimes give over-broad guidance to keep onboarding simple. The PCI Council document is the source of truth, not your acquirer's email. If your acquirer's guidance contradicts the SAQ A eligibility criteria, you're still on the hook in a forensic investigation.

Myth 5: "We're a small merchant so SAQ A is fine regardless." Merchant volume determines your level (1, 2, 3, or 4), not which SAQ applies. A Level 4 merchant who handles cards on their own server is SAQ D, the same as a Level 2 merchant doing the same thing. Volume just changes how often you have to attest and whether you need a QSA-led audit.

What happens if you don't qualify for SAQ A?#

You've got two real options: change the architecture so you qualify, or attest to the heavier SAQ that actually applies.

Changing the architecture is usually cheaper than people expect. For e-commerce, switching from a JavaScript-rendered checkout to a redirect or iframe takes a development team a couple of weeks and removes the SAQ A-EP burden permanently. For contact centres, moving from agent-typed payments to channel separation involves integrating with a PCI-compliant capture platform like ours, which is usually live within four to six weeks. We've done this for retailers, insurers, housing associations, charities, and B2B services teams — the pattern is the same regardless of vertical.

Attesting to a heavier SAQ means committing to the ongoing controls. SAQ A-EP needs quarterly ASV scans, script integrity controls, and stronger change management. SAQ D needs the full PCI DSS programme: annual penetration tests, vulnerability scans, network segmentation testing, file integrity monitoring, log management, and a dedicated security function. Mid-sized merchants typically budget £30,000–£120,000 a year for SAQ D maintenance, and that's before any tooling licences.

If you're sitting at SAQ D today and you take phone payments, the maths almost always favours adopting channel separation. Pinnacle Group dropped from SAQ D-Merchant to SAQ A and cut compliance costs by tens of thousands of pounds a year. Warby Parker reshaped their phone-payment process for similar reasons. InsureandGo's contact centre runs on our platform precisely because it puts them in SAQ A territory rather than SAQ D.

Next steps#

If you've worked through the checklist and you qualify for SAQ A, congratulations — fill in the form, get the signed AoCs from your providers, train your team, and submit. If you've spotted something that pushes you out of SAQ A, the next decision is whether to change the architecture or attest to SAQ A-EP / SAQ D. We can help with either.

For contact centres specifically, the route from SAQ D to SAQ A almost always runs through channel-separated capture. Get in touch with us if you want to walk through your current setup and what the SAQ A target architecture looks like for your team. If you'd rather see it in action first, our live demo walks through the channel separation flow from the first ring to the settled payment — you can hear what the agent hears (nothing intelligible), watch the call recording (flat tones during capture), and see the payment confirmation come back from the acquirer.