PCI compliance gets complicated in a call center because card data can pass through far more than a payment system. If a customer reads a card number aloud, the call path, agent environment, recording platform, and connected systems may all fall within PCI DSS scope. Being “on the phone” does not create an exemption. PCI SSC explicitly states that VoIP carrying payment account data is in scope wherever an organization controls the systems and networks that store, process, or transmit it.
That makes keeping card data out of the call center environment in the first place one of the most effective ways to reduce PCI scope.
In practice, that comes down to four things: keep card data away from human agents with DTMF masking or an AI agent, tokenize it before it reaches your CRM, keep it out of call recordings, and get a current Attestation of Compliance (AOC) from every provider that handles it. Below, we cover each one, what PCI DSS v4.0.1 requires, and how merchant levels and audits work.
Is Your Call Center in Scope for PCI DSS?
A call center is in PCI DSS scope when its people, processes, or technology store, process, or transmit payment account data, or can affect the security of the environment that does. If an agent hears a customer read out a card number and enters it into a payment system, taking the payment by phone does not create an exemption from PCI DSS.
The scope also extends beyond the call recording. Depending on the call and payment architecture, it can include:
- Agent systems – workstations, payment applications, softphones, or other systems that handle card data or can connect to the cardholder data environment.
- Telephony infrastructure – PBXs, session border controllers, call-routing systems, and other components that process or transmit calls containing payment account data.
- VoIP networks – PCI SSC explicitly states that VoIP traffic containing account data is in scope while it travels through infrastructure controlled by the organization, just like other IP traffic carrying account data. The external telephone network outside the organization's control is treated differently.
- Recording systems – any platform that records or stores cardholder data is in scope. A recording is therefore one potential exposure point, not the boundary of PCI scope.
- Connected systems and networks – systems that can connect to or affect the security of the cardholder data environment can also be in scope, even if they do not directly store card numbers.
Network segmentation can shrink that boundary, but simply placing payment systems on a different network segment does not automatically make everything else out of scope. PCI SSC allows technologies such as firewalls, strong access-control lists, VLANs, and other logical or physical controls, but the segmentation must actually prevent out-of-scope systems from accessing or affecting the cardholder data environment and must be validated as effective.
PCI scope follows the card data path, so the way to shrink it is to stop card data entering systems that don't need it, not only to remove it from recordings afterward.
Which Controls Actually Remove Card Data From Scope?
DTMF masking can prevent card data from reaching agents and parts of the call center infrastructure, while pause-and-resume and post-call redaction primarily keep card data out of stored recordings.
Pause-and-resume has a limited scope effect. PCI SSC guidance states that properly implemented pause-and-resume can help keep payment data out of recordings, but it does not remove the agent, desktop, or telephone systems from scope when they still handle the data.
DTMF masking can go further. If callers enter card details through the keypad and the payment digits are securely diverted to a PCI-compliant payment provider before reaching the agent, desktop, recording system, or relevant telephony infrastructure, those components may be removed from the card-data path. The exact scope reduction depends on the architecture and must be validated rather than assumed.
Post-call redaction is weaker from a scoping perspective because the data has already entered the environment before it is removed.
Here’s how they compare at a glance:
There is also one non-negotiable rule: sensitive authentication data such as CVV/CVC/CID values, full track data, and PIN/PIN-block data cannot be stored after authorization under PCI DSS Requirement 3.3.1.
The important distinction is that capture-side controls can reduce PCI scope, while recording controls mainly reduce stored exposure.
How Do You Reduce PCI Scope in a Call Center?
Reducing PCI scope means limiting how many people and systems ever receive card data. For call centers, there are two main opportunities to do that:
- Keep card data out of the human-agent environment: Payment details can be diverted to a dedicated payment service through controls such as DTMF masking, or the payment interaction can be handled within a PCI-compliant automated environment. If human agents never hear, see, enter, or record the PAN, their workstations and surrounding systems may be excluded from the card-data path. However, handing over to an AI agent does not make PCI DSS disappear. Any AI or telephony system that actually stores, processes, or transmits account data remains subject to applicable PCI DSS requirements.
- Tokenize card data before it reaches downstream systems: A payment provider can replace the PAN with a token that applications such as a CRM can use without storing the original card number. PCI SSC states that properly implemented tokenization can reduce the number of systems in scope when token-only systems are adequately isolated and cannot retrieve the PAN. The tokenization system itself remains in scope.
Synthflow, a conversational AI platform, reduces the PCI scope of the human-agent environment by letting AI agents handle eligible payment interactions, so card data never reaches a human agent's ears, screen or notes on those calls. Synthflow is compliant with PCI DSS v4.0.1 and operates its own telephony infrastructure, including Session Border Controllers (SBCs) and media servers, giving it direct control over call routing, capacity, and media handling within its telephony stack.
That infrastructure does not automatically remove a customer's PCI obligations. The actual scope depends on the complete payment flow, integrations, recordings, and which systems can access card data.
The deepest scope reduction comes from combining both approaches: keep PAN out of unnecessary call-center systems at capture time, then use tokens instead of PAN wherever downstream workflows do not need the original card number.
What Changed for Call Centers in PCI DSS v4.0.1?
PCI DSS v4.0.1 is the only active version of PCI DSS, and all requirements that were initially future-dated under PCI DSS v4.x have been mandatory since March 31, 2025. PCI DSS v4.0.1 itself was a limited revision and did not introduce new requirements beyond v4.0.
For call centers that handle card data, several requirements have a direct operational impact:
- MFA is required for all access into the cardholder data environment: Requirement 8.4.2 requires multi-factor authentication for all non-console access into the CDE, not just administrator or remote access. Synthflow supports workspace 2FA and offers SSO for Enterprise customers, although each organization remains responsible for configuring access appropriately for its PCI environment.
- PCI scope must be reviewed at least annually: Requirement 12.5.2 requires organizations to document and confirm their PCI DSS scope at least once every 12 months and after significant changes. Service providers have an additional Requirement 12.5.2.1 to perform this confirmation at least every six months and after significant changes.
- Sensitive authentication data still cannot be stored after authorization: Requirement 3.3.1 prohibits retaining data such as CVV/CVC/CID, full track data, and PIN/PIN-block data after authorization, even when encrypted. PCI SSC specifically says organizations should prevent this information from entering call recordings wherever possible.
The bigger change for call centers is that PCI compliance must be maintained continuously as payment flows, agents, telephony infrastructure, and integrations change, rather than treated as a once-a-year assessment exercise.
How Do PCI Compliance Levels and Audits Work?
PCI compliance levels sort merchants into four tiers by annual card transaction volume, and the tier decides how compliance is proven: Level 1 merchants need an annual Report on Compliance (ROC), while most others complete a Self-Assessment Questionnaire (SAQ).
The validation process usually follows two paths:
- Self-assessment: Eligible merchants complete the Self-Assessment Questionnaire (SAQ) that matches their payment environment. Each SAQ has specific eligibility criteria, and every criterion must be met.
- Formal assessment: Organizations required to complete a Report on Compliance (ROC) undergo a more detailed PCI DSS assessment. A QSA is a PCI SSC-qualified professional who can independently assess an organization's controls against PCI DSS.
Transaction volume often affects which route applies. Visa and Mastercard both use four merchant levels based primarily on annual transaction volume, although their exact boundary wording and validation rules can differ slightly. The higher the level of transaction volume, the more formal the validation process generally becomes:
- Level 1 – generally more than six million transactions per year. Merchants complete an annual PCI DSS assessment documented in a ROC.
- Level 2 – generally more than one million and up to six million transactions. The standard validation route is an annual SAQ, although additional assessor involvement may apply.
- Level 3 – generally more than 20,000 and up to one million e-commerce transactions annually. The standard validation route is an SAQ.
- Level 4 – merchants that do not meet the criteria for Levels 1, 2, or 3. These merchants must still comply with PCI DSS, even when the validation requirements are lighter.
These thresholds should not be treated as universal rules for every card brand. Your acquirer determines which validation program and reporting requirements apply to your business. Additionally, an outsourced call center that handles account data on behalf of merchants may instead be treated as a PCI service provider, which follows separate validation rules.
For call centers acting as merchants, SAQ eligibility depends heavily on where card data goes. A mail-order/telephone-order (MOTO) merchant may qualify for SAQ A when all account-data functions are completely outsourced to PCI DSS-compliant third-party service providers, the merchant does not electronically store, process, or transmit account data on its own systems or premises, and any account data it retains is limited to paper reports or receipts. Each SAQ has its own eligibility criteria, and all applicable criteria must be met. If an SAQ-eligible merchant does not qualify for a more specific questionnaire, SAQ D is generally the applicable SAQ.
Outsourcing payment handling can reduce assessment scope, but the merchant still has to verify its providers' PCI compliance and understand which responsibilities remain its own.
What Do Remote and AI Agents Change?
Remote agents can expand PCI exposure by moving card-data handling into home environments, while AI agents can reduce human exposure when payment interactions stay inside a properly designed PCI-compliant system.
For remote agents, PCI DSS follows the systems and account data they access. A private home is not automatically a PCI DSS “sensitive area,” but organizations still need controls for remote payment work. PCI SSC recommends company-authorized devices, secured endpoints, protected connections from home networks, screen locking, controls over paper records, and policies that prohibit unauthorized copying or local storage of account data. Connections from a home network into the cardholder data environment must also use MFA.
Organizations also need written policies, security awareness, and processes for confirming that remote employees follow those controls. PCI SSC does not require assessors to visit employees’ homes, but the organization must be able to demonstrate that its remote-work controls continue to protect account data.
Common call center PCI mistakes include:
- Assuming pause-and-resume removes the agent and telephony environment from scope. It does not.
- Failing to properly segment systems that should remain outside the cardholder data environment.
- Storing CVV/CVC/CID or other sensitive authentication data after authorization.
- Failing to monitor a payment provider’s PCI status at least annually and understand which PCI responsibilities the provider handles.
Synthflow AI agents remove several of the remote-human-agent risks from the portion of the interaction they handle. Synthflow agents can operate according to defined conversation logic and approved knowledge sources. When a Synthflow AI agent handles the payment portion of a call, no employee takes that step from a home workstation, so risks from handwritten notes, whiteboards, personal phones, and home networks don't apply to it.
What Should You Look for in a PCI Provider?
A PCI provider should be able to prove that its current PCI DSS assessment covers the specific services you use, clearly document which controls it owns, and show where your responsibilities begin. A generic “PCI compliant” badge is not enough.
Before choosing a call center, payment, or voice provider, verify:
- Current PCI evidence: Ask for the provider’s Attestation of Compliance (AOC) and confirm that it covers the services you plan to use. PCI SSC expects assessed third-party service providers to provide an applicable AOC to customers upon request. You can also request relevant sections of the ROC when additional detail is needed.
- Assessment scope: Check exactly which products, infrastructure, locations, and services were included. A provider can be PCI compliant while a particular service you use sits outside its assessed scope.
- Clear shared responsibilities: The provider should identify which PCI DSS requirements it handles and which remain yours. PCI DSS Requirements 12.9.1 and 12.9.2 require service providers to communicate these responsibilities to customers.
- Ongoing validation: PCI DSS Requirement 12.8 requires organizations to perform due diligence, maintain appropriate agreements, and monitor relevant providers’ PCI compliance status at least annually. Outsourcing payment handling does not outsource this responsibility.
- Broader security controls: Review access controls, encryption, auditability, subprocessors, and any additional frameworks relevant to your organization. Data residency should also match your requirements.
Synthflow publishes its compliance resources through its Trust Center and currently lists PCI DSS v4.0.1, ISO 27001:2022, SOC 2, HIPAA, and GDPR among its compliance programs. Synthflow also offers dedicated US and EU clusters that keep both storage and processing within the selected region.
What Are the Penalties for PCI Non-Compliance?
PCI non-compliance penalties are fees and assessments that acquiring banks and card brands pass on to merchants under their contracts, not fines issued by the PCI SSC. That means there is no universal PCI fine schedule that applies to every call center or merchant.
Acquirers may pass non-compliance assessments or fees on to merchants, and those amounts can increase when non-compliance continues. Industry sources commonly cite monthly charges beginning in the thousands of dollars and potentially rising into tens of thousands, but these ranges are not defined by PCI DSS itself and vary by agreement, merchant profile, payment brand, and severity.
The larger financial risk is usually a data breach. Costs can include card-brand assessments, issuer reimbursements, forensic investigations, legal expenses, customer claims, remediation, and increased processing costs.
For a call center, the goal is to reduce the amount of card data exposed to people and systems so a compromise is less likely and its potential impact is smaller.
Run PCI-Compliant Voice Interactions With Synthflow
Reducing PCI risk in a call center starts by keeping card data away from unnecessary people, recordings, workstations, and downstream systems. Controls such as secure payment capture, tokenization, segmentation, restricted storage, and carefully scoped third-party services can substantially reduce the environment that has to meet PCI DSS requirements.
Synthflow is a conversational AI platform built on PCI DSS v4.0.1-compliant infrastructure, so financial services and other regulated teams can automate sensitive voice interactions without building the underlying voice stack from scratch. The same infrastructure runs Synthflow's AI IVR, and its owned telephony gives Synthflow direct control over how calls are routed and connected.
Talk to Synthflow today to build PCI-compliant voice workflows that automate customer interactions while minimizing unnecessary exposure to card data.
Frequently Asked Questions
Does Pause-and-Resume Make a Call Center PCI Compliant?
No. Pause-and-resume can prevent card data from being stored in a call recording, but it does not remove the agent, workstation, telephony systems, or VoIP path from PCI scope if they still handle the card data. It is a recording control, not a complete PCI compliance solution.
What Is the Official PCI Guidance for Card Payments Over the Phone?
PCI SSC's main telephone-payment guidance is Protecting Telephone-Based Payment Card Data, Version 3.0, published in November 2018. It explains how PCI DSS applies to telephone and VoIP payment environments, recordings, agents, payment technologies, and scope reduction. The supplement remains guidance rather than a replacement for PCI DSS requirements.
How Much Does PCI Non-Compliance Cost a Small Call Center?
There is no universal PCI non-compliance fine for a small call center. PCI SSC does not impose fines. Payment brands and acquiring banks determine financial or operational consequences, which can vary by agreement and circumstances. A data compromise can also create additional costs such as investigations, remediation, legal claims, and increased payment-processing expenses.
