Payment compliance field guide

PCI DSS Call Recording: Keep Payment Card Data Out of Audio

Map the complete voice and recording path, prevent sensitive authentication data from being retained, and test every payment-call fallback.

Published Updated 8 minute read Primary sources reviewed
Telephone payment flow separating card entry from governed call recording and review

Signal path

Payment callCard-data exclusionSafe recording

Where call-recording.com intervenes

From technical requirement to working recording

Call Observe provides access, audit, retention, encryption, and delivery controls for recordings that are approved to retain; the customer must prevent prohibited payment data from entering audio and derived records.

Short answer

The safest way to handle payment calls is to prevent payment-card data from entering the recording, transcript, notes, logs, and analytics. Do not rely on a long retention policy or ordinary access control to make stored card verification codes acceptable.

PCI DSS prohibits storing sensitive authentication data after authorization, even when it is encrypted. For telephone payments, use a validated process such as pause and resume, DTMF masking or suppression, secure payment capture, or reliable redaction so prohibited data is not retained.

Call Observe from call-recording.com can support a governed Cisco recording workflow, but the customer must design and validate the payment boundary. A call recorder alone does not make a card-payment environment PCI DSS compliant.

Which payment data creates the highest recording risk?

Payment calls can expose:

  • the primary account number (PAN);
  • cardholder name and expiry date;
  • service codes or other cardholder data; and
  • sensitive authentication data such as the card verification code or PIN data.

The PCI Security Standards Council's current telephone-recording FAQ says sensitive authentication data must not be stored after authorization. If audio contains it, the data must be removed or made unrecoverable after authorization. Encryption by itself does not make that storage permitted.

Are telephone and VoIP systems in PCI scope?

PCI scope follows the way account data is captured, transmitted, processed, and stored. The PCI SSC's VoIP scope FAQ explains that systems using VoIP to transmit payment-card data can be in scope.

For a Cisco deployment, map the complete path:

  • phone, soft client, contact-center desktop, and agent headset;
  • CUCM, CUBE, gateway, carrier, and media services;
  • recording server and local spool;
  • cloud storage, transcript, analytics, and search index;
  • support tools, monitoring, backups, and exports; and
  • payment application and service provider.

The goal is to reduce this scope by moving card entry into an approved payment channel that does not expose the account data to the agent or recorder.

Which control pattern should be used?

Choose a pattern that works for the real call flow and can be tested.

Secure DTMF payment capture

The caller enters card data using the telephone keypad while an approved payment service captures the digits. The agent and recording should receive masked information or approved tones, not the card data. Test every codec, gateway, transfer, conference, and fallback path.

Pause and resume

The recorder pauses before the customer speaks or enters card data and resumes only after the payment step. Manual pause depends on agent behavior and is easier to fail. Automated pause tied to the payment workflow is more repeatable, but still needs negative tests for abandoned payments, retries, transfers, and application outages.

Redaction or secure deletion

If a recording unexpectedly captures prohibited data, the response must render it unrecoverable or securely delete the affected record according to the approved incident process. A beep over a playback copy is not proof that the original audio, transcript, index, backup, or export no longer contains the data.

What about PAN in a recording?

Cardholder data that is permitted to be stored still has to be protected under the applicable PCI DSS v4.0.1 requirements. That includes scope, access, authentication, logging, network security, vulnerability management, testing, service providers, and retention.

Do not retain a full PAN in searchable metadata or a transcript merely because the audio is access-controlled. Mask displays as required, restrict retrieval, keep only what the approved purpose needs, and delete it when the purpose ends.

Why transcripts and AI need the same test

Speech-to-text can copy a spoken card number or verification code into a transcript. Search indexes, summaries, prompts, model logs, evaluation datasets, and exports can then create more regulated copies than the source recording.

If the audio is paused, confirm that transcription and analytics are also excluded for the payment segment. If redaction is used, prove it applies before downstream processing and cannot be bypassed by replaying an unredacted source.

How does Call Observe fit?

Call Observe provides organization-scoped access, authenticated playback, audit history, retention controls, encrypted storage, customer-hosted Cisco capture, and visible recording delivery for supported paths. These are useful protections for recordings that the approved workflow allows the platform to retain.

The payment design must still prevent prohibited authentication data from entering that workflow. Document whether payment controls are supplied by the contact center, payment provider, agent desktop, recorder, or a combination. Confirm the actual capability before production rather than assuming that a generic “PCI mode” exists.

Payment-call acceptance checklist

  1. Map every point where PAN or sensitive authentication data can be spoken, typed, displayed, logged, or exported.
  2. Move card entry to an approved secure payment channel where practical.
  3. Prove the recording, transcript, analytics, and search workflow exclude the payment segment.
  4. Test inbound and outbound calls, transfers, conferences, callbacks, mobile agents, payment retries, and failure fallbacks.
  5. Confirm that agents cannot bypass the approved path or resume recording early.
  6. Restrict and log access to any permitted retained cardholder data.
  7. Set the shortest justified retention and verify deletion from all copies.
  8. Define incident handling for unexpected card data and test secure removal.
  9. Include the voice and recording components in the PCI scope assessment with a qualified adviser where required.

Bottom line

For PCI DSS call recording, prevention is stronger than cleanup. Keep card verification codes and other prohibited data out of audio and every derived record. Treat VoIP, recording, transcription, search, exports, and service providers as one data path.

Call Observe can govern the recordings that are safe and approved to retain. The customer remains responsible for its PCI scope, payment design, service providers, configuration, testing, and compliance assessment.

Where call-recording.com intervenes

From technical requirement to working recording

Call Observe provides access, audit, retention, encryption, and delivery controls for recordings that are approved to retain; the customer must prevent prohibited payment data from entering audio and derived records.

Source ledger

Primary references and technical evidence

Validate version-specific commands, legal scope, and policy decisions against the current source applicable to your environment.

Legal and compliance content is general information, not legal advice. Cisco behavior and commands vary by product release, platform, firmware, and call flow.