13 PCI Call Center Compliance Requirements How-To Guide

Your PCI scope isn't where you think it is. If your voice stack touches cardholder data, every hop in that pipeline is in scope, and most call centers only find out during a QSA audit.

Most enterprise buyers in regulated industries assume that deploying any PCI-certified vendor automatically limits their CDE scope and satisfies DSS obligations for voice channels. In practice, most call centers draw their PCI DSS compliance boundary around a single moment: the point where an agent types a card number into a payment screen. Everything upstream of that keystroke — the voice platform carrying the call, the transcription pipeline processing the audio, and the routing infrastructure connecting the two — gets treated as out of scope. See our voice AI for PCI-compliant call centers guide for how this works in practice.

That assumption is wrong, and it is the most common reason compliance teams walk into a QSA assessment confident and walk out with a critical finding. Teams building or evaluating AI phone agent infrastructure for payment environments need this foundation before they can assess any vendor, any architecture, or any control. Cardholder data covers the Primary Account Number (PAN) and any data associated with it: cardholder name, expiration date, and service code.

Sensitive Authentication Data (SAD) adds full track data, CVV/CVC codes, and PINs. One key rule is that SAD must never be stored after authorization, even in encrypted form. On a voice channel, that rule creates a specific problem.

When a caller reads their card number aloud, any system that records or transcribes that audio has captured PAN. Any system that captures a CVV spoken aloud has captured SAD. Per guidance synthesized by RedSec Labs, a recording or transcript containing those values constitutes prohibited SAD storage and pulls the recording system directly into CDE scope, regardless of whether capturing that data was intentional. The Cardholder Data Environment is defined as any system component that stores, processes, or transmits cardholder data or SAD, plus any system connected to it.

Key takeaways#

• PCI DSS scope in call centers starts the moment a voice channel touches cardholder data, not when an agent types a card number into a payment screen.
• Most call centers draw their compliance boundary too late and too narrow, leaving the entire upstream voice stack — SIP trunks, IVR logic, AI layers — inside an unacknowledged CDE.
• The 13 PCI call center compliance requirements function as a dependency chain: treating them as independent checkboxes is exactly how scope keeps expanding during a QSA audit.
• A vendor's SOC 2 report and a signed BAA answer whether the vendor is certified, not whether their infrastructure touches your cardholder data, which is the question that determines your audit outcome.
• Every third-party hop cardholder data takes through a shared voice stack is a liability the DSS never accounts for on your behalf; it lands on your audit surface.
• Bland.ai's self-hosted architecture eliminates this category of risk entirely: Bland provisions its own GPUs, compresses and tunes models for fastest response, and co-locates the full voice stack on its own infrastructure so sensitive call data never leaves your environment.

Common PCI Compliance Challenges in Call Centers That Cause Audit Failures#

Audit findings in call centers rarely trace back to a single rogue agent. The structural failures that actually stop compliance programs in their tracks are architectural, and they compound silently between assessments. One of the most persistent struggles compliance teams face is accurately defining and understanding PCI DSS scope in the first place, an error that delays audits and multiplies remediation effort, especially in call centers where cardholder data environments can be complex and sprawling.

The common assumption is that deploying any PCI-certified vendor automatically limits the buyer's CDE scope and satisfies DSS obligations for voice channels. Only 43.4% of organizations maintained full PCI DSS compliance during interim assessments, which means most remediation efforts fail to hold. The reason recurs with striking consistency: teams fix the visible behavior and leave the infrastructure untouched.

Voice AI Transcription and CDE Expansion#

43.4% of organizations maintained full PCI DSS compliance during interim assessments

The moment a voice AI platform transcribes a call in real time, every system that touches that audio stream or transcript becomes a potential cardholder data environment node. This happens automatically, without any agent doing anything wrong. A regulated financial services team can pass its internal audit and then receive a QSA finding weeks later because its third-party transcription service was an unmapped CDE component, triggering a 90-day remediation cycle.

As SecurityMetrics' 2024 PCI DSS compliance guide confirms, any system that stores, processes, or transmits cardholder data is in scope regardless of whether the vendor handling it holds its own PCI certification. This is where the architectural design of a voice AI platform becomes a compliance variable, not just a product feature. Bland.ai's real-time transcription is included in the per-minute rate across every plan, meaning transcription is not a bolt-on third-party service introduced outside your vendor map, but a documented, in-platform capability.

For Enterprise deployments, compliance documentation is available under NDA, and dedicated infrastructure means the transcription pipeline does not traverse shared, unmapped infrastructure hops that silently expand CDE scope. The Enterprise plan also supports data residency controls and on-premises or VPC deployment, capabilities that directly address the architectural exposure that generic AI platforms leave open. On the Enterprise tier, Bland.ai's forward-deployed engineering team scopes, builds, and tests each deployment within a 30-day framework before go-live, which means CDE boundaries are mapped before the first live call, not discovered during a QSA assessment afterward.

Teams handling high call volumes or needing 24/7 phone coverage — exactly the environments where cardholder data exposure is most frequent and hardest to monitor — have used Bland.ai to scale outreach without scaling headcount. That capacity shift matters for compliance: when AI handles the volume, sentiment capture and call analysis happen across every call at scale, making it possible to detect scope-relevant patterns that a sampled human-review program would miss entirely.

The Pause-and-Resume Control Gap#

Pause-and-resume was designed for human agents who can manually trigger it. Voice AI platforms that process speech continuously have no equivalent native mechanism to detect and suppress a primary account number mid-conversation. Audio redaction requires active architectural intent, not a policy checkbox.

Teams that assume their AI call platform inherits the same controls as their legacy recording system are building compliance on a false foundation. Call centers consistently struggle to descope their systems from PCI assessments because even with third-party management, phone networks transmitting cardholder data remain in scope and create compliance complexity. This is not a policy gap; it is an infrastructure gap.

Bland.ai's Enterprise plan surfaces controls that address this at the architectural level: guardrails, custom code extraction, and a dedicated orchestration server give regulated teams the implementation surface to enforce suppression logic within the call flow itself, rather than relying on a post-processing policy applied after the PAN has already traversed the stack. For organizations already running Amazon Connect, Bland.ai integrates directly into existing Connect call flows, allowing AI agents to be substituted for or to augment human agents without migrating to a new platform, which means CDE scope changes are bounded to the integration point rather than requiring a full infrastructure re-map.

Third-Party Infrastructure Hops and DSS Liability#

A typical cloud voice stack introduces multiple third-party infrastructure hops, each one a potential CDE node that SecurityMetrics' 2024 PCI DSS compliance guide confirms falls in scope the moment cardholder data passes through it. Generic AI call platforms are architected for scale, not for regulated environments, and they rarely provide the infrastructure isolation or compliance documentation that a QSA requires to validate scope boundaries. Bland.ai's Enterprise plan offers dedicated infrastructure, on-prem and VPC deployment options, JWT signatures for secure webhook verification, and SSO, each a direct response to the infrastructure-hop liability that DSS assessments surface. Compliance documentation is available under NDA, so the evidence package a QSA needs is a defined deliverable, not a gap the team has to reconstruct under audit pressure.

The 13 PCI Call Center Compliance Requirements — Technical Controls, Agent Protocols, and Infrastructure Standards#

Thirteen requirements. One dependency chain. The compliance teams that treat them as independent checkboxes discover the problem only when a QSA starts mapping their data paths and the scope keeps expanding.

The flat-list mental model is understandable. PCI DSS v4.0 presents its requirements sequentially, and most internal audit frameworks assign each one to a different team owner: network security to IT, access control to IAM, training to HR. The assumption is that if every owner checks their box, the organization is compliant.

What that model misses is that Requirements 1 through 6 — the controls governing how cardholder data is captured, masked, and transmitted — are only enforceable if the voice infrastructure carrying that data sits inside a boundary you actually control. The 13 items below map each requirement to the infrastructure layer it governs. Read them that way, not as a checklist.

Vendor PCI Compliance Evaluation Checklist#

Use this checklist before signing any voice AI vendor contract. Each item maps to a DSS requirement that shared infrastructure cannot satisfy on your behalf.

#

Evaluation Question

DSS Requirement

Pass Criteria

1

Does audio containing spoken PANs transit the vendor's shared network at any point?

Req. 1, 4

Confirmed NO with network diagram

2

Where does real-time transcription occur, and who owns that compute?

Req. 3, 4

Dedicated or self-hosted compute only

3

Can the vendor produce a network diagram showing CHD never reaches multi-tenant infrastructure?

Req. 1, 9

Diagram produced in QSA-acceptable format

4

Does the vendor enforce MFA at session level for all agent access?

Req. 8

Yes, enforced at platform level

5

Can the vendor produce penetration test results covering all CDE-adjacent infrastructure?

Req. 11

Annual pen-test report available

6

Is a current AOC on file, and does it explicitly document shared-control boundaries?

Req. 12

AOC on file + written shared-responsibility matrix

7

Does the vendor provide DTMF suppression or equivalent PAN suppression that prevents CHD from entering the audio stream entirely?

Req. 3

Native suppression confirmed, not pause-and-resume only

Scoring: 7/7 required for reduced CDE scope. Any NO answer is a scoping risk that must be remediated before go-live.

1. Call Recording Redaction and Pause-Resume Controls#

PCI DSS prohibits storing sensitive authentication data post-authorization, making call recording controls a frontline compliance requirement. Pause-and-resume lets agents manually halt recording during card capture, but human error creates gaps: agents forget to resume or pause too late. Automated real-time redaction eliminates agent dependency entirely, making it the stronger choice for high-volume contact centers handling thousands of daily payment transactions.

2. Cardholder Data Environment (CDE) Scoping and Network Segmentation#

Defining the CDE boundary is the foundational step in PCI call center compliance: every system that stores, processes, or transmits cardholder data falls in scope. Proper network segmentation using firewalls, VLANs, or cloud-native controls isolates agent workstations from non-CDE systems, dramatically reducing audit scope. The tradeoff is architectural complexity: poorly documented segmentation is one of the most common QSA findings during assessments.

3. Tokenization of Primary Account Numbers (PANs) at Point of Capture#

Tokenization replaces the full PAN with a surrogate value the moment it enters the call center environment, ensuring agents and downstream systems never handle raw card data. This is the single most effective scope-reduction technique available to contact centers, removing entire system categories from PCI audit scope. The limitation is integration complexity: tokenization must connect cleanly with payment processors and CRM platforms without breaking existing agent workflows.

4. Screen Recording Governance and CHD Masking on Agent Desktops#

Screen recording systems in call centers can inadvertently capture cardholder data displayed on agent desktops, bringing those systems into PCI scope. Compliance requires either preventing CHD from appearing on recorded screens or implementing automatic masking of PAN fields. Displaying only the last four digits of a card number keeps screen recording out of scope, but organizations must verify through QSA review that no full PANs are ever rendered on captured screens.

5. Unique User ID Assignment and Shared Workstation Access Controls#

PCI DSS Requirement 8 mandates that every individual accessing CDE systems has a unique ID, making shared agent logins a direct compliance violation. In call center environments with hot-desking and shift rotations, enforcing unique credentials requires robust identity infrastructure, often including RFID badges, biometrics, or passwordless authentication. The operational tradeoff is login friction during high-turnover shifts, which organizations must balance against the non-negotiable audit requirement.

6. Sensitive Authentication Data (SAD) Non-Storage Policy Enforcement#

PCI DSS Requirement 3 absolutely prohibits storing CVV2 codes, full magnetic stripe data, or PINs after authorization, even in encrypted form. Call centers must implement technical controls that prevent agents from entering SAD into CRM notes, ticketing systems, or call logs. Policy alone is insufficient; organizations need data loss prevention (DLP) tools that detect and block SAD entry in real time, with regular audits confirming no historical SAD storage exists in any system.

7. Role-Based Access Control (RBAC) with Least-Privilege Enforcement#

PCI DSS requires that access to cardholder data is restricted to only those with a documented business need, making RBAC a core call center compliance control. Agents should access only the payment functions their role requires, with supervisors, QA teams, and IT staff having separately scoped permissions. The practical challenge in large contact centers is maintaining accurate role definitions as staff rotate between queues and responsibilities, requiring regular access reviews at least every six months.

8. Encryption of Cardholder Data in Transit Across Call Center Networks#

PCI DSS Requirement 4 mandates strong cryptography for all cardholder data transmitted over open or public networks, including VoIP streams, SIP trunks, and agent-to-processor connections. Call centers using cloud-based telephony must verify that their carrier and CCaaS platform encrypt media streams end-to-end using TLS 1.2 or higher. The tradeoff is that encrypted VoIP can complicate call quality monitoring and real-time analytics tools that require access to the media stream.

9. Multi-Factor Authentication (MFA) for Remote Agent CDE Access#

Image: PCI Call Center Compliance Requirements - multi factor authentication mfa

PCI DSS v4.0 expanded MFA requirements to cover all access into the CDE, including remote agents connecting via VPN or cloud desktop environments. For work-from-home call center agents, a segment that grew dramatically post-2020, MFA is now non-negotiable for any session touching payment systems. The operational friction of MFA prompts during high-call-volume periods is real, and organizations must choose authentication methods that balance security with agent productivity.

10. Vulnerability Management and Patch Cadence for Call Center Systems#

PCI DSS Requirements 5 and 6 mandate anti-malware protection and timely patching of all CDE systems, including agent workstations, telephony servers, and payment middleware. Call centers face a unique challenge: patching during business hours disrupts live agent operations, while delaying patches extends the vulnerability window. Organizations must implement a documented patch management policy with defined SLAs — critical patches within 30 days — and use maintenance windows that minimize agent downtime.

11. Audit Logging and Log Integrity Monitoring for Agent Payment Activity#

PCI DSS Requirement 10 requires comprehensive audit trails of all access to cardholder data, including agent login events, payment transaction records, and administrative actions on CDE systems. Logs must be protected from tampering, retained for at least 12 months with three months immediately available, and reviewed daily for anomalies. In high-volume call centers generating millions of log events daily, automated SIEM tools are essential; manual log review is neither practical nor sufficient for compliance.

12. Annual PCI DSS Security Awareness Training for Call Center Agents#

PCI DSS Requirement 12.6 mandates formal security awareness training for all personnel with access to cardholder data, delivered at hire and annually thereafter. For call centers with high agent turnover, often exceeding 30–40% annually, maintaining training completion records and ensuring new hires are trained before accessing payment systems is operationally demanding. Training must specifically cover social engineering risks, proper handling of card data, and the consequences of non-compliance to be considered adequate by QSAs.

13. Third-Party Service Provider (TPSP) PCI Compliance Validation and Contracts#

Call centers routinely rely on third-party vendors for CCaaS platforms, payment gateways, call recording, and CRM systems, each of which may touch cardholder data and require PCI compliance validation. PCI DSS Requirement 12.8 mandates written agreements with TPSPs acknowledging their responsibility for the security of shared cardholder data, plus annual confirmation of their PCI DSS compliance status. Organizations that assume vendor compliance without documented validation face direct liability during QSA assessments.

How to Evaluate Voice AI Vendors Against PCI Call Center Compliance Requirements#

Signing a BAA and collecting a vendor's SOC 2 report feels like due diligence. In practice, it answers the wrong question. The question that determines your audit outcome is not "is this vendor certified?"

Those are structurally different questions, and only one of them will satisfy a QSA. One pattern we see repeatedly among compliance and engineering teams building voice AI for call centers: the appeal of a tool that "scrubs card details so you don't have to deal with PCI compliance" is real, but the underlying infrastructure question never disappears; it just moves.

If the vendor's real-time transcription layer sits on shared compute, the CHD has already transited infrastructure you do not control, regardless of what the vendor's marketing says about compliance. This is the operational gap that surfaces mid-assessment and derails timelines.

Why Vendor Evaluation Must Start With a Data-Path Audit#

Vendors often cannot demonstrate live integrations with core banking or insurance systems such as CRM, ticketing and core transaction platforms, which raises concerns about the compliance audit trails and data handling required for PCI-compliant call center environments.

PCI DSS scope is determined by data flow and system connectivity, not by certification status (VikingCloud). Every node a spoken PAN digit touches — from IVR pickup through real-time transcription to LLM inference — independently enrolls your connected systems into the full set of DSS obligations. A vendor's AOC documents their own controls; it does not subtract a single line from your organization's control inventory.

That is the structural trap: a PCI-certified voice AI vendor's certificate is a scope-entry document, not a scope-reduction one. A compounding concern that compliance teams frequently raise: vendors often cannot demonstrate live integrations with core banking or insurance systems — CRM, ticketing, or core transaction platforms — at the time of vendor review. That gap matters not just for functionality but for audit trail completeness.

If your voice AI vendor cannot show, in a working integration, how call data flows into and out of your systems of record, your QSA will have no basis for evaluating whether that data path is controlled. Bland.ai's Integrations Platform and native Amazon Connect Integration address this directly: teams already running call operations on Amazon Connect can layer AI voice agents onto existing inbound and outbound call flows without migrating to a new platform, preserving the system-of-record connections, and therefore the audit trail, they have already built. That is not a minor convenience; it is what makes a data-path diagram producible at audit time rather than aspirational.

The Four Data-Path Questions Every Compliance Team Must Ask#

Before signing any voice AI contract, map the answer to each of these: (1) Does audio containing spoken PANs transit the vendor's shared network at any point? (2) Where does real-time transcription occur, and who owns that compute? (3) Can the vendor produce a network diagram showing your CHD never reaches multi-tenant infrastructure?

(4) Can they produce that diagram in a form your QSA will accept at audit time, not just on request? Teams that skip this exercise routinely discover mid-assessment that a vendor's shared GPU cluster has been in their CDE for months. On questions two and three, infrastructure architecture is decisive.

Bland.ai's Enterprise tier runs on dedicated infrastructure, on-premises or VPC deployment is available, and compliance documentation is available under NDA for teams that need it before contract signature. Real-time transcription and LLM inference are included in the per-minute rate with no separate token charges, meaning those compute layers are part of the contracted infrastructure envelope, not routed through a third-party shared cluster that sits outside your audit boundary. For organizations that need to stand up quickly, the forward-deployed engineering team ships the first agent within 30 days on a structured deployment framework — scope, build, gray/red/green-team test, and go live — giving compliance teams a defined timeline to work against rather than an open-ended integration risk.

Why Shared Infrastructure Creates Unresolvable Gaps Under Requirements 3, 4, 7, and 9#

Requirement 3 (protect stored cardholder data) and Requirement 4 (encrypt transmission) both assume you control the storage and transmission layer. On shared infrastructure, you do not. Requirement 7 (restrict access by business need) and Requirement 9 (restrict physical access) require logical and physical separation you cannot enforce on a multi-tenant platform.

Bland.ai's Enterprise tier is not a premium feature in this context; it is the architectural precondition for satisfying Requirements 7 and 9 at all. Without it, every access-control policy you write is an assertion about infrastructure you do not own, and a QSA reviewing your control inventory will note the gap (VikingCloud). The broader operational case matters here too.

High-volume call centers adopt AI voice precisely to scale outbound and inbound call operations without proportional headcount growth, and to ensure consistent application of service standards across every call, turning customer support from a pure cost center into a competitive differentiator. None of that operational value is realizable if the compliance architecture collapses under audit. The infrastructure question and the business case question are the same question, evaluated at different points in the procurement cycle.

Next steps#

If your voice AI deployment is quietly expanding your cardholder data environment before a single auditor asks a question, the path forward starts with keeping the entire voice stack inside infrastructure you own and can prove you control.

A vendor's AOC is a scope-entry document, not a scope-reduction certificate. Every shared-infrastructure hop cardholder audio takes independently enrolls your connected systems into the full DSS control inventory, regardless of what certification the vendor holds. Pause-and-resume and DTMF suppression compound the problem: they are procedural controls layered on top of an architecture that has not actually isolated cardholder data from your CDE, which means you are paying compensating-control audit overhead without eliminating the underlying data-path risk. Together, these two realities point to the same architectural answer: dedicated, self-hosted infrastructure where audio capture, real-time transcription, and LLM inference never traverse a network segment you cannot inspect or test.

Start by evaluating your current voice stack against the seven-question vendor checklist in this guide, then see our voice AI for PCI-compliant call centers guide, built for that infrastructure model. Enterprise deployments include dedicated infrastructure, on-premises or VPC options, and compliance documentation available under NDA before contract signature, giving your QSA a producible data-path diagram rather than a gap to document.

Frequently Asked Questions#

Does pause-and-resume actually keep my call recordings out of PCI scope?#

No. Pause-and-resume only interrupts recording; it does not remove cardholder data from your call center's data environment. If the audio stream passes through your infrastructure before the pause fires, the data has already entered your CDE and Requirement 3 still applies.

If my vendor is PCI-certified, does that mean my call center is automatically compliant?#

No. PCI DSS scope is determined by what your infrastructure touches, not your vendor's certification status. Any system that stores, processes, or transmits cardholder data is in scope regardless of whether the vendor handling it holds its own PCI certification, and a vendor's Attestation of Compliance covering their data center does not automatically cover the data path between their infrastructure and yours.

How does real-time voice transcription expand my cardholder data environment?#

The moment a voice AI platform transcribes a call in real time, every system that touches that audio stream or transcript becomes a potential CDE node, automatically, without any agent error. A third-party transcription service that is unmapped in your vendor documentation can trigger a QSA finding and a 90-day remediation cycle even if your internal audit passed cleanly.

What does PCI DSS v4.0 require for call center agents working from home?#

PCI DSS v4.0 expanded mandatory multi-factor authentication to cover all access to the CDE, including remote agents connecting from home networks; this is not optional. Any voice AI platform or CCaaS tool that allows shared agent credentials or does not enforce MFA at the session level introduces a Requirement 8 finding, and shared login credentials used as a workaround in high-turnover environments fail this requirement outright.

What logging and monitoring does PCI DSS actually require for a high-volume call center?#

Every access to cardholder data must be logged, those logs must be protected from modification, and they must be reviewed regularly across every CDE component, including the voice infrastructure, not just the network perimeter. Manual review is not operationally realistic at scale, so automated SIEM tooling is the standard approach, and the SIEM must ingest logs from all CDE components simultaneously.