Originally published on Paytia Insights.
If you take card payments over the phone, you're almost certainly on SAQ D. And SAQ D is brutal — over 300 controls covering all 12 PCI DSS requirements, with quarterly external scans, annual penetration testing, file integrity monitoring, the works. For most contact centres, the annual cost of staying compliant runs into six figures.
Here's the thing nobody told you when your QSA scoped the project: SAQ D isn't your only option.
Why call centres default to SAQ D
The PCI DSS scoping rule is simple in principle. Any system that stores, processes, or transmits cardholder data — plus anything connected to those systems — is in scope. For a typical call centre that means:
- The agent's PC (they hear the card number, often type it into a CRM)
- The phone system (the audio carries the PAN over the network)
- Call recording infrastructure (records contain CHD, often for years)
- Screen recording (captures CHD as agents type)
- The CRM (stores customer records that may include payment data)
- The network segments connecting all of the above
Once that environment is in scope, you can't qualify for SAQ A, A-EP, B, B-IP, C-VT, C, or P2PE. The only SAQ left is D.
What SAQ A actually requires
SAQ A is the lightest self-assessment in the standard. It applies to merchants who have fully outsourced all cardholder data functions to PCI DSS validated third parties — meaning your business never electronically stores, processes, or transmits cardholder data on your systems.
The full SAQ A is about 16 controls — mostly around managing your third-party service providers, basic information security policy, and physical security of any paper records. Compared to SAQ D, it's roughly a 95% reduction in compliance burden.
The eligibility constraint is strict, though. Cardholder data must never enter your environment. Not on the agent's screen. Not in the call recording. Not in the CRM. Nowhere.
The descope mechanism: secure DTMF capture
The path from SAQ D to SAQ A for a phone channel is well-established in the industry: secure DTMF capture (often called "DTMF masking" or "pause-and-resume" — though those terms describe weaker variants).
Here's how the strong version works. When the agent reaches the payment step in the call, they trigger a process that:
- Routes the customer's audio through a separate, PCI-compliant payment gateway in parallel with the agent
- Prompts the customer to enter their card number on their phone keypad
- Captures the DTMF tones at the gateway and sends them directly to the payment processor
- Suppresses the tones from reaching the agent and from being recorded
- Returns only the authorisation result to the agent ("Approved" or "Declined")
The customer never leaves the call. The agent stays in the conversation throughout. But the cardholder data never touches your environment — it goes from the customer's phone to the payment processor and nothing in between is in scope.
That's what enables SAQ A. The agent's PC, the phone system, the call recording, the CRM — none of it ever sees CHD, so none of it is in scope under PCI DSS.
Why "pause-and-resume" isn't enough
A common mistake is treating call-recording pause as equivalent to descoping. It isn't.
If you pause the recording while the customer reads out their card number, the recording is descoped. But the agent still hears the PAN. The agent's PC still sees it (if they type it into a CRM). The phone system still carries it. Those systems are still in scope, which means SAQ A is still off the table — you're stuck on SAQ D, just with one less component in scope.
True DTMF capture removes the cardholder data from the entire phone channel, not just the recording.
What this is worth in practice
For a 50-seat call centre on SAQ D today, descoping to SAQ A typically saves £80,000–£200,000 per year in compliance costs alone, before factoring in:
- Reduced breach risk (no CHD in scope = no CHD to lose)
- Lower cyber insurance premiums
- Faster audits (a SAQ A AOC can be self-attested; SAQ D often requires ROC engagement)
- Removed need for staff vetting in CHD-handling roles
The catch — there's always a catch — is that the descope only works if every payment flow goes through the secure capture mechanism. One agent taking a card number over voice on one call breaks the whole thing. The control needs to be technical, not procedural: it has to be impossible for an agent to bypass it, not just policy that says they shouldn't.
What to do next
If you're a contact centre on SAQ D and you've never considered descoping, start here:
- Map your CHD flows. Where does cardholder data enter, traverse, and exit your environment? You need this before you can shrink scope.
- Identify the channels. Phone, email, web, post — each needs a different descope mechanism. Phone is usually the hardest and most valuable to fix.
- Talk to your QSA early. A good QSA will tell you what scope reduction looks like for your specific environment. A great one will tell you which of your in-scope systems exist purely because of legacy decisions and can be removed without spending anything.
- Get vendor proof. Any phone payment vendor claiming to enable SAQ A should provide their own AOC and a clear responsibility matrix showing which PCI requirements they cover and which remain yours.
If you want to see how this works in practice — including AOCs, responsibility matrices, and real implementation paths — Paytia builds secure DTMF capture for contact centres. Our customers on SAQ D become eligible for SAQ A typically within 30 days of switching the phone channel over. There's a free open-source PCI SAQ checklist that walks through the SAQ A requirements in plain English if you want to see what the destination looks like before committing to the journey.
Curtis Nash is the CEO of Paytia, which builds PCI DSS-compliant secure phone payment solutions for contact centres.
Top comments (0)