If you run a contact centre that takes card payments over the phone, you are handling regulated data under PCI DSS. You probably knew that already. What you may not realise is how much of your operation the standard actually pulls into scope, what the new version 4.0 requirements changed in March 2025, and how far a few targeted technical controls can shrink your compliance burden — often by 75% or more.
We've been helping contact centres solve this problem since 2016. This guide is everything we've learned about what PCI DSS actually requires, where contact centres get caught out, and the practical steps that move you from a full SAQ D (329 controls) down to a manageable SAQ A (22 controls). If you're deciding whether to hire outside help for the attestation, we've written a separate piece on hiring a PCI compliance auditor that covers what QSAs actually do. It's written for operations leaders, compliance officers, and anyone who's been asked "are we PCI compliant?" and isn't sure what to say.
No fluff. No generic "what is PCI compliance" filler — we assume you know the basics. (If you don't, our what is PCI compliance guide is the right starting point, and what Paytia does for your PCI work is the short version.) If you don't, start with our PCI DSS explainer and come back. This page is about what the standard means specifically for contact centre operations.
What is PCI DSS compliance?
PCI DSS compliance means meeting the Payment Card Industry Data Security Standard — the rules every business that stores, processes, or transmits cardholder data has to follow. The standard is set by the PCI Security Standards Council, backed by Visa, Mastercard, Amex, Discover, and JCB, and enforced through your acquiring bank. It's audited annually.
For a contact centre, PCI DSS compliance means your agents, phone systems, call recordings, and supporting infrastructure all have to meet the standard — or you have to technically remove them from scope. It's not optional, and it's not a certification you earn once and forget.
Why contact centres are a PCI DSS problem
Contact centres are the most exposed environment in the payments industry, and most contact centre managers don't realise how exposed they are until a QSA walks them through it. The issue isn't that you're doing anything wrong — it's that the standard default setup of a contact centre accidentally touches cardholder data in a dozen places.
Here's the chain. A customer calls in to pay. They speak to an agent. At some point they read out their card number, or type it on their keypad with the recording running. The agent's headset hears the number. The agent's workstation is logged into the payment portal. The call recording system captures the whole conversation including the DTMF tones. That recording gets stored — often in a cloud platform you don't fully control. Supervisors listen back for training. QA flags calls for review. Dispute resolution pulls recordings on demand.
Every single link in that chain is "processing or transmitting cardholder data" as PCI DSS defines it. Every workstation, every headset, every recording server, every cloud bucket, every supervisor who can hit "listen to recording" — all of it is in scope. Not because you intended to store card data, but because the standard assesses technical possibility, not just intent.
A 50-seat contact centre that took the "we'll just be careful" approach typically ends up with an in-scope estate of several hundred endpoints, half-a-dozen servers, two or three third-party SaaS platforms, and a recording archive that needs network-segmentation, encryption, access logging, vulnerability scanning, and audit review. None of which was what the business thought it was signing up for when it bought a contact centre suite.
This is what we mean when we say contact centres are exposed. You haven't been careless — the architecture is just built in a way that lets card data leak into places the standard cares about. The good news is that the fix is equally structural: stop card data entering those places in the first place, and most of the scope collapses.
What PCI DSS actually requires of you
PCI DSS is organised around six goals and twelve core requirements. We've covered the full list elsewhere in our PCI DSS requirements guide, so this section focuses on the ones that actually bite for contact centres. If you only read about four requirements, read about these.
Requirement 3: Protect stored cardholder data
This is the headline rule. It bans storage of sensitive authentication data (CVV, PIN, full track data) after authorisation — which is why a properly designed secure virtual terminal never writes those fields to disk in the first place, full stop. It also requires strong cryptographic protection of any Primary Account Number (PAN) you do store. For contact centres, this usually comes up around call recordings. If your recordings capture the keypad tones when customers type their card details, those tones can be decoded back into the PAN and debit card security code (we've also written a separate piece specifically on secure codes on credit cards) — and storing those recordings unencrypted is a direct Requirement 3 violation. You either need to stop capturing the tones (our strong recommendation — see the DTMF masking approach) or encrypt every single recording with documented key management and retention policies.
Requirement 4: Encrypt cardholder data in transit
Every card number that moves between systems must travel over strong cryptography — minimum TLS 1.2, in practice TLS 1.3 these days. That's straightforward for web payments, and increasingly routine for APIs. It gets awkward for phone payments because the "transmission" often happens over old-world voice infrastructure (SIP, PRI, analogue lines) that doesn't speak TLS. If your voice stack carries unprotected DTMF tones, you're transmitting card data in clear — which fails Requirement 4 even if your backend API calls are encrypted.
Requirement 7: Restrict access by business need-to-know
Only people who need card data to do their job should be able to access it. In a contact centre this rule hits hardest at the supervisor level. If a team leader can pull up any call recording on demand — including recordings that captured card numbers — they've got access to card data whether they actively use it or not. You either need to strip card data from recordings (which is hard to do reliably after the fact) or prevent card data reaching recordings in the first place.
Requirement 8: Identify and authenticate access
Every person accessing card data needs a unique ID and strong authentication — typically multi-factor. Shared logins are banned. This matters for contact centres because agent logins are historically quite loose: shared terminals, generic team accounts for training or evening shifts, vendor logins that everyone knows. All of that needs to be cleaned up if card data is in the environment. Or — as with the other requirements — you can move the card data out of your environment and make the whole thing moot.
The other eight requirements matter too, but they're either standard IT hygiene (patching, logging, firewalls) or things you only have to worry about in more complex scenarios. For a typical contact centre, the Requirements 3, 4, 7, and 8 conversation is where the pain lives.
PCI DSS 4.0 changes that hit contact centres hardest
PCI DSS 4.0 is the current version of the Payment Card Industry Data Security Standard, and it became mandatory on 31 March 2025 — that's the effective date every contact centre manager needs to have circled. It replaces version 3.2.1, which had been the standard since 2018. PCI DSS 4.0 introduces 64 new requirements across the twelve PCI DSS control areas, with the biggest operational changes landing on scoping, authentication, encryption, and payment page integrity. A small number of the new requirements were optional until 31 March 2025; from that date onward every single one is mandatory. If your last PCI self-assessment was against 3.2.1, you're now out of date and any QSA assessment will be scored against 4.0.
PCI DSS 4.0 became mandatory on 31 March 2025, replacing the 3.2.1 standard that most contact centres had been running under for years. The new version includes 64 new requirements overall. A handful of them are genuinely disruptive for contact centres.
Requirement 12.5.2 — annual scope review
Under 3.2.1 you could scope your environment once and mostly leave it alone. Under 4.0 you have to review your PCI scope at least annually, and confirm the review with a documented process. Every new phone system, every new CRM integration, every new agent tool — all of it has to be checked for whether it changed your in-scope footprint. For contact centres that change tooling frequently (and most do), that's a real administrative burden, and it catches scope creep that would previously have gone unnoticed until the next audit.
Requirement 8.3.6 — stronger authentication
4.0 tightens password policies (minimum 12 characters, no default passwords, account lockouts) and pushes strongly toward multi-factor authentication. For contact centres with a lot of part-time or seasonal agents, rolling MFA to every single agent workstation is operationally painful. Many teams have been delaying this one, and they're now out of time.
Requirement 11.6.1 — payment page integrity
4.0 requires contact centres with any web-based payment form to monitor the form for unauthorised modifications. Think payment skimming attacks that inject a malicious script into a checkout page to steal card numbers. This primarily affects contact centres that use web forms alongside phone payments — which is most of them, now. You need tamper-detection on every payment form, checked regularly.
Requirement 3.4.2 — PAN masking on display
Any screen that displays a Primary Account Number has to mask all but the first six and last four digits by default. Full PAN display requires an explicit business justification. For contact centres, this typically affects CRM systems that used to show agents the full card number for verification — that's no longer allowed unless you can document why every agent needs it, and even then only for the specific screens where it's justified.
The big practical shift
The biggest practical shift in 4.0 isn't any single requirement — it's the new "customised approach" for compliance. Under 3.2.1, you had to meet each control exactly as specified. Under 4.0 you can meet the intent of a control using a different technical approach, as long as you can document the reasoning and the QSA signs off. This is good news for contact centres with unusual setups, because it gives you flexibility. It's bad news for contact centres that don't have strong documentation practice, because the customised approach requires a lot more written evidence than the prescriptive path.
Our 4.0 telephone payments guide has the full breakdown if you need more depth on any of this.
Scoping: what "in scope" actually means for your contact centre
Scope is the single most important concept in PCI DSS and the thing contact centre managers most often misunderstand. Your scope is the boundary within which cardholder data can exist, move, or be accessed. Everything inside that boundary is subject to PCI DSS controls. Everything outside it is not. The goal, always, is to shrink the boundary.
A contact centre's PCI scope typically includes these components, whether or not anyone intended them to be:
- The telephony platform — your PBX, softphone software, any VoIP gateway, and any SIP infrastructure. If card data travels over it in any form, it's in scope.
- Agent workstations — the physical computers or thin clients agents use. If an agent can type, paste, or otherwise handle card data on the machine, it's in scope.
- The call recording system — servers, storage, cloud buckets, archives, backups. If any recording anywhere in the chain could contain card data, the entire recording estate is in scope.
- The CRM — if the CRM stores transaction data that includes partial or full PANs, it's in scope. Notes fields are a particularly common source of hidden scope: agents have been known to paste card numbers into free-text notes "just temporarily".
- The payment gateway integration — API endpoints, credentials storage, logs. These are almost always in scope regardless of what else you do.
- Supervisor and QA tools — anything that can listen to recordings, review transactions, or access customer data. In scope by association.
- Network segments that touch any of the above — which in an unsegmented office network is, essentially, everything. Network segmentation is the easiest way to reduce scope by brute force.
When a QSA assesses your environment, they're checking all of this — not just what you think contains card data, but what technically could. And they're right to. The cardholder data environment (CDE) is defined by capability, not by intent.
The good news is that there are only two ways to reduce scope, and one of them is dramatically more effective than the other. You can either add controls to your existing systems (the hard way), or you can remove card data from those systems entirely so they drop out of scope (the easy way). Every hour you spend trying to add controls to legacy telephony is an hour you could have spent removing telephony from scope in the first place.
Removing card data from the CDE is called descoping, and it's the single most valuable lever available to contact centres. Done properly, it cuts your PCI burden by 75% or more — not just in audit hours, but in network segmentation complexity, recording retention policies, staff training, pen test coverage, and vulnerability management.
The four SAQ types — and which one you qualify for
If you're not undergoing a full Report on Compliance (you're probably not, unless you process over 6 million Visa or Mastercard transactions a year), you'll be completing a Self-Assessment Questionnaire instead. There are several SAQ types. Four of them apply to contact centres.
SAQ A
22 controls. You qualify for SAQ A if you've outsourced all card processing to a PCI DSS Level 1 validated third party, and your own systems never store, process, or transmit card data. The only controls you're responsible for are the ones that govern your relationship with the third party: contract due diligence, link integrity, and basic security hygiene on your side of the handoff.
This is the lightest tier. It's also where we help contact centres land when they deploy Paytia properly. If Paytia captures the card data and you never see it, your SAQ shrinks from a multi-hundred-question monster to a handful of pages. Most contact centres can complete SAQ A in a morning with their compliance team.
SAQ A-EP
191 controls. SAQ A-EP applies if you've outsourced card processing to a third party but your own web pages contain or load the payment form. The thinking is that if a browser request touches your domain during the payment flow, your website is in scope even though your backend doesn't see the card. A-EP adds nearly 170 controls over SAQ A, mostly covering web security, patching, and access management for the pages involved.
A lot of contact centres land here accidentally because they embed a payment iframe into their own contact-us page or customer portal. If that's you, you're doing 170 extra controls you don't need to. Moving to a fully hosted payment page — or fully outsourced phone payments — gets you back down to SAQ A.
SAQ B / B-IP
41 controls (B) or 83 controls (B-IP). SAQ B applies if you only handle card data via dial-out terminals or physical imprint machines. B-IP is the equivalent for IP-connected terminals. Neither one is common for contact centres running phone payment operations — they're more for retail stores with physical card readers — but if you're a hybrid operation with a card terminal in your office as a fallback, you might find yourself needing to complete a B form alongside your main SAQ.
SAQ D
329 controls. The full self-assessment. SAQ D applies to any organisation that stores, processes, or transmits cardholder data and doesn't qualify for any of the simpler SAQs. Most contact centres that take card payments and don't have proper scope-reduction in place end up here by default. It covers every aspect of the PCI DSS standard — network security, encryption, access control, logging, monitoring, vulnerability management, incident response, documented policies, and regular testing. Completing a SAQ D honestly is a serious undertaking. Completing one and maintaining the controls it describes is even more serious.
The big decision
The practical choice for most contact centres is SAQ D or SAQ A. A-EP and B-IP are edge cases. If your current setup has card data reaching your agents or your recording platform in any form, you're in SAQ D territory. If you deploy proper scope reduction and your card data never touches your systems, you drop to SAQ A. The difference in ongoing compliance effort between those two is roughly 10-20x.
The real cost of non-compliance (for contact centres specifically)
Most of the published PCI DSS penalty numbers come from retail breach cases, which doesn't help contact centre managers model their own exposure. Here's what the real costs look like for a contact centre that fails to meet the standard.
PCI Security Standards Council penalties
Direct PCI penalties are levied by the card brands — Visa, Mastercard, Amex, Discover — not by the PCI Council itself. They range from $5,000 to $100,000 per month for non-compliance, and they're usually assessed after a breach is discovered. The exact number depends on which level of merchant you are, how long you've been non-compliant, and how cooperative you're being with the forensic investigation.
UK ICO and GDPR fines
If a UK contact centre suffers a breach involving personal data (and a card number is personal data under GDPR), the Information Commissioner's Office can fine you up to £17.5 million or 4% of global annual turnover, whichever is higher. ICO fines in the post-GDPR era have been trending upwards: British Airways received a £20 million fine for a 2018 skimming attack. Marriott received £18.4 million. Ticketmaster £1.25 million. For a UK contact centre, this is often the biggest financial risk, not the card brand penalties.
Card reissuance and customer notification
If your breach exposes card numbers, affected customers' cards have to be cancelled and reissued. The industry rule of thumb is around £3-5 per card for the issuing bank to reissue — but the bank bills that back to the merchant responsible for the breach. For a contact centre handling 50,000 active customer cards, that's £150,000-250,000 of direct cost, before any other damages.
Forensic investigation
After any suspected breach, card brands mandate a forensic investigation by a PCI Forensic Investigator (PFI). These cost £50,000-200,000 depending on scope, complexity, and how fast you're moving. The investigation is non-optional and the cost is entirely yours.
Legal, remediation, and brand damage
Add to all of that the legal costs of responding to regulatory inquiries, the remediation costs of fixing whatever caused the breach, the customer-service costs of handling complaints, and the revenue impact of lost customer trust. For contact centres that experienced a breach in 2024, average total recovery costs ran north of £3 million per incident across all these categories combined.
This is why contact centre boards that understand the numbers prioritise scope reduction. It's not just about audit hours — it's about taking a £3 million tail risk off the table.
How contact centres reduce scope in practice
This is the part most contact centre managers want to skip to. You've read the theory, you've seen the fines, now you want the playbook. Here's what works.
Step 1: Remove card data from the voice path
The single highest-impact action a contact centre can take is making sure card data never enters the agent's voice channel. This is what DTMF masking and channel separation are designed to do. The customer enters their card on their own keypad, the tones are intercepted before they reach the agent's headset, and the actual digits are routed directly to a PCI-certified payment processor. Your telephony estate drops out of scope immediately — not because the auditor takes your word for it, but because you can technically demonstrate that no card data ever crosses your voice infrastructure.
This single change is typically worth 60-70% of your total scope reduction. Everything that depends on your voice platform — recording systems, QA tools, supervisor dashboards — all of it comes out of scope in one move. Nothing else you can do has a comparable impact.
Step 2: Remove card data from agent workstations
If agents never see a card number on their screen — not in the CRM, not in the payment portal, not in any free-text field — the workstations drop out of scope. This is harder than it sounds, because contact centres have historically given agents a lot of payment visibility for "customer service reasons". PCI 4.0's Requirement 3.4.2 (PAN masking on display) is actually helpful here because it forces you to justify every screen that shows full card data. Most of those justifications don't hold up, and the screens get changed.
Combined with Step 1, this accounts for a further 15-20% of scope reduction.
Step 3: Stop storing card-linked data in the CRM
Tokenise. Every reputable payment gateway — Paytia included — returns a token after capture that stands in for the card number. The CRM stores the token, not the PAN. The token is useless to anyone who steals it because it's bound to your specific merchant account. When you need to charge the card again (for recurring billing or refunds), you pass the token back to the gateway, not the PAN.
Proper tokenisation gets most of your CRM, billing system, reporting tools, and data warehouse out of scope. That's another 5-10% scope reduction, and it's mostly automatic once Steps 1 and 2 are in place.
Step 4: Tighten what's left
After Steps 1-3, you'll have a very small remaining in-scope footprint — typically just the payment gateway integration itself, plus whatever minimal surface SAQ A requires. Harden those pieces properly: strong authentication, encrypted links, documented change control, quarterly scans if required. This is the lightweight compliance work the standard is actually designed for.
What NOT to do
Don't try to reduce scope by adding controls to an in-scope estate while leaving card data flowing through it. That's the expensive path: you end up paying for extensive segmentation, enterprise-grade logging, penetration testing on every asset, and detailed documentation on every system — and you're still in SAQ D territory because card data is still in your environment. The cheaper and safer move is always to remove the data first, then worry about controls on whatever's left.
Real contact centres that have done it
The following case studies are all real Paytia customers. The numbers are pulled from their published case studies. If you want the full stories, the links go straight to the case studies on our site.
Insure and Go: 75% PCI scope reduction across all locations
Insure and Go is a UK travel insurance specialist with phone-sales teams across multiple offices and a growing hybrid-working population. Before Paytia they were running under a full SAQ D with all the usual pain: in-scope telephony, in-scope recording, in-scope agent workstations. After deploying our common-capture service across every agent location, they achieved a 75% reduction in PCI compliance scope and enabled full work-location flexibility — agents could work from home without triggering the hybrid-working compliance concerns that usually come with that shift.
All Clear Travel: 75% scope reduction plus 45% processing cost savings
All Clear Travel is a travel insurance provider serving customers with pre-existing medical conditions. Phone sales are critical to their business because the nature of the conversation means customers often need to talk through their specific circumstances. The scope reduction result was identical to Insure and Go at 75%, but All Clear's deployment also unlocked a 45% reduction in payment processing costs during off-peak periods through Paytia's flexible licensing model — which charges based on active seats rather than total seats under the compliance umbrella. During quiet periods they simply need fewer seats, and the savings flow directly through.
CAS: card data eliminated from systems entirely
CAS, a business services provider, had PCI compliance as a direct barrier to expanding their phone-based payment offering. After implementing Paytia, all card data was eliminated from CAS systems, removing them from PCI DSS scope entirely. This let them expand their customer payment options to include both real-time telephone payments and customer-actionable payment links — something they couldn't have done within the compliance constraints of their old setup.
Pinnacle Group: housing management transformed
Pinnacle Group manages residential properties across the UK and handles rent and service charge collection over the phone. Their operations team reported faster collection cycles, less invoice chasing, and improved customer trust after deploying Paytia. The compliance result was a clean SAQ A deployment across all their telephony, but the operational wins were the story the board paid attention to.
Trinity Hall College: compliance without infrastructure overhaul
Trinity Hall College, a Cambridge educational institution, needed full PCI DSS compliance for their donor payment lines. Their internal IT team didn't have capacity for an infrastructure overhaul. Paytia let them achieve full compliance without significant IT changes — the card data was simply moved out of their environment, and everything else stayed as it was.
What the pattern looks like
The common thread across all of these is that the compliance outcome (75% scope reduction) isn't the headline for the customer — the operational improvements are. Faster calls, lower costs, better customer experience, less admin burden. The PCI work is a means to those ends, not an end in itself. Contact centres that have been sitting on PCI debt for years are usually surprised by how much operational flexibility returns once the compliance rope is off their operations.
Your 12-week implementation roadmap
Here's what a realistic contact centre PCI scope reduction programme looks like from kickoff to a signed SAQ A. This is the path we walk our customers through when we're engaged directly. It's deliberately not aggressive — you can go faster, but most contact centres have enough other priorities that twelve weeks is a comfortable timeline.
Weeks 1-2: Scoping workshop
Work with a QSA or a compliance specialist to map your current scope. The output of this phase is a document that lists every system currently handling or touching card data, what controls are on it today, and whether it would drop out of scope if card data were removed. Most contact centres find 2-3 systems they didn't realise were in scope.
Weeks 3-4: Technology selection
Decide how you're going to remove card data from the voice path. The main options are DTMF masking, channel separation, or third-party IVR (we covered all three in the DTMF pillar). Get demos, verify integration paths, check your existing telephony compatibility, and sign commercials.
Weeks 5-8: Integration and testing
The vendor integrates with your telephony, your payment gateway, and your CRM. We typically run this in parallel with your existing setup for a few days before cutover, so your QA team can listen to calls and verify that the masking (or channel separation) is working as expected. Agents get a brief training session on the new payment flow — usually 20 minutes per team, because the change on their side is minimal.
Weeks 9-10: Cutover and validation
Switch your phone payment flow to the new vendor. Paytia handles the cutover for you — you don't need a maintenance window or a weekend deployment. Verify a week's worth of calls going through cleanly, then have your compliance lead formally validate that card data is no longer reaching any previously-in-scope systems.
Weeks 11-12: Documentation and SAQ completion
The final phase is paperwork. Collect the attestation documents from your new vendor (Paytia provides this automatically), update your internal PCI scope document, complete SAQ A, and file the result. This is also when you update your internal training materials, your data flow diagrams, and your incident response runbook to reflect the new environment.
After week 12
You're on SAQ A ongoing. Your annual review (required by 4.0 Requirement 12.5.2) becomes a half-day task instead of a week. Your penetration tests narrow to just the remaining in-scope estate. Your vulnerability scans get smaller. Your audit prep gets shorter. Your compliance team gets their life back.
Frequently asked questions
Does my current phone system affect which path I should take?
Almost certainly not. The main phone payment security options — DTMF masking and channel separation — work with virtually any modern telephony platform. If you're on 3CX, Aircall, Avaya, Cisco, Amazon Connect, Genesys, Talkdesk, or any SIP-based platform, integration is straightforward. If you've got something older or more unusual, we can usually still work with it, but the discovery call is where we confirm.
Do I need a QSA to do this?
For scope reduction and implementation, no — the vendor (Paytia in our case) handles the technical side and provides the attestation documentation. For completing SAQ A itself, you can do it internally if you're confident in what you're attesting to. Larger organisations often still involve a QSA for the annual compliance review, even under SAQ A, because the QSA is looking at things like segmentation, policy coverage, and evidence of ongoing controls — not just the SAQ form itself.
How long does deployment actually take, really?
For a straightforward contact centre with standard telephony, we've done deployments in under a week from kickoff to live traffic. For complex multi-site operations with bespoke CRM integration, 4-6 weeks is more typical. We've never seen one take longer than 8 weeks — and most of the delay in longer deployments is internal project management on the customer side, not integration work on ours.
What happens to our existing call recordings?
Existing recordings that captured card data remain in scope until they're deleted or the data in them is purged. Most contact centres handle this by setting a tight retention period (usually 90 days, aligned with PCI DSS 3.1 requirements), letting old recordings age out, and having all new recordings taken after the scope reduction cutover. After the retention period passes, your recording system is fully out of scope.
Can remote agents use this?
Yes. Remote working is one of the strongest arguments for phone payment security — because when card data is handled by Paytia's infrastructure, your agents can work from anywhere without creating compliance risks. No more secure rooms, no more separate policies for remote agents, no more concern about home environments being audited. This was a major driver for Insure and Go and All Clear Travel's deployments, and it'll be a major driver for most contact centres going hybrid.
What about MOTO payments?
Mail Order / Telephone Order (MOTO) is exactly the use case DTMF masking and channel separation are designed for. Whether you're taking card-not-present payments by phone, mail order, or ordering via email, the same scope reduction applies. Our MOTO payments guide has more on the specific nuances.
What about PCI 4.0's new web integrity requirement?
Requirement 11.6.1 affects contact centres that also take payments through web forms. It requires you to monitor the form for unauthorised changes (to protect against skimming attacks). If your web payments are fully hosted by your payment provider, the requirement mostly falls on them. If you embed an iframe or handle the form yourself, you have some work to do. Our customised web checkout handles this for customers who need it.
Is there any scenario where full SAQ D is unavoidable?
Only if you genuinely need to store full PANs in your environment — for example, if you're building your own payment gateway or acquiring bank. For normal contact centre operations, there's no scenario where SAQ D is unavoidable. If a vendor is telling you otherwise, they're selling you the wrong solution.
What to do next
If you're reading this and realising your current setup probably isn't compliant, you're in the same position almost every contact centre manager we talk to is in on the first call. The answer isn't to panic — it's to book a scoping conversation and start mapping the gap between where you are and where SAQ A would put you. Usually that gap is bridgeable in under three months without disrupting your operations.
We offer a no-obligation scoping workshop where we'll look at your current telephony, recording, and payment setup, tell you honestly what's in scope today, and what it would take to get to SAQ A. If DTMF masking or channel separation isn't the right answer for your environment, we'll tell you that too — we'd rather you hear the honest answer from us than from a QSA three months into a deployment.
Book your discovery call through our product tour or get in touch directly via the contact page. Bring your operations lead and your compliance lead to the call — both perspectives matter, and you'll get a more useful conversation when both seats are at the table.
And if you'd rather read more first, we've got full depth on the underlying technology in our DTMF masking pillar, the full list of PCI DSS requirements in our requirements guide, and a walkthrough of what happens in a breach in our consequences of non-compliance post. Take your time. The compliance question doesn't usually have to be solved this week, but it does need to be solved before your next audit.
