Home / Blog / PCI Compliance in a Call Center: Where Card Data Actually Leaks

PCI Compliance in a Call Center: Where Card Data Actually Leaks

PCI Compliance in a Call Center: Where Card Data Actually Leaks

Taking payments by phone pulls your contact center into PCI DSS scope. What that covers, the three approaches to descoping, and the gaps that survive an otherwise clean setup.

Reading a card number aloud puts you in scope

The moment a customer reads a card number to an agent, your contact center is handling cardholder data and falls within PCI DSS scope. That applies to the agent, the desktop, the network, the phone system and — the part most often missed — the call recording. It applies whether the agent is in your building or a provider's, and whether they are on a floor or at home.

Being in scope is not a problem in itself. Being in scope without knowing where the data goes is.

The three ways to reduce scope

  • Pause-and-resume recording. Recording stops while card details are spoken. Simple to implement and the weakest option, because it depends on the agent or the system pausing reliably every time, and the agent still hears and could write down the number.
  • DTMF masking. The customer types their card into the keypad; tones are suppressed or replaced so neither the agent nor the recording captures them. The agent stays on the line throughout, which preserves the experience.
  • Full descoping. Payment is handled entirely outside the agent environment — a secure link, an IVR payment flow, or a redirect — so cardholder data never touches your systems or the provider's at all.

Scope reduction is worth pursuing on its own merits: every system removed from scope is a system that no longer has to be assessed, hardened and audited annually.

Reviewing where cardholder data flows through a contact center
Trace the path a card number takes. The gap is usually somewhere nobody has drawn.

Where it leaks in practice

Almost never in the place the diagram covers. The recurring gaps:

  • Recordings. Pause-and-resume that fails silently, or an archive of historical recordings from before masking was introduced that nobody has dealt with.
  • Agent notes. A free-text field in the CRM where somebody typed a card number to finish the call. This survives every technical control you have.
  • Chat and email. Customers send card details unprompted. If nothing detects and redacts them, they sit in a ticket system indefinitely.
  • Screen sharing and remote support. A support session where the agent sees the customer's payment page.
  • Home working. A clean-desk policy is not enforceable in someone's spare room, which is precisely why DTMF masking matters more in distributed models.

What to ask a provider

Ask for their current Attestation of Compliance and check what it actually covers — an AOC for one facility says nothing about the delivery centre your program will run in. Ask which of the three approaches above they use, what happens to historical recordings, how free-text fields are monitored for card data, and how home-based agents are handled. Then trace one payment end to end and look for the step nobody has drawn on the diagram.

This describes how programs are commonly structured and is not compliance advice. Confirm your obligations with your acquirer and your qualified security assessor.

See our fraud and security capabilities, or read about the infrastructure behind client programs.

Recordings are the most common place scope leaks

An operation can handle payments carefully in real time and still fail, because the recording captured what the agent did not retain. Sensitive authentication data — the security code on the back of the card — must not be stored after authorisation under any circumstances, and a call recording that captures it read aloud is storage.

Pause-and-resume is the usual control, and its weaknesses are worth knowing. Manual pausing depends on an agent remembering under pressure, and the failure is silent. Automated pause triggered by screen context is more reliable but fails when the agent works out of order. Either way the mitigation is to verify rather than assume: sample recordings specifically for captured card data, and treat any instance as an incident with a root cause rather than as an agent error. Screen recording deserves the same attention and is more often forgotten. And where recordings are stored by a provider, the obligation and the retention rule follow the data — ask where they sit, who can retrieve them and when they are destroyed.

Controlling PCI scope in call recordings and agent screens
Pause-and-resume is a control to be verified, not assumed. Sample recordings specifically for captured card data.

Home-based and hybrid agents change the assessment

Much of the traditional control set assumes a supervised floor: no phones, no paper, no unauthorised observers, controlled network. Remote delivery removes most of those physical assumptions, and the response cannot simply be to trust the agent.

The controls that substitute are a mix of technical and procedural. Keep card data off the agent's environment entirely wherever possible, which makes the workspace largely irrelevant — this is the strongest answer. Where that is not possible, address the workspace explicitly: a documented policy on privacy of the working area, absence of recording devices, and no household members within earshot; endpoint controls covering clipboard, screenshots, local storage and split tunnelling; and identity assurance strong enough that you know who is at the keyboard. If a provider offers home-based delivery for payment-taking work, ask precisely how each of these is enforced and evidenced rather than whether they have a policy.

Sharing responsibility with your provider, in writing

Outsourcing payment-adjacent work does not transfer your obligation, and the most common gap is not a technical control but an unclear boundary. Both parties assume the other covers something, and the assessment finds it uncovered.

Produce a written responsibility matrix rather than relying on the provider's compliance certificate. Attestation of compliance evidence tells you the provider's own environment was assessed; it does not tell you which controls they operate on your behalf, which remain yours, and which are shared. Name each control, name the owner, and record how it is evidenced. Then keep it current: attestations expire, scope changes when a provider adds a channel or a delivery site, and subcontracting introduces parties you never assessed. Require notification of material changes, and re-review annually rather than at renewal. Our SLA guide covers where these obligations sit in the contract.

Frequently asked questions

Does pause-and-resume make us compliant?

It reduces scope and does not, on its own, make an operation compliant. Two weaknesses matter: it depends on the pause triggering reliably on every call, and a silent failure is invisible until an audit finds card numbers in an archive; and the agent still hears the number, so the human control remains. It is a reasonable step and a poor destination. DTMF masking or full descoping addresses both weaknesses and is where most serious programs end up.

Can home-based agents take card payments?

Yes, and it is common, but it changes which controls you can rely on. You cannot enforce a clean desk in someone's home, and you cannot be certain who else is in the room, so controls that depend on the physical environment stop being credible. That is exactly why distributed programs lean on DTMF masking or full descoping — if the agent never sees or hears the number, the environment matters much less. Confirm the arrangement with your assessor.

What about card details customers put in chat or email?

This is one of the most common gaps and it is entirely customer-generated, which is why technical controls on the voice channel miss it. Customers paste card numbers into chat windows and email replies unprompted, and without automated detection and redaction those sit in a ticketing system indefinitely, fully in scope and usually forgotten. You need detection on inbound text channels and a documented process for what happens when it fires.

Is a provider's PCI certification enough?

It is necessary and it is not the whole answer, for two reasons. First, check what the attestation actually covers — the entity, the facilities and the services in scope — because an AOC covering one delivery centre says nothing about the one your program will run in. Second, compliance is shared: your own systems, integrations and processes remain yours. A provider's certificate does not cover the CRM field your agents type into.

Build an outsourcing plan around your customers, operations, and growth goals.