TL;DR
SAQ A vs SAQ D comes down to one question: does your environment ever touch a card number? SAQ A is 22 questions for merchants who've fully outsourced card handling. SAQ D is 360+ questions for merchants who store, process, or transmit cardholder data on their own systems. Most UK contact centres are on SAQ D when they could be on SAQ A — the gap is usually one architectural change: DTMF masking with true channel separation.
Last updated: 29 May 2026
The SAQ A vs SAQ D choice isn't really a choice — it's a consequence of how your card data flows. You don't pick the SAQ; the architecture picks it for you. If your systems touch a PAN at any point, you're SAQ D. If they don't, you're potentially SAQ A. Everything else is detail.
The reason the question gets asked so often is the gap between the two questionnaires is enormous. SAQ A asks 22 questions. SAQ D asks 360+. SAQ A skips the ASV scanning, the penetration testing, the cardholder data environment hardening, the network segmentation evidence, the staff background checks. SAQ D requires all of them. The annual compliance overhead between the two SAQs typically differs by a factor of four to six.
So most merchants want to know two things: which one do I actually need, and how do I get from SAQ D to SAQ A if I'm currently on the wrong side. This guide covers both.
What's the difference between SAQ A and SAQ D?#
The PCI SSC defines nine SAQs. SAQ A is the lightest, SAQ D is the heaviest. The two are at opposite ends of the same spectrum, and the rest of the SAQs (A-EP, B, B-IP, C, C-VT, P2PE) sit in between depending on the merchant's specific acceptance channels.
The core distinction comes down to where cardholder data exists. SAQ A is for merchants whose systems never store, process, or transmit cardholder data — everything is outsourced to a PCI-validated third party. SAQ D is for merchants whose systems do at least one of those three things.
The questionnaire structures reflect that. SAQ A's 22 controls focus on third-party management, payment page script integrity, and operational hygiene. SAQ D's 360+ controls cover the entire PCI DSS standard: build and maintain secure networks, protect cardholder data, maintain a vulnerability management programme, implement access control, regular monitoring and testing, and an information security policy. Everything PCI DSS asks for, you have to evidence.
Side-by-side comparison
| Aspect | SAQ A | SAQ D |
|---|---|---|
| Questions (v4.0.1) | 22 | 360+ |
| Card data in environment | None | Stored, processed, or transmitted |
| Acceptance channels | Card-not-present only, fully outsourced | Any channel, including card-present |
| Quarterly ASV scans | Not required on merchant systems | Required on all CDE-facing systems |
| Annual penetration testing | Not required | Required (internal and external) |
| Network segmentation | Not applicable (no CDE) | Required if used to reduce scope |
| Cardholder data environment | None | Must be defined and hardened |
| Typical annual cost (UK SME) | £8-15k | £40-90k+ |
| Audit duration | 1-2 weeks | 2-3 months |
| Suitable for contact centres | Only with true DTMF masking | Any contact centre using traditional capture |
The cost numbers are based on what we see across UK SMEs handling phone payments. Variability is high — a 100-seat contact centre with international operations and a complex acquirer relationship will pay more on SAQ D than a 20-seat UK-only operation. The ratio between the two SAQs holds reasonably steady: SAQ D is typically four to six times the SAQ A cost.
The eligibility tree#
Work through these questions in order. The first "no" tells you which SAQ you're on.
1. Do you take only card-not-present transactions? If you have any physical card-present channel (in-person terminals, mPOS, anything where the customer hands over the card), you're not eligible for SAQ A. You're looking at SAQ B, B-IP, C, P2PE, or D depending on your specific setup. SAQ A is e-commerce, MOTO, and phone payments only.
2. Have you fully outsourced card storage to a PCI-validated PSP? If your systems store the PAN — even encrypted, even tokenised by you, even in a "secure" CRM field — you're on SAQ D. Tokens issued by your PSP are fine; PANs are not. Card numbers in call recordings count as stored.
3. Have you fully outsourced card processing? "Processing" in PCI DSS terms means any action your systems take with the PAN: capturing it, formatting it, displaying it, decoding it. If your agent types the PAN into a virtual terminal on their desktop, your desktop is processing. If your IVR script reads back the digits, your IVR is processing.
4. Have you fully outsourced card transmission? Transmission means moving the PAN across your network. If the digits travel over your VoIP network as audio, your network is transmitting. If they go from the agent's desktop to your PSP, your desktop is transmitting.
5. Does your acceptance channel match one of the three SAQ A scenarios? Redirect to PSP-hosted page, embedded iframe from PSP, or phone payments with true DTMF masking (channel separation). If you've fully outsourced but you're using an SDK that runs on your origin or pause-and-resume recording, you're on SAQ A-EP or SAQ D, not SAQ A.
If you got all the way through with "yes" answers, you're an SAQ A candidate. The next step is to evidence each yes with documentation.
The most common reasons UK merchants end up on SAQ D
Of the merchants we see who are on SAQ D when they could be on SAQ A, the reasons cluster into a small number of patterns:
Phone payments with pause-and-resume recording. Agent hears the digits, agent types them into a virtual terminal. The call recording pauses, but the agent and the desktop are still in the data flow. This is the single biggest category — probably 70% of UK contact centres taking card payments are in this situation.
CRM notes fields containing PANs. Agent helpfully captures the card number into a free-text field "in case the payment fails." Suddenly the CRM, its backups, and its analytics pipeline are all in scope. We see this even at merchants whose architecture would otherwise have been clean.
Self-hosted payment forms. The merchant's website renders the card capture form themselves, then POSTs to the PSP. Even if the data is encrypted in transit, the merchant's web server is processing card data, which puts them on SAQ D (or SAQ A-EP at best).
JavaScript SDKs that run on the merchant's origin. The PSP provides a drop-in SDK that "looks like" an iframe but actually executes on the merchant's page. DOM events fire on the merchant's origin. PCI scope follows.
Call recordings retained for QA / training that captured pre-masking calls. Even after you install DTMF masking, the historical recordings still contain PANs. Those recordings are now in scope until they're retired or remediated.
Scope-reduction path: from SAQ D to SAQ A#
If you're currently on SAQ D and you'd like to be on SAQ A, here's the path that actually works.
Step 1: Map your card data flows
Walk through every acceptance channel and document where the PAN exists at each step. Web checkout, phone payments, mail order, recurring billing, refunds, dispute handling, customer service interactions. For each, note who sees the PAN, what system stores it, what backups capture it, and what staff have access.
The output is a data flow diagram. This is the artefact your QSA wants anyway — produce it now and you're already saving them time at the next assessment.
Step 2: Identify the in-scope systems
From the flow map, list every system that touches the PAN. Agent desktops, call recorders, VoIP infrastructure, IVR platform, CRM, data warehouse, backup tapes, monitoring tools, screen recordings, QA platforms. Each is currently in your cardholder data environment and contributing to your SAQ D scope.
Step 3: Replace each flow with an outsourced equivalent
For web checkout, switch to a redirect or true PSP-hosted iframe. For phone payments, install DTMF masking with channel separation. For recurring billing, move to a tokenised vault at the PSP. For mail order, switch to a PSP-hosted virtual terminal that the operator keys into directly (so the form is the PSP's, not yours).
The principle is consistent: the PAN goes direct from the cardholder to the PSP. Your systems get a token in return. The token is useless to an attacker because it only works inside the PSP's environment with the right credentials.
Step 4: Remediate legacy stored data
This is the painful step. Search every system you've identified for stored card numbers. CRMs, data warehouses, call recordings, backup tapes, log files, ticket systems, support transcripts, anywhere a PAN might have leaked in over the years.
Tokenise what's still needed. Securely delete the rest. Document the destruction. The Information Commissioner's Office expects evidence of secure deletion under UK GDPR; the PCI SSC expects evidence under PCI DSS Requirement 9.4. Same artefact serves both.
Plan for this step taking longer than you think. Most merchants underestimate by a factor of two. Old SQL databases, departed-employee laptops, forgotten staging environments — card data hides in places nobody remembers.
Step 5: Update policies and segmentation
Update your information security policy to reflect the new architecture. Update your incident response plan. Update your network diagram. Remove segmentation evidence you no longer need (no CDE means no segmentation requirement under SAQ A). Update your staff training to reflect that they no longer have direct access to PANs.
Step 6: Get PSP AOCs and re-sign
Get a current Attestation of Compliance from each PSP whose services you're now relying on. Keep them in a folder dated for the last 12 months. Complete the SAQ A questionnaire. Have it reviewed by your QSA (most are happy to do a desk review of the new architecture for a fraction of the SAQ D fee). Submit to your acquirer.
Step 7: Operational discipline
Staying on SAQ A is harder than getting to SAQ A. Train agents that PANs never go into notes fields. Run regular DLP scans for PANs across your environment. Maintain your payment page script inventory. Review your PSP's AOC annually. Audit your call recordings periodically (DTMF masking implementations can drift — verify the masking is still working).
The discipline matters because SAQ A drift is silent. You can be on SAQ A on paper while a quarter of your transactions are leaking card data into your CRM. The next breach reveals it.
The operational discipline that keeps you on SAQ A#
Getting to SAQ A is one project. Staying on SAQ A is an ongoing discipline. The drift back toward SAQ D is silent — it accumulates one small operational decision at a time, and you don't notice until the next incident exposes it.
The drift patterns we see most often:
Agent helpfulness. An agent gets a customer whose payment is failing. The customer reads the card number aloud. The agent helpfully types it into the CRM notes field "so we can try again later." That CRM record now contains a PAN. The CRM is now in scope. You're off SAQ A.
The fix is training plus a technical control. Train agents that PANs never enter free-text fields, full stop. Run a regular Data Loss Prevention scan that grep's CRM records for credit-card-number patterns and alerts when one is found. Most DLP tools have a PCI-specific module that catches Visa/Mastercard/Amex/Discover patterns out of the box. The alert is the safety net for when training fails.
The same pattern applies to support tickets, email threads, chat transcripts, and internal Slack channels. Anywhere a human can type free text that ends up in a system you control, a PAN can land there.
Process workarounds. A vulnerable customer can't enter their card via the keypad — accessibility issue, broken phone, language barrier. Your agent works around it by capturing the card on a paper form, walks it to a manager, the manager keys it into the virtual terminal. Now you've reintroduced a card data flow that bypasses your architecture.
The fix is a documented escalation path that doesn't break the architecture. Most PSPs offer agent-keyed entry via a PCI-validated virtual terminal that runs in the PSP's environment, not on the agent's desktop. Train your supervisors to use that path for vulnerable customers rather than capturing on paper.
Vendor drift. Your PSP changes their integration mode in a software update, your script inventory falls out of date, your tamper detection alerting goes silent because a refactor changed the page structure. None of these are dramatic individually; collectively they erode the evidence base your SAQ A self-certification rests on.
The fix is a quarterly compliance review. Re-check your PSP's AOC is current. Re-check your script inventory matches what actually loads on the page (use the browser's Network tab). Re-check your tamper detection has fired at least once during the quarter on a deliberate test change. Re-check your DLP hasn't found any PANs in CRM records. The review takes a couple of hours and catches the drift before it becomes a problem.
SAQ A is a sustainable compliance position when the operational discipline matches the architecture. When the discipline lapses, you're paper-compliant and architecturally exposed — which is the worst state to be in.
When SAQ D is actually the right answer#
SAQ A isn't right for everyone. Some businesses legitimately need to be on SAQ D:
You run your own payment gateway. If you've built your own integration with the card networks (Visa, Mastercard direct) rather than going through a PSP, you're processing card data in the most fundamental sense. SAQ D applies.
You're a payment service provider yourself. If your customers are merchants using your platform to take payments, you're operating as a PSP. SAQ D plus PCI DSS validation as a service provider.
You need full card data for fraud analysis. Some high-risk industries (gambling, certain travel sectors) need access to the full PAN for fraud scoring across multiple transactions. Tokenisation helps but doesn't fully replace this for some use cases.
Your contractual relationships require it. Some B2B card relationships, particularly with large corporate cards, contractually require the merchant to hold the PAN. SAQ D is unavoidable in those cases.
For the majority of merchants — retail e-commerce, B2C contact centres, SaaS billing, professional services — SAQ A is achievable with an architecture change, and worth pursuing.
Worked example: SAQ D to SAQ A in 12 weeks#
A UK insurance broker takes around 6,000 phone payments a month across a 35-seat contact centre, plus another 2,000 monthly card-on-file charges for renewals. Before the project: SAQ D-Merchant, annual compliance overhead approximately £68k. Card numbers were captured by agents into a virtual terminal, call recordings used pause-and-resume, and renewals were charged from a "card on file" field in their CRM.
Project timeline:
Weeks 1-3: Flow mapping and architecture design. Identified that the renewals CRM field was holding PANs (not tokens), agent desktops were the primary processing surface, and call recordings before 2024 still contained card data that hadn't been remediated. Designed the target state: channel-separated DTMF masking for inbound payments, PSP-hosted virtual terminal for outbound MOTO, tokenised vault for the renewals.
Weeks 4-7: Implementation. Channel separation deployed at the SBC layer with Paytia as the PCI-validated endpoint. CRM renewal field migrated to token-only — required custom development to integrate with the broker's policy system. Agent training rolled out to the contact centre.
Weeks 8-10: Legacy remediation. Scanned all CRM records for stored PANs (found 2,400 records with full card numbers, tokenised the active ones and securely deleted the inactive). Scanned call recordings from the previous five years (found 18 months of unmasked recordings, retained the metadata and securely deleted the audio). Updated information security policy and incident response plan.
Weeks 11-12: SAQ A evidence collection and submission. QSA desk review of the new architecture, AOC from Paytia and the renewals PSP, completed SAQ A questionnaire, submitted to acquirer.
Post-project annual compliance overhead: approximately £14k. Saving: £54k/year, against a one-off project cost of around £35k. Payback in under nine months. Beyond the cost, the architecture is now genuinely more secure — there's no historical data that could leak, no agent desktop that could be compromised, no CRM field that could be exfiltrated.
SAQ A-EP and the middle ground#
SAQ A-EP (Eligible Merchants Using a Partially Outsourced E-commerce Implementation) is the middle option that comes up for merchants who can't quite get to SAQ A but don't want to be on SAQ D. It applies when the merchant's website is in the payment data flow but doesn't store or process cardholder data — typically the SDK / drop-in JavaScript scenario.
SAQ A-EP runs to about 191 controls. Includes ASV scanning of merchant web infrastructure, penetration testing, and full vulnerability management. Closer to SAQ D than to SAQ A in workload terms.
The honest answer is that SAQ A-EP is usually a stepping stone, not a destination. If you're stuck on it, the architectural change that gets you to SAQ A is usually small (switch from SDK to true iframe or redirect). Worth doing.
The cost components nobody talks about upfront#
When merchants weigh SAQ A vs SAQ D, the headline numbers (£8-15k versus £40-90k) are useful but they hide a lot of variation. Worth unpacking what's actually in each side of the comparison so you can pressure-test your own situation.
What goes into the SAQ A annual cost
The bulk of SAQ A spend is internal staff time, not external vendor fees. Typically:
Internal compliance lead time, roughly 3-5 days per year to maintain the script inventory, refresh the PSP AOC, run the staff training, and complete the questionnaire. At a fully-loaded UK rate of £400/day, that's £1.5-2k of staff time.
QSA desk review fee, optional but recommended, £2-5k. Some merchants self-certify without a QSA at all if the architecture is unambiguous; others use one annually for peace of mind.
Tamper-detection tooling, £3-12k per year. SaaS options like Source Defense or Akamai are at the higher end; DIY options using SRI hashes and CSP reporting are functionally free if you've already got an engineering team that can build and maintain them.
Annual security awareness training, £500-2k depending on whether you use a SaaS platform (Knowbe4, Curricula) or run it internally. Required even on SAQ A.
Total: £8-15k for a typical UK SME. Higher if you outsource everything; lower if you do the work in-house.
What goes into the SAQ D annual cost
SAQ D includes everything above plus a much larger pile of recurring spend.
QSA-led assessment, £15-50k per year. This is the big one. The QSA spends several weeks reviewing your environment, sampling evidence, observing controls, and producing a Report on Compliance or a signed-off SAQ D. Cost scales with the size of your CDE.
Quarterly external ASV scans, £2-5k per year. Required by Requirement 11.3.2 — an Approved Scanning Vendor runs an external vulnerability scan against your internet-facing infrastructure four times a year. You receive a report. Any findings need to be remediated and re-scanned to "pass."
Annual internal and external penetration testing, £15-30k. Required by Requirement 11.4 — a qualified tester (internal or external) attempts to compromise your CDE. The report identifies findings, and you need to remediate or risk-accept each one.
Segmentation testing (if you use network segmentation to reduce scope), £5-15k per year. Required by Requirement 11.4.5 — periodic testing that your segmentation actually works. Skipping this is a common audit failure.
Vulnerability management programme, £5-20k per year — patching, scanning, change management. Required by Requirement 6 across the standard.
Internal compliance staff time, 20-60 days per year depending on the size of your CDE and the maturity of your programme. At £400/day, that's £8-24k.
Total: £40-90k for a typical UK SME, often higher for larger contact centres or complex environments.
The arithmetic is straightforward. Every requirement on the SAQ D list that doesn't apply to SAQ A disappears from the budget. Most of what's left on SAQ A is the internal staff time, which doesn't scale much with transaction volume — so larger merchants see proportionally bigger savings when they migrate.
Other SAQs you might encounter#
Briefly, the other SAQs and when they apply:
SAQ B: merchants using only imprint machines or standalone dial-out terminals. No e-commerce, no integration with merchant systems. Niche category.
SAQ B-IP: merchants using standalone IP-connected payment terminals. The terminal does everything, the merchant's systems aren't involved. Lighter than SAQ C.
SAQ C: merchants with payment application systems connected to the internet, but no cardholder data storage. Heavier than B-IP.
SAQ C-VT: merchants with virtual terminals on a dedicated, isolated computer. The computer is the only thing in the CDE. Limited use case.
SAQ P2PE: merchants using validated point-to-point encryption solutions. Lighter than B-IP and C because the P2PE solution takes most of the controls off the merchant's plate.
For most merchants reading this, the realistic comparison is between SAQ A, SAQ A-EP, and SAQ D. The other SAQs apply to specific niche acceptance channels.
What changes between v3.2.1 and v4.0.1 for the SAQ A vs SAQ D decision#
The v3.2.1 to v4.0.1 transition completed on 31 March 2025, when the previously future-dated requirements went mandatory. If you're still self-assessing under v3.2.1 templates, your acquirer will catch it at your next renewal — fix that first before worrying about SAQ choice.
The relevant v4.0.1 changes for the SAQ A vs SAQ D decision:
The SAQ A control count grew from 14 to 22. The increase is concentrated in payment page script management and tamper detection (Requirements 6.4.3 and 11.6.1). If you were already on SAQ A under v3.2.1 and you haven't updated your evidence collection, your next acquirer audit will flag the missing controls.
SAQ D added the same script and tamper detection controls. Those apply across the standard, so SAQ D merchants pick up the same requirements. The relative gap between SAQ A and SAQ D didn't shrink.
The customised approach is available on both. You can propose your own controls to meet the objectives rather than ticking the prescriptive sub-requirements. More relevant for SAQ D (where there are more requirements that might not map cleanly) than for SAQ A.
Targeted risk analyses (TRAs) became more central. Several v4.0.1 requirements give the merchant a choice — apply the defined frequency (annual review, quarterly scan, etc.) or perform a targeted risk analysis to justify a different frequency. The TRA documents your reasoning and is reviewable by your assessor. Useful for merchants with mature security programmes; potentially risky if you misjudge the threat model.
If you're planning a project to migrate from SAQ D to SAQ A, do the v4.0.1 update at the same time. Don't migrate first and then update — the v4.0.1 changes affect what evidence you're collecting at the SAQ A target state, so design for them from the start.
The architectural patterns merchants confuse#
The biggest source of confusion in the SAQ A vs SAQ D decision is whether a particular architectural pattern actually qualifies. Three patterns get described as "PCI compliant" or "outsourced" when they don't actually clear the SAQ A bar.
Pattern 1: PSP-provided JavaScript SDK
The PSP gives you a JavaScript library to drop into your checkout page. The library renders a form that looks like an iframe, the customer types their card number, and the SDK handles the POST to the PSP's API. Looks clean, feels modern.
The problem: the SDK runs on your origin. The DOM events fire on your domain. The keystrokes are momentarily processed by JavaScript running in your page's context before being sent to the PSP. Under PCI DSS, your origin is processing card data.
That puts you on SAQ A-EP at best, often SAQ D depending on how the SDK handles errors and retries. Stripe Elements is the canonical example of this pattern — Stripe explicitly tells merchants it's SAQ A-EP. Some merchants don't realise that the modal-style "checkout" they've installed is actually an SDK with the same property.
Pattern 2: Server-side proxy to the PSP
The merchant's server captures the form data and POSTs it to the PSP's API. The form is on the merchant's domain; the server-side code briefly holds the card number before forwarding. Some merchants assume "we don't store it, so we're SAQ A" — wrong. They're processing and transmitting it, both of which are independently disqualifying.
SAQ D applies. The server-side code is in your CDE. Logs need to be sanitised, error handling needs to be careful, memory needs to be cleared. The whole web tier is in scope.
Pattern 3: Pause-and-resume "PCI compliant" phone payments
This is the contact-centre version of the JavaScript-SDK trap. The vendor sells "PCI compliant phone payments" — and they're not lying, the product does help — but the architecture is pause-and-resume recording. The agent still hears the card digits, types them into a virtual terminal, and the call recorder pauses during entry.
You're still on SAQ D. The agent and the desktop and the contact centre infrastructure are all in scope. The improvement over the baseline (raw call recordings with PANs in them) is real but it doesn't get you to SAQ A.
The architecture that does get you to SAQ A is genuine channel separation — the customer's keypad audio is split off at the SBC or carrier and travels down a separate path to the PCI-validated PSP. The agent hears flat tones. The call recorder hears flat tones. The contact centre never touches the PAN. That's the standard DTMF masking with channel separation delivers.
When evaluating vendors, the test question is: "Where does the customer's keypad audio physically travel during card entry?" If the answer involves your contact centre infrastructure, your virtual terminal, or your agent's desktop in any way, it's pause-and-resume. If the answer is "direct from the carrier to the PSP via a separate signalling channel," it's true channel separation and qualifies for SAQ A.
Common questions about SAQ A vs SAQ D#
A few questions that come up repeatedly when merchants are working through this.
"Can I be on different SAQs for different channels?" Yes. PCI DSS allows merchants to evaluate each acceptance channel independently. You might be on SAQ A for e-commerce and SAQ B-IP for in-store. The aggregate compliance status reflects the most restrictive of all the SAQs in use.
"What if my PSP says I'm on SAQ A but my acquirer says SAQ D?" Your acquirer makes the final call. The PSP can guide you, but your acquirer is the one bearing the residual risk and has the final say on what SAQ they'll accept. If there's a disagreement, the acquirer wins.
"Do I need a QSA for SAQ A?" Not formally — SAQ A is a self-assessment by definition. Many merchants engage a QSA for a desk review anyway, especially during the transition from SAQ D to SAQ A. Costs are typically £2-5k versus £40k+ for a full QSA-led SAQ D assessment.
"How long does SAQ A take to complete?" The questionnaire itself takes a couple of days for someone who knows the environment. The evidence gathering — payment page script inventory, PSP AOC collection, third-party management documentation — typically adds another week or two. Once it's set up, the annual refresh is a few days.
Next steps#
If you're trying to work out whether you should be on SAQ A vs SAQ D, the practical step is to map your current card data flows and walk them through the eligibility tree above. The most common answer for UK contact centres is "we could be on SAQ A if we changed how we capture cards over the phone" — which is the architecture DTMF masking with channel separation directly enables.
For a working demo of how that architecture works under the hood, book a 15-minute call and we'll wire it up against your actual phone system. For more background on the standard itself, see our what is PCI DSS guide and the deeper-dive what is SAQ A explainer. For a worked example of a UK merchant making this transition, the Pinnacle Group case study documents the cost saving in concrete numbers. If you'd rather talk through your situation first, the contact form reaches our UK team.
The structural point is that SAQ D isn't a permanent fate — it's a snapshot of how your environment currently handles card data. Change the architecture and the SAQ changes with it. Most of the cost saving sits on the other side of one well-executed migration project.
Drop from SAQ D to SAQ A
Paytia takes contact centres from SAQ D to SAQ A by splitting the audio channel so card data never enters your environment. Typical saving: 60-80% of annual PCI compliance overhead.
