TL;DR
SAQ A is the lightest PCI DSS self-assessment questionnaire — only 22 questions in v4.0.1, intended for merchants who've fully outsourced card handling to a PCI-validated third party and never touch cardholder data themselves. If your website redirects to a payment provider, your phone calls go through DTMF masking, or your back office never sees a PAN, you're probably an SAQ A candidate. Get it wrong and you'll get hit by a forensic investigation the first time a card is breached on your watch.
Last updated: 29 May 2026
If you take card payments and your bank's just told you to fill in an SAQ, you're trying to work out which one. SAQ A is the one every merchant wants — it's the shortest, the cheapest, and it carries the lightest evidence burden. Twenty-two questions in v4.0.1, no quarterly ASV scans on your own infrastructure, no penetration test of your cardholder data environment. The catch: you only qualify if you've genuinely pushed every piece of card handling out to someone else.
We've written this guide because we see merchants get it wrong constantly. They self-certify on SAQ A while their contact centre is still hearing PANs read out loud. They use a hosted iframe but their analytics tags load on the same page. They tick "no electronic storage" while their CRM helpfully captures the full card number into a notes field. Every one of those gets you forensically scoped to SAQ D when the breach happens, with a Qualified Security Assessor billing £1,500 a day to work out how badly you've misrepresented your situation.
So here's what SAQ A actually is, who really qualifies, and the three eligibility traps that catch most UK merchants.
Quick context: the SAQ system in plain English#
Before we get into SAQ A specifically, a quick orientation. The PCI Security Standards Council publishes the PCI Data Security Standard (PCI DSS), currently at version 4.0.1. Every merchant that takes card payments has to demonstrate compliance with it. For the largest merchants (Level 1, more than six million transactions a year per card brand), that means a full audit by a Qualified Security Assessor producing a Report on Compliance. For everyone else, it means completing a Self-Assessment Questionnaire that matches their acceptance channels.
The SSC publishes nine SAQs because not every merchant has the same risk profile. A coffee shop with a Square reader doesn't have the same scope as a 500-seat contact centre running a custom integration with their acquirer. The SAQs are calibrated to fit. SAQ A is the lightest because it covers the merchants who've made themselves least relevant to the security model — they've outsourced the card handling, so the questionnaire mostly asks them to prove the outsourcing is real and uncompromised.
Your acquiring bank decides which SAQ you complete. If you self-certify on the wrong one and an incident happens, the acquirer will pull in a PCI Forensic Investigator (PFI) to determine the actual scope. That investigation typically costs £20k-£80k and the merchant pays. If the PFI finds you should have been on SAQ D, you face card scheme fines on top, plus the operational fallout of dealing with whatever they uncovered.
What is SAQ A?#
SAQ A is one of nine PCI DSS Self-Assessment Questionnaires that the PCI Security Standards Council publishes. It's the shortest of them all. It's the one your acquiring bank wants you on if at all possible, because it cuts the compliance evidence collection to a fraction of what SAQ D requires.
The official SAQ A description in PCI DSS v4.0.1 reads: "Card-not-present merchants that have fully outsourced all cardholder data functions to PCI DSS validated third-party service providers, with no electronic storage, processing, or transmission of any cardholder data on the merchant's systems or premises." Read that twice. Every word matters. "Fully outsourced." "No electronic storage." "No processing." "No transmission." Any one of those failing kicks you out.
The questionnaire itself runs to 22 controls in v4.0.1, up from 14 in v3.2.1. The increase came from the new requirements around payment-page scripts (Requirement 6.4.3) and tamper detection (Requirement 11.6.1) — controls that PCI SSC added to address Magecart-style attacks where attackers compromise third-party JavaScript on the payment page to skim card data. If you'd been told "SAQ A is 14 questions," that was the v3.2.1 number. Update your mental model.
Compare that to SAQ D, which runs to 360+ questions and pulls in the full PCI DSS control set. Or SAQ B (40-ish), SAQ C (160-ish). SAQ A is the merchant's prize for keeping card data out of their environment. The whole compliance industry is structured to reward you for not handling cards.
Who qualifies for SAQ A?#
The PCI SSC lists three eligibility scenarios for SAQ A. You need to fit all five baseline conditions, and your acceptance channel needs to match one of the three scenarios.
The five baseline conditions
To self-certify on SAQ A at all, your business must:
- Accept only card-not-present transactions (e-commerce or mail order / telephone order).
- Have fully outsourced all cardholder data functions to PCI DSS validated third-party service providers.
- Have no electronic storage, processing, or transmission of cardholder data on your systems or premises.
- Confirm that the PCI DSS validated third-party service providers handling storage, processing, or transmission are responsible for their PCI DSS compliance (and you've got the documentation to prove it).
- Retain only paper reports or receipts with cardholder data, and those reports aren't received electronically.
Card-present merchants — anyone with a physical terminal — are out. SAQ A is a card-not-present-only document.
The three eligible acceptance channels
Within those baseline conditions, you also need to match one of three acceptance channel scenarios. These are the three SAQ A eligibility routes:
Scenario 1: Redirect to a third party. Your website doesn't display a payment form at all. When the customer clicks "pay," they're redirected to the payment service provider's own URL. The PSP's domain handles the card capture, the card data flows directly to them, and the customer comes back to your site only after the transaction is authorised. This is the cleanest route to SAQ A — the PSP's payment page never shares an origin with your site.
Scenario 2: Embedded iframe from a PCI-validated provider. Your checkout page includes an iframe whose contents are served from the PSP's domain. The customer types their card number, but the form they're typing into is rendered by the PSP, not by you. You don't see, touch, or transmit the PAN. As long as the iframe genuinely comes from the PSP and your page isn't capturing the data via JavaScript, this qualifies for SAQ A.
Scenario 3: Phone payments through a PCI-validated provider with DTMF masking. Customers call your contact centre, but during the moment the card number is entered, the audio path is split. The customer presses the digits on their phone keypad and the tones travel down a separate channel direct to the PSP. Your agent hears flat, neutral tones. Your call recorder hears flat, neutral tones. Your CRM never sees a PAN. This is what DTMF masking done properly enables, and it's how phone-payment merchants legitimately stay on SAQ A.
That third scenario is where most merchants come unstuck. Pause-and-resume recording — where the call recorder stops while the customer reads the digits aloud — doesn't qualify. The agent still heard the card. You're not on SAQ A; you're on SAQ D with extra steps.
What does SAQ A actually cover?#
The 22 controls in SAQ A v4.0.1 cluster around a small number of practical concerns. You're not being asked to harden a cardholder data environment, because you don't have one. You're being asked to prove that the outsourcing arrangement is real, the payment page is uncompromised, and your operational practices don't accidentally drag card data back in.
Third-party service provider management
The first group of controls (Requirement 12.8) asks you to maintain a list of all your service providers that handle cardholder data on your behalf, confirm each one is PCI DSS compliant, and review their AOCs annually. Practically: keep a folder with your PSP's Attestation of Compliance, dated within the last 12 months. When your acquirer asks, you produce it. If you can't, you're already not compliant.
You're also expected to have a written agreement that acknowledges your service provider's PCI DSS responsibilities. Most PSP contracts include this language; if yours doesn't, ask for an addendum. We've seen acquirer audits hinge on whether the PSP's contract mentions PCI DSS by name.
Payment page script management
The newer requirements that arrived with v4.0.1 — 6.4.3 and 11.6.1 — are where SAQ A merchants now spend most of their evidence-gathering time. Requirement 6.4.3 wants you to inventory every script that runs on your payment page (or the page that loads the PSP's iframe). For each script, you need a written justification of why it's there, integrity verification, and authorisation.
That includes your analytics tags, A/B testing tools, chat widgets, marketing pixels — anything that loads JavaScript on the page. The threat model is Magecart: an attacker compromises one of those third-party scripts and uses it to read card data out of the iframe or capture it via DOM events.
Requirement 11.6.1 wants tamper-detection on the payment page. You need a mechanism that alerts you within seven days if the HTTP headers or HTML content of your payment page change unexpectedly. There are SaaS tools for this (Source Defense, Akamai Page Integrity Manager); there are also DIY options using subresource integrity hashes and a CSP report endpoint. Pick one and document it.
Operational controls that still apply
Even with everything outsourced, you keep a small set of operational controls. Annual security awareness training for staff who handle card payments (even if they're just handing customers off to the PSP). A documented incident response plan. A written information security policy. These are the carry-over from broader PCI DSS that every merchant needs regardless of SAQ level.
The three eligibility traps that catch most merchants#
This is where we lose people. The SAQ A description sounds straightforward, but the audit reality has nuances. Three specific traps account for most of the wrongly-self-certified merchants we encounter.
Trap 1: The iframe that isn't really an iframe
You've installed your PSP's drop-in JavaScript SDK. It renders what looks like an iframe. But under the hood, the SDK uses JavaScript on your page to capture the keystrokes and POST them to the PSP. The DOM events fire on your origin, which means your origin is processing card data, which means you're not on SAQ A — you're on SAQ A-EP (Eligible Merchants Using a Partially Outsourced E-commerce Implementation), which adds another 80+ controls including ASV scanning of your web infrastructure.
The test: open your payment page's DevTools, go to the Network tab, and watch what happens when the customer types a card number. If the keystroke events fire on your domain and the eventual POST to the PSP comes from your origin, you're SAQ A-EP. If the iframe is genuinely served from the PSP's domain and the data never crosses your origin, you're SAQ A.
Most PSPs publish guidance on which integration mode puts you on which SAQ. If yours doesn't, ask before you self-certify.
Trap 2: The CRM notes field
An agent helpfully types the customer's card number into a CRM notes field while waiting for the payment screen to load. Or your post-payment workflow includes "save card number to customer record" as a convenience. The moment a PAN lands in your CRM, your CRM becomes part of your cardholder data environment, and you're off SAQ A.
This catches people because the CRM was never sold as a "payment system." But PCI DSS doesn't care what you call the system; it cares what data the system holds. Your CRM is now in scope, every backup of it is in scope, every analytics warehouse that ingests CRM data is in scope, every staff member with read access is in scope. You're firmly in SAQ D territory.
The fix is to never let a PAN reach the CRM. Tokenise at the PSP, store only the token in your CRM, and treat the CRM as token-only. Train your agents that "the card number goes in the payment system, not the notes field." Run regular data scans (DLP tools, scripts, even a quarterly grep on a backup) to confirm no PANs are leaking in.
Trap 3: Phone payments without true channel separation
This is the one that catches contact centres. You bought a "PCI compliant phone payment" product. You assumed it put you on SAQ A. But the product is actually pause-and-resume recording — the agent still hears the card digits, your call recorder pauses during entry, and the digits are typed into a virtual terminal that runs on the agent's desktop.
Under PCI DSS, that means your agent is processing cardholder data (they're the channel), your agent desktop is in scope (they typed the digits), and your network is in scope (the digits travelled across it to the virtual terminal). You're not on SAQ A. You're on SAQ D with a smaller scope than nothing, but SAQ D nonetheless.
True DTMF masking with channel separation works differently. The audio path is split at the carrier or the SBC. The customer's keypad tones travel down a separate channel that's terminated at the PSP, not at your contact centre. Your agent hears flat tones. Your call recorder hears flat tones. The PSP processes the digits and returns an authorisation result. Your contact centre never touches the PAN, and that's the architecture that legitimately keeps you on SAQ A.
If you're not sure which architecture your vendor is selling, ask them this question: "When the customer types the card number, where does that audio physically travel?" If the answer involves your contact centre infrastructure, your call recorder, or your agent's desktop, it's pause-and-resume. If the answer is "direct from the carrier to the PSP via a separate signalling path," it's true channel separation.
SAQ A vs SAQ A-EP — the partial-outsourcing variant#
SAQ A-EP is the questionnaire for merchants who've done most of the outsourcing but their website is technically involved in the data flow. Most often this is the SDK / drop-in JavaScript scenario above, or the merchant uses a transparent redirect that's served from the merchant's own subdomain.
SAQ A-EP carries about 191 controls in v4.0.1, including quarterly ASV scans of the merchant's web infrastructure and an annual penetration test. It's much closer to SAQ D than to SAQ A in workload terms. If you've inherited SAQ A-EP because your integration mode requires it, the obvious cost-saving move is to switch to a redirect or true iframe integration and drop to SAQ A.
Plenty of merchants run SAQ A-EP for years without realising they could be on SAQ A with a half-day integration change. Worth checking with your PSP.
What SAQ A doesn't get you out of#
Self-certifying on SAQ A doesn't make you immune to liability. Three things stay on your plate regardless of which SAQ you're on:
Breach liability. If a breach happens — whether through your PSP, your payment page, or operational drift — the cardholders affected are your customers. You're the one taking the reputational hit, processing the chargebacks, and dealing with the ICO if personal data is involved. SAQ A reduces the surface area; it doesn't eliminate it.
Acquirer monitoring programmes. If your chargeback ratio creeps above 1%, Visa's VDMP and Mastercard's ECM monitoring programmes pull you in regardless of which SAQ you're on. Fines, increased fees, eventual merchant account termination. SAQ A doesn't shield you.
Customer trust. Customers don't know what SAQ A is. They know that their card got skimmed on your site, and now they're getting fraud alerts. The reputational cost of a payment-page compromise is the same whether you were SAQ A or SAQ D.
The point of SAQ A isn't to dodge security responsibility. It's to recognise that you've genuinely outsourced the highest-risk piece — the card data handling — and therefore your compliance evidence collection should reflect that. The security controls live with the PSP. Your job is to keep things that way.
How to get to SAQ A from SAQ D#
If you're currently on SAQ D and you want to drop to SAQ A, there's a clear path. It's the same path that produces real security improvements as a side-effect.
First, audit where card data currently lives in your environment. Walk through every channel: web checkout, phone, mail order, recurring billing, refunds, dispute handling. For each, work out who sees the PAN, what system stores it, and what backups or logs capture it. The output is a heat map of card data flows that's worth keeping anyway.
Second, replace each flow with an outsourced equivalent. Web checkout → redirect or true iframe. Phone → DTMF masking with channel separation. Recurring → tokenised vault. Mail order → operator-keyed entry on a PSP-hosted virtual terminal. The principle is the same in each case: the PAN goes directly to the PSP, your systems get a token back.
Third, remediate the legacy. Search your CRM, your data warehouse, your call recordings, your backups for stored PANs. Tokenise what's still needed, securely delete the rest. This is the painful step — there's usually card data hiding in places nobody remembers — and it's where most projects stall.
Fourth, document the new architecture. Update your data flow diagrams, your information security policy, your incident response plan. When your acquirer asks why you're now self-certifying on SAQ A, you produce the architecture document and the PSP's AOCs.
Fifth, re-sign your AOC. Submit the new SAQ A. Notify your acquirer. The expected reduction in compliance overhead is typically 60-80% versus the SAQ D baseline. We've seen UK contact centres go from £90k/year in compliance overhead to £15k — most of the saving is staff time on evidence collection rather than direct vendor costs.
The v4.0.1 changes that affect SAQ A specifically#
PCI DSS 4.0.1 replaced the previous v3.2.1 in March 2024, and the optional future-dated requirements went mandatory on 31 March 2025. As of 2026, every UK merchant should be assessing under v4.0.1. The changes that bite hardest for SAQ A merchants are concentrated in three areas.
Payment page script management (Requirement 6.4.3). Magecart attacks — where attackers compromise a third-party JavaScript library to skim card data from payment pages — have been the dominant card-data breach vector for the last five years. British Airways, Ticketmaster, Newegg. PCI SSC's response in v4.0.1 was to require every merchant operating a payment page to maintain an inventory of every script that runs on the page, authorise each one in writing, and verify the integrity of each script. The control applies to SAQ A merchants because even though the payment form is iframed from the PSP, the parent page (your page) is still where attackers compromise scripts to skim data via the DOM.
Practically: list every script that runs on your /checkout or /payment page. Include analytics tags (GA4, GTM, Adobe Analytics), session recording tools (Hotjar, Clarity, FullStory), A/B testing platforms (Optimizely, VWO), chat widgets (Intercom, Drift), marketing pixels (Meta, LinkedIn, TikTok), and any custom JavaScript. For each, write a one-sentence business justification ("required for conversion tracking" / "required for customer support"), record the script's source URL and integrity hash, and authorise it through whatever change-control process you use. Review the list quarterly.
Payment page tamper detection (Requirement 11.6.1). Complementing 6.4.3, the merchant needs a mechanism that alerts them within seven days of unexpected changes to the HTTP headers or content of the payment page. The threat model is the same — attacker injects malicious script, alters the page, exfiltrates data. The control is the detection layer that catches it.
SaaS options exist (Source Defense, Akamai Page Integrity Manager, Human's PerimeterX, Jscrambler). DIY options exist too — subresource integrity (SRI) hashes on every script tag, plus a Content Security Policy with a report-uri that emails when violations occur, plus an external monitoring tool that diffs the page HTML weekly. Pick one and document it. The audit doesn't care which tool you use; it cares that you can show the alerting works.
Customised approach. v4.x introduced the "customised approach" — the merchant can propose their own controls to meet a stated objective rather than ticking the prescriptive sub-requirements. Useful for mature security programmes; risky if you don't have the documentation to defend it. Most SAQ A merchants stick with the defined approach because the prescriptive controls are reasonable and well-understood. Worth knowing the customised approach exists in case a specific requirement doesn't map cleanly to your architecture.
What an actual SAQ A submission looks like#
Concrete example of what your finished SAQ A package contains. This is what you'd send to your acquirer or hand to your QSA for a desk review.
First, the SAQ A document itself — the 22-control questionnaire with your responses, signed by an officer of the company. Most acquirers accept the PCI SSC's standard template.
Second, an Attestation of Compliance (AOC) document for your business. This is the cover page that says "we self-certify on SAQ A, here are our acceptance channels, here are our service providers." It's a few pages, signed and dated.
Third, supporting evidence. Your PSP's current AOC (one per PSP if you use multiple). Your payment page script inventory. Your tamper-detection alerting evidence (a sample alert that was generated and triaged). Your third-party service provider management policy. Your information security policy. Your incident response plan. Your annual security awareness training records.
Fourth, your data flow diagram. PCI SSC doesn't require one for SAQ A, but most QSAs and acquirers want to see one. It's the artefact that proves you've thought about where card data goes and validates that it doesn't touch your environment.
That's it. No quarterly ASV scan reports of your own infrastructure (those go to your PSP). No penetration test reports of your CDE (you don't have a CDE). No FIM logs, no SIEM evidence, no segmentation testing. The SAQ A package is one folder that fits on a single screen.
Common SAQ A misconceptions#
A few things people get wrong about SAQ A that are worth correcting briefly.
"SAQ A means I don't need PCI DSS compliance." Wrong. SAQ A is PCI DSS compliance — it's the questionnaire you complete to attest to your compliance. You're still bound by every PCI DSS requirement; SAQ A is a simplified evidence-collection mechanism that reflects your reduced risk profile.
"SAQ A means my PSP is responsible for everything." Wrong. The PSP is responsible for the controls inside their environment. You're responsible for the operational and contractual controls on your side — the third-party management, the script inventory, the payment page tamper detection, the staff training. The whole point of the 22 questions is to verify you've kept up your end.
"SAQ A is just for small merchants." Wrong. Card volume matters for whether you need a QSA-led Report on Compliance (RoC) vs a self-assessment, but the SAQ choice within self-assessment is determined by your acceptance channels, not your size. A Level 4 merchant handling 1,000 transactions a year can be on SAQ D, and a Level 2 merchant handling 1 million can be on SAQ A. It depends entirely on the data flow.
"SAQ A means no audit." Wrong. Your acquiring bank can still ask for an audit at any time, especially after an incident. SAQ A reduces the evidence burden in the routine compliance cycle; it doesn't make you immune to investigation.
Worked example: a UK contact centre on SAQ A#
Concrete example to make this real. A 25-seat UK contact centre takes around 4,000 phone payments a month for a B2C service. Pre-Paytia, they were running pause-and-resume recording on a Genesys deployment, agents were typing card numbers into a virtual terminal on their desktop, and their compliance team was self-certifying on SAQ D-Merchant. Annual compliance overhead: roughly £55k including QSA gap assessment, internal evidence collection, agent clean-desk training, network segmentation maintenance.
Implementing channel separation took six weeks. The audio split happens at the SBC layer — the SBC forks the inbound call into two RTP streams, one carrying voice (continuing to the agent) and one carrying DTMF (terminated at Paytia's PCI-validated gateway). The agent's desktop never sees a card number. Call recordings are clean. The CRM stores tokens only.
Post-implementation, they self-certified on SAQ A. The contact centre infrastructure is now out of PCI scope. Annual compliance overhead dropped to roughly £12k — most of which is now the script management on their booking portal rather than anything contact-centre-related. The 78% reduction matches what we see across most contact-centre migrations.
The integration didn't change the customer experience. The same agents handle the same calls. The customer reads the digits into their phone keypad rather than out loud. The conversation flow is the same. The compliance posture changed completely.
How Paytia keeps you on SAQ A#
Paytia is a PCI-validated payment service provider that sits between your contact centre infrastructure and the acquirer. Three things matter for SAQ A eligibility:
First, the audio channel is genuinely split. The DTMF tones travel down a separate path that's terminated at Paytia's gateway, not at your contact centre. Your agents, your call recorder, your QA tools, and your CRM all hear flat tones. That's what keeps your contact centre out of scope.
Second, Paytia issues you a token in place of the PAN. Your CRM stores the token. Your recurring billing uses the token. Your refund workflow uses the token. The actual card number never leaves Paytia's PCI-validated environment.
Third, Paytia maintains its own Attestation of Compliance, which we provide to you annually for your third-party management evidence. Your acquirer asks for the AOC, you hand it over, done.
For the full architecture of how the channel separation works under the hood, see our PCI-compliant call centre page. For the eligibility comparison with SAQ D, see our SAQ A vs SAQ D guide. For a more general background on the data security standard itself, see our what is PCI DSS explainer.
Next steps#
If you're trying to work out whether you qualify for SAQ A, the practical path is to map your current card data flows and check each against the three eligibility scenarios. If your contact centre is the blocker, that's the largest category of merchants who could be on SAQ A but currently aren't — and it's the one DTMF masking with channel separation directly solves.
For a working demo of how Paytia keeps a contact centre on SAQ A while preserving the agent experience, book a 15-minute call. For a broader read on the cost-of-compliance pattern this affects, see the Pinnacle Group case study — they took the same path from SAQ D to SAQ A and documented the saving. If you'd like to talk through your specific situation before booking a demo, the contact form goes straight to our UK team.
The structural read is that SAQ A is the merchant's reward for getting card data out of their environment. Every control PCI SSC has added since v3.2.1 — script inventory, tamper detection, the customised approach — sits inside that same logic. The merchants who'll be on SAQ A in 2027 are the ones who finished their architecture work in 2026. Worth starting now.
Get to SAQ A with channel separation
Paytia splits the audio channel during card entry so card data never enters your contact centre. The architecture that legitimately keeps phone-payment merchants on SAQ A — and cuts compliance overhead by 60-80%.
