All 9 PCI SAQ Levels Explained — A to D Compared

Last updated: 29 May 2026

If you're a Level 2, 3, or 4 merchant, you don't get audited by a QSA every year. You self-assess. The way you do that is by filling in a Self-Assessment Questionnaire — an SAQ — and submitting it with your annual Attestation of Compliance. The catch is there isn't one SAQ. There are nine. And each one covers a very specific way of accepting card payments. Get the wrong one and you're either over-attesting (claiming compliance you can't prove) or doing 20x more work than you need to.

We see this every week at Paytia. A merchant lands on SAQ D because their acquirer flagged "we take phone payments" and assumed worst case. Two hundred and fifty controls, an external scan, and an annual budget that runs into five figures. After a descoping conversation, the same merchant moves to SAQ A — about 22 controls, no scan, no penetration test. Same business, same payment volume, completely different compliance footprint. The only thing that changed was the SAQ.

This guide walks through all nine PCI SAQ levels in plain English. For each one we'll tell you what it covers, who it's actually for, what you have to attest to, and where merchants get tripped up. By the end you'll know which SAQ matches your real-world setup — and where there's a route to a smaller one.

Why pci saq levels exist in the first place#

The PCI Security Standards Council wrote one standard — PCI DSS — that covers everyone from a corner shop with a single card terminal to a global airline running its own card processing platform. That standard has 12 high-level requirements and several hundred sub-controls. Forcing the corner shop to evidence all of them would be ridiculous. Forcing the airline to skip them would be reckless.

The SAQs are how the Council squares that circle. Each SAQ is a cut-down subset of the full PCI DSS standard, scoped to a specific way of accepting cards. If your environment matches the eligibility criteria for SAQ A, you only have to attest to the controls that genuinely apply to your setup — about 22 of them. If your environment doesn't fit any of the simpler SAQs, you land on SAQ D and you're answering questions about all of it.

So when people say "PCI SAQ levels" they're really talking about two things at once. First, the merchant level (1, 2, 3, or 4 — based on annual transaction volume) which decides whether you self-assess at all. Second, which SAQ variant you use to do that self-assessment. We've covered the merchant levels in our PCI DSS primer. This piece is about the second part.

SAQ A — fully outsourced card-not-present#

SAQ A is the smallest, simplest SAQ in the suite. It exists for merchants who never touch card data themselves. Every card-not-present transaction is handled by a PCI-DSS-validated third party — a hosted checkout page, a tokenised iframe, a redirect to a payment service provider. Your servers, staff, and networks never see a PAN, a CVV, or anything else sensitive.

You can only file SAQ A if every payment channel meets that test. Take one phone order on a Tuesday afternoon where an agent typed the card number into a CRM? You're off SAQ A. Take MOTO orders via a virtual terminal in your back office? You're on SAQ C-VT, not SAQ A. Have a website with a JavaScript checkout that posts card data through your domain? You're on SAQ A-EP, not SAQ A.

Where this gets interesting is contact centres. A traditional MOTO setup with agents typing cards into a payment screen lands on SAQ D. But if you switch to a system like Paytia's, where the buyer keys the card themselves via DTMF tones and your agent never sees or hears the digits, you can drop onto SAQ A. We've walked through that journey for contact centres and it's the single biggest scope reduction available to most merchants. Pinnacle Group cut their PCI scope by 95% with this move.

For the full eligibility breakdown and the 22 controls you actually have to evidence, see our SAQ A guide.

SAQ A-EP — e-commerce with partial control#

SAQ A-EP sits between SAQ A and SAQ D for e-commerce merchants. The use case is specific: you've outsourced card processing to a PCI-validated payment processor, but your own website still influences how the cardholder data form is delivered to the customer's browser. Think direct post integrations, JavaScript that posts card data to a third party but is served from your domain, or any setup where your servers shape the page that captures the PAN even though they don't store or transmit it themselves.

SAQ A-EP runs to roughly 150 controls — significantly more than SAQ A. You'll need quarterly external vulnerability scans by an ASV (Approved Scanning Vendor), file integrity monitoring on the web servers that serve the checkout, and proof of secure development practices. The shift to PCI DSS v4.0 has tightened SAQ A-EP further — particularly around client-side script integrity (Requirements 6.4.3 and 11.6.1), which now apply if any element of your checkout page is served from your infrastructure.

If you're on SAQ A-EP and looking to move down to SAQ A, the play is a full redirect or a fully-hosted iframe served from the PSP's domain — no script of yours running on the checkout page. That's an architecture call, not a paperwork call. Our online payments setup is designed to land merchants cleanly on SAQ A rather than SAQ A-EP.

SAQ B — standalone dial-out terminals#

SAQ B covers merchants who only accept cards through standalone, dial-out card terminals or imprint machines. Standalone means the device is not connected to any IP network — it dials the acquirer over a phone line. Imprint machines (the old carbon-paper kind) still get a mention in the SAQ because some merchants legitimately still use them for fall-back capture, although the Council has signalled this category will shrink over time.

The eligibility test is strict. No cardholder data on any computer system, no electronic storage, no IP-connected terminals. If your terminal connects via ethernet or Wi-Fi to a router, you're not on SAQ B — you're on SAQ B-IP. The control count for SAQ B is small (around 41 controls), and the questions focus on physical security of the device, the imprint slips, and the transaction receipts.

For most merchants in 2026, SAQ B is a legacy SAQ. New terminal deployments are nearly always IP-connected, which pushes you to SAQ B-IP. Where we still see SAQ B in active use is small rural businesses, mobile traders, and some charity events using a backup phone-line terminal.

SAQ B-IP — standalone IP-connected terminals#

SAQ B-IP is the IP-connected equivalent of SAQ B. The terminals are still standalone (no integration with point-of-sale software, no electronic storage of cardholder data on your systems), but they connect to the acquirer over IP rather than a phone line. That extra network exposure adds controls — typically around 83 controls compared to SAQ B's 41.

You'll need a network diagram showing the segregation between the terminal network and the rest of your IT environment, evidence that the terminal isn't reachable from your office LAN, and basic firewall and patching controls on whatever router sits between the terminal and the acquirer. Quarterly ASV scans are required for the terminal's external IP address.

Where merchants get caught is assuming SAQ B-IP "because we just have a terminal." If that terminal is integrated with a till system — sending totals, syncing inventory, or sharing a customer database — you're not on SAQ B-IP, you're on SAQ C. The standalone test is genuinely standalone.

SAQ C — payment application integrated into a system#

SAQ C is for merchants whose payment application is part of a wider system that's connected to the internet. Classic examples: a till system that integrates with a chip-and-PIN terminal and also runs back-office reporting from a network, a hospitality property management system with integrated payment capture, an MOT booking platform that handles its own card processing.

The control count for SAQ C is around 160. You're attesting that the payment application is PA-DSS validated (or PCI-DSS validated under the newer Software Security Framework), that the network it sits on is segmented from any other systems, and that you've got the usual suite of vulnerability management, change control, and access management in place.

SAQ C is where the cost-benefit calculation starts to favour descoping. At 160 controls you're not far off SAQ D's 250-ish, and the work to evidence everything — scans, penetration tests, file integrity, change control — adds up fast. A lot of SAQ C merchants would be better off moving payment capture entirely off their main system to a hosted gateway or a phone-based capture flow, dropping straight to SAQ A.

SAQ C-VT — virtual terminal MOTO merchants#

SAQ C-VT is the SAQ for merchants who process card-not-present transactions through a web-based virtual terminal provided by a PCI-DSS-validated payment gateway. The classic setup is an MOTO operation where staff take card details over the phone, then key them into a browser-based payment form hosted by Worldpay, Stripe, Opayo, or similar.

The eligibility criteria are tight. The virtual terminal must run in an isolated browser on a dedicated device that is used for nothing else. No printing of card numbers, no copying into spreadsheets, no integration with CRMs. Realistically very few contact centres can hand-on-heart say they meet that bar — agents take calls on shared workstations, paste details into multiple systems, and the device almost never lives in a locked-down state.

This is why so many contact centres that think they're on SAQ C-VT are actually carrying SAQ D risk in practice. The QSA community has been clear: if the virtual terminal is open in a tab next to the agent's CRM, you're not eligible for SAQ C-VT. The realistic path off SAQ C-VT, for any merchant taking card details by phone, is DTMF masking or channel separation, both of which remove the agent from the cardholder data flow entirely and unlock SAQ A.

SAQ D-Merchant — everything else for merchants#

SAQ D for Merchants is the catch-all. If you don't fit any of the simpler SAQs — A, A-EP, B, B-IP, C, C-VT, or P2PE — you're on SAQ D. It runs to roughly 250 controls and covers the full breadth of PCI DSS. Quarterly ASV scans, annual penetration testing, file integrity monitoring, formal incident response, secure development lifecycle, network segmentation evidence, deep logging and monitoring — the lot.

SAQ D is where most contact centres end up by default if they take card payments by phone without a descoping technology. It's also where merchants land when they've grown out of a simpler SAQ — a new payment channel was added, a CRM started storing card numbers, or an agent screen-shares a payment session. Once any cardholder data touches your environment, you're on SAQ D.

The cost of being on SAQ D versus SAQ A is the single biggest financial decision in PCI compliance. We've covered the realistic numbers in our breakdown of PCI compliance costs — the difference can be £15,000-£25,000 a year for a mid-sized merchant once you add up scans, pen tests, staff time, and tooling. For most contact centres, the route off SAQ D is a descoping technology, not better controls.

SAQ D-Service Provider — the version for processors and platforms#

SAQ D for Service Providers is a separate, longer version of SAQ D aimed at organisations that store, process, or transmit cardholder data on behalf of other merchants. If you run a payment gateway, a tokenisation platform, a hosted checkout, an IVR payment service like Paytia, or any kind of payment-related SaaS — you complete the service provider variant.

The control set is even larger than SAQ D for merchants, because service providers carry obligations to their customers as well as to the card brands. There are extra requirements around customer reporting (12.9), shared hosting (A.1), and Designated Entities Supplemental Validation (DESV) for the largest service providers. PCI DSS v4.0 has added more service-provider-only requirements around cryptographic key custodianship, software inventory, and continuous evidence of control effectiveness.

For our customers, Paytia files SAQ D-Service Provider and provides our customers with the relevant section of our Attestation of Compliance. That AoC is what they reference in their own SAQ A as the validated third party handling card data on their behalf.

SAQ P2PE — point-to-point encryption deployments#

SAQ P2PE is the newest and smallest SAQ in the suite. It applies only to merchants using a PCI SSC-listed Point-to-Point Encryption (P2PE) solution — a tightly defined kind of card-present setup where the card data is encrypted at the moment of card insertion (inside the terminal's secure hardware) and only decrypted by the P2PE solution provider, never by the merchant.

The eligibility test is strict. Your P2PE solution has to be on the PCI SSC's official listing — not just "encrypted" by your vendor's claim, but a validated P2PE listing. The terminals have to be P2PE-validated devices, the key management has to follow the solution provider's PIM (P2PE Instruction Manual), and you can't have any legacy non-P2PE flows in scope. Get all that right and your control count drops to around 33 — close to SAQ A territory.

SAQ P2PE is the right answer for retailers and hospitality businesses that take a lot of card-present transactions. It's not a fit for contact centres, e-commerce, or MOTO. For those channels the path to a small SAQ runs through SAQ A, not SAQ P2PE.

How to choose the right PCI SAQ level for your business#

Picking the right SAQ comes down to four questions, in order. First: how do you actually accept cards today? List every channel — web checkout, phone orders, terminals in shops, payment links by email, recurring billing, in-app payments, IVR. Don't skip the ones that feel small; a single Tuesday-afternoon phone order taken by an agent typing a card into a CRM puts you on SAQ D for the whole business.

Second: for each channel, does any cardholder data touch your systems, staff, or networks? "Touch" includes hearing it on a phone call, seeing it on a screen, having it transit your network, or storing it anywhere — even briefly, even encrypted, even in a notebook. If the answer is no for every channel, you're a candidate for SAQ A. If yes for any channel, you're on a bigger SAQ.

Third: is there a realistic descoping option? Most merchants on SAQ D for contact centre reasons can move to SAQ A by adopting DTMF masking, channel separation, or pay-by-link. Most merchants on SAQ A-EP can move to SAQ A by switching to a fully-redirected or fully-hosted checkout. We've laid out the contact-centre route in detail in SAQ A vs SAQ D guide.

Fourth: have you confirmed the SAQ choice with your acquirer? Some acquirers have idiosyncratic interpretations and prefer you on a larger SAQ for their own risk management. It's worth a conversation before you spend three months evidencing the wrong one.

What changed in PCI DSS v4.0 across the SAQs#

The SAQ structure carried over from PCI DSS v3.2.1 to v4.0 — same nine SAQs, same eligibility criteria for each. What changed is the control content within each SAQ. SAQ A picked up two new requirements around client-side script management (6.4.3) and tamper-detection on the payment page (11.6.1), both targeted at e-skimming attacks like Magecart. Those came into force as mandatory on 31 March 2025.

SAQ A-EP and SAQ D picked up more substantial additions — targeted risk analyses (12.3.1), authenticated internal vulnerability scans (11.3.1.2), and stronger customised-approach options for organisations that can document a control's intent and effectiveness rather than ticking a defined-approach box. Service providers got extra requirements around cryptographic architecture documentation (3.2.1) and software inventory (6.3.2).

Across the board, v4.0 has pushed merchants towards evidence-based attestation rather than checkbox attestation. Your QSA or your acquirer is going to want to see the artefacts behind your SAQ — scan reports, policy documents, change records, training logs. Treat the SAQ as the summary, not the work. We've covered the broader v4.0 changes in our PCI compliance for telephone payments guide.

Common mistakes when picking an SAQ#

The first mistake is the one we've already mentioned: assuming SAQ D because it feels safer. SAQ D isn't safer. It's bigger. If your environment genuinely qualifies for SAQ A, attesting to SAQ D is a waste of money and gives your team a 250-control document to keep current instead of a 22-control one.

The second mistake is the opposite — filing SAQ A when one channel doesn't qualify. The classic example is a SaaS with a hosted Stripe checkout (clean SAQ A territory) that also has a customer success team taking the occasional phone payment via a manually-keyed virtual terminal. That phone payment channel makes you ineligible for SAQ A across the whole business. Either remove the phone channel, or move it onto a descoping flow that keeps you on SAQ A.

The third mistake is treating the SAQ as a one-off. PCI DSS attestation is annual. If anything about your payment environment changes mid-year — new acquirer, new gateway, new payment channel, new CRM integration — your SAQ might need to change too. Material changes also trigger an obligation to update your Attestation of Compliance before the annual renewal, not at it.

The fourth mistake is ignoring the related SAQ in your supply chain. If your service provider's AoC doesn't cover the requirements you're relying on them for, you can't validly carry those requirements as "outsourced" in your own SAQ. Check the AoC. We see this caught at audit far too often.

How the SAQ levels interact with merchant levels (1, 2, 3, 4)#

One thing worth being clear on, because it trips people up constantly: SAQ levels and merchant levels are different things. Merchant level is set by your annual transaction volume. Level 1 is over 6 million Visa/Mastercard transactions a year — those merchants don't file an SAQ at all, they have a full Report on Compliance (ROC) signed off by a QSA. Level 2 is 1-6 million, Level 3 is 20,000-1 million for e-commerce, and Level 4 is everything below. Levels 2-4 self-assess via an SAQ.

Which SAQ a Level 2, 3, or 4 merchant files is a separate decision from their merchant level. A Level 4 corner shop with a single dial-out terminal files SAQ B. A Level 4 e-commerce site using a hosted Stripe checkout files SAQ A. A Level 4 contact centre with manually-keyed phone payments files SAQ D. Same merchant level, three different SAQs, three completely different control sets to evidence.

At Level 1 the SAQ question still matters indirectly. The ROC is structured around the same control families, and the QSA will still look at your environment and ask which simplified scoping rules apply. A Level 1 merchant that's engineered itself onto an SAQ A-equivalent architecture (cardholder data fully outsourced) has a much smaller ROC than one that hasn't. The descoping logic that moves Level 2-4 merchants from SAQ D to SAQ A also dramatically reduces the cost of the Level 1 ROC.

The other practical wrinkle: your merchant level can change. If you cross the 1 million Visa transaction threshold mid-year, you move up a level and may need to file a ROC instead of an SAQ at your next renewal. Plan for the transition rather than getting surprised by it. Most acquirers will give you notice, but it's worth tracking your own volume.

How Paytia maps to the SAQ levels#

Paytia exists to move contact centre merchants from SAQ D to SAQ A. Our agent-assisted payment platform sits between your contact centre and your payment service provider. When a buyer reads out a card number, the digits never reach your agent's screen, your phone system, your call recording, or your CRM. They're captured by Paytia's hosted DTMF capture and posted directly to your acquirer or gateway as a tokenised transaction.

The compliance effect is straightforward. With Paytia in the flow, you can validly attest that no cardholder data is stored, processed, or transmitted by your environment — the test for SAQ A. We file SAQ D-Service Provider on our end and provide you with the AoC excerpt you need to reference. You're left attesting to the 22 SAQ A controls instead of the 250-odd in SAQ D.

The merchants this matters most for are contact centres, MOTO operations, charities running phone-based donor lines, healthcare practices billing private patients, and insurance teams taking renewal payments. We've documented those journeys in our contact centre PCI guide. Pinnacle Group, Warby Parker, and InsureandGo are working examples.

Side-by-side: control counts, scans, and pen tests across the SAQs#

Numbers help here. The PCI Security Standards Council doesn't publish a single "controls per SAQ" table, but the count is implicit in the questions on each SAQ form. Here's the working summary we use when we're walking a merchant through the choice.

SAQ A runs to roughly 22 controls under PCI DSS v4.0. No external ASV scans required on your environment (you're relying on the third party for that). No internal vulnerability scans. No penetration testing. The new client-side script controls (6.4.3 and 11.6.1) are the only fresh additions you need to evidence. Annual SAQ submission plus a current AoC from each PCI-validated third party you rely on.

SAQ A-EP runs to roughly 150 controls. Quarterly external ASV scans on every public IP that serves the checkout flow. Internal vulnerability scans (now authenticated under v4.0). Annual penetration test required. Secure development lifecycle evidence — code reviews, change control, separation of dev/test/prod. File integrity monitoring on the web servers. This is a real engineering programme, not a paperwork exercise.

SAQ B is around 41 controls, no scans, no pen test. SAQ B-IP is around 83 controls with quarterly external ASV scans of the terminal's external IP. SAQ C lands around 160 controls with full quarterly scans and an annual pen test. SAQ C-VT is around 80 controls — but with the eligibility caveat that very few merchants genuinely qualify.

SAQ D for Merchants is around 250 controls, full ASV scans, full pen test (internal and external), and the longest list of operational evidence. SAQ D for Service Providers is larger again — adds the customer-facing requirements in section 12.9 and the DESV controls if you're flagged as a Designated Entity. SAQ P2PE drops back to around 33 controls, no ASV scans, no pen test — the smallest SAQ in the suite for card-present setups.

The headline you should take away: SAQ A is dramatically smaller than every other SAQ, including SAQ A-EP. The work to engineer your environment onto SAQ A pays back every year for as long as the business is running cards. If you're handling a phone channel today and you've never priced the SAQ A route, it's worth twenty minutes of your time.

A real-world example: contact centre moving from SAQ D to SAQ A#

One of the working examples we walk new prospects through is a contact centre we'll call Acme Renewals — a 60-seat operation handling insurance renewals across the UK. They were on SAQ D, which they'd filed every year since 2019 because their acquirer told them to. Annual external ASV scan, annual penetration test, full PCI policy stack, formal incident response, agent training programme. Annual compliance cost (excluding the policy work that came out of the day job) was running at around £18,000.

The payment flow was simple. A customer rang in to renew a policy. The agent confirmed the policy details, quoted the renewal, and the customer agreed. The agent then asked for the card details, typed them into a virtual terminal in a browser tab, and clicked submit. The card data sat momentarily in the browser's form fields, transited the corporate network, hit the virtual terminal's hosted form, and posted from there to the acquirer. The customer's voice on the call was recorded for quality, which meant the card digits were also in the call recording.

That setup is squarely SAQ D. Card data in the browser, card data on the network, card data in the call recording, card data in the agent's screen and (briefly) memory. None of which is the agent's fault — it's the architecture.

The descoping move was a Paytia integration. When the conversation reached the payment step, the agent clicked a button in their existing CRM. That triggered a Paytia hosted capture flow. The customer's voice was muted on the call recording for the duration of the digit entry. The customer keyed their card digits as DTMF tones, which Paytia translated server-side into a tokenised transaction. The agent stayed on the line, could see status updates ("PAN captured", "CVV captured", "transaction approved"), but never saw the digits themselves. The audio captured by the call recording during the digit entry was silence.

The compliance effect was a clean drop from SAQ D to SAQ A. No card data in the browser, on the network, or in the call recording. The corporate environment was no longer in the cardholder data environment at all. Acme's QSA confirmed the SAQ A path, the acquirer agreed, and the following year's attestation was the 22-control version. Annual compliance cost dropped to under £4,000. Net saving roughly £14,000 a year, recurring.

This is the descoping route that defines the whole reason for the SAQ structure existing. The standard rewards merchants who genuinely take cardholder data out of their environment — and the SAQ levels are how that reward gets paid out.

Next steps#

If you're not sure which of the PCI SAQ levels applies to your business — or you suspect you're carrying a bigger SAQ than you need — we can walk through your payment flows in 20 minutes and tell you. Get in touch with our team or book a live demo to see how the descoping route to SAQ A looks for a contact centre like yours. We'll give you a straight read on your options, even if the answer is "stay where you are."

Bring three things to the call and we can usually map your SAQ path in the first ten minutes: a list of every channel you currently take cards on, a copy of your current AoC or SAQ (whichever one you most recently filed), and a rough sense of your annual transaction volume. From there we can tell you which SAQ you should be on, which one you're realistically on today, and whether there's a route to a smaller one. The conversation costs nothing, and the answer often saves five figures a year in compliance overhead.