Why SAQ A Beats SAQ D for Contact Centres — Cost, Time, Risk

Last updated: 29 May 2026

If you're a compliance lead at a contact centre weighing up SAQ A vs SAQ D, here's the honest answer up front: SAQ D isn't a goal, it's a symptom. You're filling in 300 questions because your agents, phone system and call recordings are inside the cardholder data environment. SAQ A exists for merchants who've moved card data out of that environment entirely — typically by routing the card capture through a PCI-validated third party so the contact centre never sees, hears or stores the PAN. Same payment, same customer, completely different scope.

We see this calculation play out every month. A telecoms operator running 80 agents on SAQ D was spending roughly £120,000 a year on audit prep, QSA fees, vulnerability scans, agent re-training and the soft cost of senior compliance time. After moving to DTMF masking for card capture, the same business filed SAQ A in 2026 with one compliance manager and a week of prep. The same answer keeps coming back across insurance, utilities and retail — the cost difference between the two SAQs runs into six figures once you count audit, scope and breach insurance.

This piece walks through the practical case: what SAQ A actually covers, why SAQ D bites contact centres harder than any other merchant type, the four conditions that have to be true before you qualify for SAQ A, and how the move pays for itself in year one. If you want the full side-by-side on the eligibility rules, our pillar guide on SAQ A vs SAQ D guide covers the question structure in more depth.

SAQ A vs SAQ D for a contact centre: the headline difference#

SAQ A is the short form. It's 22 questions covering policy, vendor management, the fact that you don't store cardholder data, and a small block on website security if you take payments online. The PCI Council's eligibility wording for SAQ A reads almost like a checklist: you've outsourced all payment channels to PCI-validated third parties, your systems don't store, process or transmit cardholder data on paper or electronically, and the third party can confirm your eligibility in writing.

SAQ D is the long form. It's 300+ questions covering all 12 PCI DSS requirements at full depth — network segmentation, access control, secure development, change management, incident response, the lot. It exists because card data lives somewhere in your environment, which means the entire perimeter around that data is in scope. For a contact centre, that perimeter is huge: agent desktops, the CRM that stores notes, the call recorder, the softphone, the VoIP carrier, the agent's home Wi-Fi if they work from home, the corporate VPN that connects them.

When we talk to contact centre operators, the question we hear most often is "how much scope reduction does SAQ A actually buy?" The honest answer is most of it. Once card data doesn't reach your environment, you don't need quarterly ASV scans on your customer-facing systems, you don't need penetration testing against the cardholder data environment (because there isn't one), and your annual evidence pack shrinks from a hundred pages to under twenty. That doesn't make the policies optional, but it does mean the auditor isn't crawling through agent desktops and call recordings to verify them.

Across our base, SAQ A merchants spend 80–95% less time on annual audit prep than they did on SAQ D. Pinnacle Group cut PCI scope by 95% after moving to a phone-payment architecture where DTMF tones are masked before they reach the contact centre — same outcome, same maths, every time.

Why contact centres get stuck on SAQ D in the first place#

A retail merchant taking card payments online can usually qualify for SAQ A by pointing their checkout at a hosted payment page. A contact centre can't do that by default, because the conversation is live and the agent is in the room. Card data flows through the agent's headset, into the softphone, through the call recorder, often into the CRM as call notes, and out to the acquirer through a payment gateway the agent has typed it into. Every one of those systems is now in scope.

The call recording question is the one that catches teams out. PCI DSS Requirement 3.2.1 prohibits storing sensitive authentication data (CVV, full track data, PIN data) after authorisation. If your call recorder is capturing the agent reading back a CVV — even for thirty seconds before a pause-and-resume rule kicks in — you've got SAD on the recording and the recording is now cardholder data. That single line is why a lot of contact centres find themselves on SAQ D when their accountant assumed they were SAQ A.

The other common trap is the CRM. Agents take card data "just for one quick payment," type it into a payment form on their screen, and the screen is being recorded by a quality-management tool that nobody told the compliance team about. The screen capture sits in a vendor cloud for 90 days. That's SAQ D territory, regardless of how briefly the data was on the screen.

This is where the architectural shift matters. Once you decide that card data simply will not reach your agents, three things change at once. The call recorder stays clean because the buyer keys the digits on their phone keypad. The CRM has only tokens and last-four reference, never PAN. The screen-capture tool can keep running because there's nothing card-related on the screen to capture. You've moved the surface area of your audit from the entire contact centre to the small slice of policy that says "we use a PCI-validated third party for card capture." That's SAQ A.

The four conditions to qualify for SAQ A as a phone merchant#

This is the section we get asked about most. The PCI Council updated SAQ A eligibility in v4.0.1 and the line for phone-only merchants is clearer than it's been in years. If you take card payments by phone and you want to qualify for SAQ A in 2026, four things have to be true.

First, your contact centre must not capture, transmit or store cardholder data in any electronic form. "Capture" includes the agent hearing the digits out loud. "Transmit" includes the softphone carrying the audio. "Store" includes the call recorder, the screen recorder and the CRM. The PCI Council's wording in the SAQ A v4.0.1 document is specific: card capture has to be entirely outsourced to a PCI-validated third party.

Second, you have to be using a PCI DSS Level 1 service provider for the card capture leg. Their Attestation of Compliance has to cover the specific service you're using — a generic AoC for the vendor's wider business isn't enough. Ask for the AoC, check the date (it should be within the last 12 months), check that the service description matches what you're actually doing, and keep it on file for your own SAQ submission.

Third, you have to have a documented agent workflow that prevents card data from reaching the agent. The technical control is the masking or channel separation — the procedural control is that agents are trained not to ask for the card details verbally, not to accept them if a buyer reads them out anyway, and to terminate-and-restart the secure capture flow if a slip happens. Our piece on agent scripts for PCI compliance walks through the wording most contact centres land on.

Fourth, your acquirer or card brand has to confirm your eligibility. In practice this is usually a one-line confirmation in writing that you're on the merchant level that permits SAQ A self-assessment. Don't skip this — we've seen merchants build the whole technical case for SAQ A and then have it rejected at the acquirer because they were on a merchant tier (usually Level 1 by volume) that requires a Report on Compliance instead.

What you save by moving from SAQ D to SAQ A#

The savings break into four categories: direct audit cost, internal time, breach insurance premium, and the soft cost of scope.

Direct audit cost is the easiest to put a number on. A QSA-led SAQ D engagement runs roughly £25,000–£50,000 a year for a mid-sized contact centre depending on agent count, segmentation complexity and the QSA firm's day rate. An SAQ A self-assessment, validated and signed off internally by a compliance manager, costs the staff time to fill in the form — typically two to five days of one person's time. Even if you bring in a QSA for an independent review of your SAQ A submission, you're looking at £2,000–£5,000.

Internal time is where the bigger number lives. Across our contact centre clients, a SAQ D programme averages between 200 and 400 hours a year of compliance staff time — evidence gathering, policy updates, agent training tracking, ASV scan remediation, penetration test scoping, and the long tail of "the auditor wants to see…" requests. The same merchants on SAQ A average 30–60 hours a year. The difference at typical UK compliance manager day rates (£450–£650) is £60,000–£120,000 of recoverable time.

Breach insurance premiums move too. We don't see the underwriter conversations directly, but the merchants who've moved tell us their cyber and PCI liability premiums dropped 15–30% at renewal once the scope reduction was documented. The logic is straightforward — the insurer's exposure is smaller when card data doesn't transit your environment.

The soft cost of scope is the one nobody puts on a spreadsheet but everyone feels. SAQ D scope means every new tool the business wants to adopt — a new CRM, a new quality management system, a new workforce management vendor — has to be assessed for PCI impact. That's a procurement drag of weeks per vendor and a tax on innovation that compounds over time. SAQ A scope means card data doesn't touch any of those systems, so the procurement assessment is a one-paragraph confirmation rather than a 40-line risk register.

The risk side of the argument: why SAQ A reduces breach exposure#

The cost case for SAQ A is strong on its own, but the risk case is the one that closes the boardroom conversation. Card data that doesn't reach your environment can't be exfiltrated from your environment. The 2024 Verizon DBIR put 68% of breaches at the human-element category — phishing, credential theft, social engineering, misdelivered files. In a contact centre on SAQ D, every one of those failure modes potentially exposes PAN data. In a contact centre on SAQ A architecture, the same human failure exposes contact information and order history but not the card.

The legal and regulatory consequences scale with the data exposed. A breach that includes PAN triggers PCI forensic investigation, ICO notification (if UK GDPR data is also involved), card brand fines, and potential acquirer-imposed remediation costs. A breach that doesn't include PAN may still need ICO notification but doesn't pull in the card-brand side of the cost. The 2023 IBM Cost of a Data Breach report put the average UK breach at £3.9m — the card-brand penalty component alone can run £50–£500 per compromised card, which dwarfs everything else for a high-volume contact centre.

The other risk move is insider risk. Contact centre staff turnover runs 30–45% a year across UK operators. Every leaver is a potential data-loss event under SAQ D, because they had access to card data during their employment. Under SAQ A architecture, a leaver had access to a token environment and the relevant contact information, but never to PAN. That's a meaningfully smaller blast radius for the same operational reality.

The connected piece on this is our breakdown of SAQ D merchant compliance — it covers the 12-requirement structure in detail and is worth reading if you want to understand what you're walking away from when you move to SAQ A.

The migration question: how long does the move actually take?#

This is the practical objection. "SAQ A sounds great, but the migration looks painful and our renewal is in eight months." Across our base, the typical contact centre migration from SAQ D to SAQ A takes 6–12 weeks of active project time, not counting QSA review. The work splits into four phases.

Phase one is mapping. You need a current-state diagram showing every point where card data touches your environment — agent desktop, softphone, call recorder, CRM, screen recorder, payment gateway, network segment. This is usually a two-week exercise with one architect and one compliance lead. The output is the document the auditor will ask for in eighteen months.

Phase two is the technical change. Most contact centres pick DTMF masking or channel separation as the mechanism for moving card data out of agent scope — our explainer on DTMF masking vs channel separation covers the trade-offs. The integration work depends on your telephony — a SIP-based contact centre platform can usually deploy in 2–4 weeks; an older TDM PBX takes longer because the SIP trunk side has to be re-architected.

Phase three is the procedural change. Agent scripts updated, training delivered, quality monitoring updated to flag verbal card-data attempts, exception handling documented. This is the bit that always takes longer than the technical change — plan for 4–8 weeks of incremental training and floor-walking. Our piece on moving from SAQ D to SAQ A has a detailed agent-training section.

Phase four is the SAQ A submission. New documentation pack, vendor AoC on file, ASV scans confirmed clean for the residual perimeter, acquirer confirmation. Usually 2–3 weeks of compliance lead time.

Where teams underestimate is the change-management side — you're asking floor managers and team leaders to accept a new payment flow at the same time as hitting their normal service-level targets. Run it as a managed cutover with a small pilot team for two weeks before the wider rollout, and have a clear rollback if call abandonment spikes.

When SAQ D is the right answer (and how to make peace with it)#

SAQ A isn't always achievable. Three situations push you onto SAQ D regardless of how much you'd prefer the short form.

First, regulatory constraints in some sectors require the agent to verbally confirm specific details with the customer — some insurance and pensions workflows, some safeguarding-sensitive financial services flows. If the agent has to read back card data as part of a regulator-mandated verbal check, you can't avoid the agent hearing the data and SAQ D is the answer.

Second, some legacy payment platforms can't integrate with a PCI-validated third party for card capture. The vendor has the PAN in their database whether you like it or not. Until you migrate off, your environment includes that database and SAQ D applies.

Third, very high-volume contact centres at Level 1 merchant tier are required by their acquirer to file a Report on Compliance rather than any SAQ — the volume threshold is typically 6 million transactions a year for Visa or Mastercard. The architectural decisions are still worth making (a clean ROC is much cheaper than a complicated one), but the form itself is mandated.

If you're stuck on SAQ D for one of these reasons, the play is to minimise scope rather than eliminate it. Tight network segmentation, locked-down agent desktops, encrypted call recording with strict access controls, and aggressive data minimisation (don't keep what you don't need). Our pillar guide on PCI SAQ levels explained covers the variants between SAQ A-EP, SAQ B-IP and the others — sometimes the right answer isn't SAQ A but one of the in-between forms that still gets you scope relief without a full SAQ D programme.

Common objections and the honest answers#

"Our acquirer says we can't move to SAQ A." This usually means one of three things: you're at Level 1 by volume (and need a ROC, not an SAQ), the acquirer hasn't seen the AoC from your card-capture vendor yet, or there's a misunderstanding about which entity owns the merchant ID. Walk the conversation back to the AoC. If it's a Level 1 issue, you're not moving to SAQ A regardless of architecture — but the scope-reduction work is still worth doing because it shrinks the ROC.

"Our agents won't accept a payment flow they can't see." The agent visibility argument is real but solvable. Modern phone-payment platforms give the agent a real-time status panel — they see the buyer's progress through the card-entry steps without seeing the digits. The agent can re-prompt, retry, escalate or terminate. The buyer doesn't experience a black-box handoff because the agent is on the call the whole time, supporting them through the transaction.

"What about returns and refunds where we don't have the original card?" This is a workflow question, not a PCI question. Most contact centres on SAQ A handle refunds through the same secure capture flow as the original payment — the buyer keys the card details again. For card-on-file scenarios, you tokenise the original payment and process the refund against the token. Neither pattern reintroduces card data to the agent.

"We use a hosted payment page on our website — doesn't that already put us on SAQ A?" Possibly for the online channel. But if you also take phone payments and the phone channel is unmasked, the phone leg is on SAQ D and you can't selectively SAQ A part of your operation. The eligibility is for the merchant entity, not the channel. You have to fix the phone channel for the SAQ A designation to apply to your business.

If you're working through this calculation, our SAQ A glossary entry has the bare definition, and the contact centre industry page has more on the broader PCI architecture for inbound and outbound contact centres.

What the maths looks like in year one#

For a typical 50-agent UK contact centre on SAQ D today, our model puts year-one savings from moving to SAQ A at £95,000–£180,000. The breakdown: £25–40k of direct audit cost reduction, £60–120k of recovered compliance manager time, £10–20k of reduced breach insurance premium. The cost side is roughly £20–40k of integration project work and £5–10k a year of ongoing third-party masking service. That's a payback inside the first year for most operators.

The number we don't put on the spreadsheet but should is the opportunity cost of getting it wrong. We've talked to two contact centres in the last six months that took breaches under SAQ D scope and ended up with brand-side fines and remediation costs north of £500k each. Both said in hindsight they'd been meaning to move to SAQ A for two years and the project kept getting deferred. The cost of the breach was 5–10x what the SAQ A migration would have cost.

If your contact centre is on SAQ D today and the question is whether SAQ A is worth the project, the maths is rarely close. The harder questions are the four eligibility conditions — if you can satisfy them, the rest is mechanical.

The hidden SAQ D costs nobody puts on the spreadsheet#

The headline figures we've covered — audit fees, compliance time, insurance — are the visible costs. There's a second tier of cost that doesn't make the procurement business case but eats budget all year round.

The first hidden cost is agent attrition. Contact centre attrition in the UK runs 30–45% a year industry-wide, and SAQ D operations sit at the upper end of that range. Why? Because the procedural burden on agents under SAQ D is heavier — they're trained on card-handling rules that have legal weight, they're recorded for compliance monitoring, and any slip is potentially a reportable incident. Several of our clients have told us the move to SAQ A reduced their agent attrition by 5–8 percentage points in the year following the move. At a typical cost-to-replace of £4,000–£8,000 per agent (recruitment plus training plus productivity ramp), a 50-agent operation saves £10,000–£32,000 a year on attrition alone.

The second hidden cost is the friction of new-vendor onboarding. Under SAQ D, every vendor that touches the contact centre — workforce management, quality monitoring, screen capture, agent-coaching tools, CRM add-ons — has to be assessed for PCI impact. The procurement team adds 4–8 weeks to every vendor onboarding for the PCI review. Across a year, an active contact centre evaluates maybe 8–15 new tools. That's 32–120 weeks of cumulative procurement delay, which translates to deferred productivity gains worth tens of thousands of pounds.

The third hidden cost is the senior management time spent on PCI as a quarterly board item. SAQ D programmes produce material risk register entries, board-level breach scenarios and audit committee questions. SAQ A programmes produce a one-line confirmation. Across our client base, board-level PCI time drops from 4–6 hours per quarter to roughly 30 minutes per quarter after the move. For boards with directors charging out at £500–£1,000 an hour, that's another £8,000–£20,000 a year of recovered time.

What the contact centre architecture actually looks like under SAQ A#

Let's get concrete. Under SAQ A, when a buyer calls in and reaches the point in the conversation where they want to pay, the agent stays on the line. The agent triggers the secure capture flow — usually a single click in their CRM or a softphone button. The buyer hears a brief prompt explaining that they'll be asked to enter their card details using their phone keypad and that the agent won't see or hear the digits.

The buyer then keys their card number on the keypad. The DTMF tones — the audio beeps each key press produces — are intercepted by a layer that sits between the buyer and the agent. The agent's leg of the call hears a flat tone (or silence, depending on configuration). The call recording captures the same flat tone. The agent's screen shows a progress indicator: "PAN entered (16 digits captured), awaiting expiry..." The agent can see they're on step 2 of 4, but can't see the digits.

Once the buyer completes entry, the captured data goes directly from the masking layer to the payment gateway, never touching any system you control. The gateway responds with an authorisation result, and the masking layer notifies the agent: "Payment approved, £247.50, last four 4242, reference TXN-09183." The agent confirms with the buyer, marks the order paid in the CRM (with the token reference, never the PAN), and the call continues normally.

From a PCI scope perspective, the cardholder data environment under this architecture is the masking layer's infrastructure — which is owned by your card-capture vendor, validated under their PCI DSS Level 1 attestation. Your environment is the agent desktop, CRM and call recorder, none of which see PAN. That's the architectural reason SAQ A applies: you're not in the cardholder data environment, you're connected to one that's somebody else's responsibility.

Edge cases worth knowing before you commit#

A few situations come up regularly that the eligibility wording doesn't address head-on.

Agent screen-sharing for training. If your quality team uses agent-screen monitoring (live or recorded) for coaching, you need to confirm that the monitoring tool doesn't capture the payment step. Most vendors can configure a sensitivity zone that pauses screen recording during the masked card-entry window. If yours can't, the screen recording becomes cardholder data and you've lost the SAQ A position.

Backup payments by the agent. Some workflows allow the agent to enter card details manually if the buyer can't use their keypad (accessibility, very old handset, language barrier). The moment the agent types a PAN into any field, you're back in SAQ D scope for that call. The cleanest answer is to route accessibility cases through a different channel (web form sent by SMS, written authorisation, a callback at a different number) rather than allow agent manual entry. Some of our clients accept a tiny percentage of SAQ D-compliant manual-entry calls handled by a specialist team on a strictly segregated network, but it's a complex carve-out and not recommended unless you have a clear business reason.

Third-party telephony providers. If your contact centre runs on a hosted contact centre as a service (CCaaS) platform, you need to confirm that the CCaaS provider's PCI position is compatible with your masking layer. The two layers have to be designed to interoperate — a masking layer that sits in front of a CCaaS will need API integration with the CCaaS for call control. Most modern providers (Five9, NICE inContact, Genesys, Talkdesk) have integrations available; older platforms sometimes don't.

Multi-jurisdiction operations. If your contact centre handles payments across UK, EU and US regulatory perimeters, the SAQ regime still applies globally to your card brand merchant agreement — but other data-protection regimes (UK GDPR, EU GDPR, US state laws, sectoral rules like HIPAA) sit on top. SAQ A doesn't exempt you from these. The architecture that gets you to SAQ A usually helps with the others (less personal data processed in your environment), but verify each regime independently.

The wider PCI calculation: SAQ A as one part of a scope-reduction strategy#

SAQ A is the right outcome for the phone channel of a contact centre. It's not the whole PCI conversation. Most contact centres also handle payments through other channels — web checkout, payment links sent by SMS, IVR self-service, web chat, recurring billing. Each of those has its own scope question.

The good news is that the same architectural principle works across channels. If card data doesn't reach your environment in any channel, you stay on SAQ A for the whole merchant entity. Payment links sent by SMS push the card capture to a hosted page the buyer opens on their own device — your environment doesn't see PAN. IVR self-service payments use the same DTMF masking layer as live-agent calls — same scope position. Web chat payments use a tokenised secure form embedded in the chat window — same scope position again. The pattern is consistent: outsource the card-handling leg to a PCI-validated provider, keep tokens and metadata in your environment.

The merchants who do this best treat PCI as an architectural question, not a compliance question. The compliance team isn't running around evidence-gathering, they're verifying that the architecture matches the documented data flow. The architecture is built so that card data has nowhere to land in your environment. That's the durable answer.

Next steps#

If you want to see what an SAQ A architecture looks like in practice for your contact centre, the fastest route is a 20-minute scoping conversation — we map your current card data flow, flag the SAQ D triggers, and show you what the SAQ A version would look like. Book a scoping call or see the secure capture flow in a live demo first. If you want to read further before that conversation, the SAQ A vs SAQ D pillar has the full eligibility detail, and our phone payments solution page covers the technical side of the masking layer.