PCI DSS for VoIP Phone Payments UK: Scope & Recording

What Does PCI DSS Mean for VoIP Phone Payments?

PCI DSS can apply to a business telephone environment when payment-card account data is stored, processed or transmitted through it. That includes VoIP audio and supporting systems where card numbers or other account data pass through infrastructure the business controls. The relevant scope follows the actual data path, not a provider’s label of “cloud”, “secure” or “PCI-ready”.

For a UK organisation taking payment by phone, the useful first step is to identify who can hear, see, record, transmit, store or retrieve card information during each payment. Then identify controls that stop it reaching unnecessary systems and ask the acquiring bank or appropriate PCI assessor to confirm the applicable validation approach. PCI SSC FAQ 1153 explains how PCI DSS applies to VoIP.

Map Every System a Telephone Payment Touches

Most scoping mistakes begin with a diagram that stops at the PBX. A real telephone payment can pass through a carrier, hosted calling service, agent headset, browser softphone, recorder, speech analytics, CRM notes and payment gateway. Whether each component is in scope depends on what it actually handles, can access or can affect.

PCI DSS telephone payment data flow

Draw a second diagram for the proposed protected route and show where account data bypasses the business or becomes inaccessible. A diagram is only evidence when supported by configurations, contracts and acceptance tests.

Swipe inside the table to see all columns.

Where Does VoIP Enter PCI DSS Scope?

PCI SSC explains that voice traffic containing payment account data is considered for PCI DSS wherever it is stored, processed or transmitted within the organisation’s controlled environment. The external segment of an incoming call that the merchant cannot control is treated differently from its own internal network. This is a control-boundary distinction, not an exemption for hosted calling.

Swipe inside the table to see all columns.

PAN, Cardholder Data and CVV: What Must Never Be Confused

Different data elements carry different rules. A primary account number (PAN) is cardholder data. Sensitive authentication data (SAD) includes card verification codes and values such as CVV2/CVC2/CID. PCI DSS Requirement 3.3.1 prohibits storage of SAD after authorisation even if encrypted. A stored audio file can violate this requirement just as a database can.

Swipe inside the table to see all columns.

Compare Telephone Payment-Capture Options by Data Exposure

The right question is not “Which technology is PCI certified?” but “Which systems can obtain the card data, under the deployed configuration and failure conditions?” The following is a planning comparison, not an assessment outcome. Actual PCI scope and validation depend on implementation, evidence and acquirer/assessor confirmation.

Swipe inside the table to see all columns.

What DTMF Masking and Secure Payment IVR Actually Need to Prove

DTMF (dual-tone multi-frequency) is the keypad signalling used when a caller presses digits. A masked-payment service can intercept or suppress usable keypad data before it reaches an agent or recording platform. An IVR can instead direct the caller to a payment-processing function. The products are not interchangeable, and simply muting a headset may not protect the media stream or stored recording.

Swipe inside the table to see all columns.

Why Pausing Call Recording Is Not Full PCI De-scoping

Pause-and-resume aims to stop payment information being captured in stored audio. PCI SSC’s telephone-payment information supplement explains that a properly implemented pause feature may reduce requirements applicable to the recording and storage system, but does not by itself remove the agent, desktop or other telephone systems from scope.

When evaluating a recording platform, test manual and automated pause triggers, timing, live transfers, call queues, resuming after authorisation, recordings exported to quality systems, and retention of old data in backups. Include screen recordings and speech-to-text, not just the audio file.

For the separate UK privacy, retention, employee monitoring and caller-information questions, see our business call-recording guidance. This guide covers PCI card-data scope, not general UK GDPR recording policy.

Hosted PBX, Softphones, AI Transcription and Outsourced Support

Telephony outsourcing changes who operates a system; it does not automatically remove the merchant’s contractual or PCI responsibilities. Ask whether account data can traverse the business LAN, browser, desktop capture, headset software, screen recording, CRM integration, analytics or AI voice services. Review data flow under normal calls and exceptional routes.

Swipe inside the table to see all columns.

For broader call-environment hardening and user access considerations, see UK VoIP security controls and, where a PBX feeds the payment route, how SIP trunking connects business calling.

What to Request from a Telephone-Payment Supplier

Do not accept a brochure as complete PCI evidence. Request the provider’s specific service name, payment path, responsibility allocation, current attestation or other applicable validation evidence, and limitations. Check whether the supplied evidence covers the particular component and deployment you are purchasing—not merely the parent company’s data centre.

Swipe inside the table to see all columns.

Telephone Payment Acceptance Tests Before Go-Live

Use test or non-sensitive demonstration data under an authorised supplier-led test plan; never place genuine card numbers or CVV values into website forms, recordings, chat, screenshots or this checklist. Agree how the assessor wants redaction and exclusion demonstrated without creating sensitive test artefacts.

Supplier evidence and go-live checks

Swipe inside the table to see all columns.

What If Card Details Enter a Recording, Transcript or CRM?

If card details enter an unapproved system, treat that as a potential security/compliance incident rather than quietly deleting a visible item and assuming the exposure has ended. Stop the unsafe capture route, preserve approved incident evidence without spreading account data, and engage the security owner and payment stakeholders.

Swipe inside the table to see all columns.

Who Decides the SAQ, ROC and Remaining PCI Responsibilities?

Merchants often hear that a hosted payment service “qualifies you for SAQ A” or “fully de-scopes the contact centre”. Those claims need context. Which assessment or attestation applies depends on the merchant, card brands, acquiring bank, validation criteria and the deployed card-data environment—not solely on whether payment capture is outsourced.

Before signing a supplier contract, give the acquirer or appointed PCI specialist the complete diagrams, product and service identifiers, data handling evidence and exception paths. Ask them to state the applicable assessment approach in writing. If the architecture changes, revalidate the impact.

PCI DSS and UK GDPR Are Different Obligations

PCI DSS governs payment-card data security. UK GDPR and associated UK law address personal-data processing, lawful bases, transparency, retention and individuals’ rights. A design may reduce payment-data exposure but still require privacy notices, access controls and appropriate retention practices for the rest of the recorded conversation.

Keep a separate privacy assessment for call monitoring, workforce recordings, transcriptions and any personal information beyond card details. PCI scope reviews should feed into—not replace—those governance processes. For that wider topic, refer to the existing call recording guide.

Example: A UK Service Desk Moves from Spoken Cards to Secure IVR

Fictional scenario: A three-team UK customer service operation uses a hosted PBX, browser softphones, call recording and a shared CRM. Customers currently read card details aloud. The business wants to use a separate secure payment IVR while keeping the agent on the call for order assistance.

Swipe inside the table to see all columns.

Telephone-Payment Scope & Supplier Evidence Checklist

Use this before approving a VoIP or secure-payment provider. Capture evidence identifiers, owners and sign-off dates outside the public website; the checklist itself must never become a repository for payment-card details.

Swipe inside the table to see all columns.

Compare general business telephony features separately using the VoIP recommendation quiz. It is a general selection tool, not a PCI audit, approval or validation service.

Frequently Asked Questions

Primary Standards and Further Reading

Reviewed on 22 October 2026. The 2018 PCI SSC telephone-payment supplement is supporting guidance, not a replacement for current PCI DSS requirements. Re-check the active standard and programme-specific rules at release.

• PCI SSC — FAQ 1153, How PCI DSS applies to VoIP
• PCI SSC — FAQ 1210, Sensitive authentication data in recordings (June 2025)
• PCI SSC — Protecting Telephone-Based Payment Card Data, Information Supplement v3.0 (November 2018)
• PCI SSC — PCI DSS v4.0.1 information and release
• PCI SSC — PCI DSS v4.0.1 request for comments (June 2026)

Editorial note: No supplier product has been technically tested or PCI assessed for this article. Illustrations, tables and scenarios are original advisory frameworks, not certification evidence.