Does PCI DSS apply to call centers taking card payments by phone?
PCI DSS applies to a call center that takes card payments by phone, because the agents' systems, the telephony platform that carries cardholder data inside your network, and any call recordings that capture card details are all part of the environment your organization must protect. The rule that drives most of the work is that card verification codes (CAV2, CVC2, CVV2 or CID) must not be stored in any digital audio recording after authorization. Where the recording platform can suppress or redact audio during data entry, that capability should be enabled. Where it cannot, the recording must be securely deleted immediately after authorization. The organization owns this decision and the control that enforces it, and it should be documented as a control, not left to agent habit.
The cost and effort depend on four questions you should answer before requesting a quote: whether your recording platform can suppress audio during card entry, whether recordings with card data can be securely deleted on a reliable schedule, how the telephony platform is scoped (including whether VoIP traffic inside your own network falls inside your boundary), and which validation route applies to your acquirer's requirements. Each answer changes the work. A platform that suppresses audio reduces the number of controls you must prove. A platform that cannot suppress or delete may require a documented compensating control set, which carries recurring annual and change-driven risk assessments and restricted access to recordings and queries. Confirm with your acquirer which Self-Assessment Questionnaire or Report on Compliance applies to your volume and channel.
DeployOpen can prepare the systems, configurations, data-flow diagrams and evidence that support your controls, including recording configuration, retention settings and access records, as part of a fixed-scope engagement agreed in writing. DeployOpen does not validate compliance. Your organization attests to its own controls, and only a Qualified Security Assessor, or the validation route your acquirer or payment brand accepts, issues the Attestation of Compliance. Ask any provider to state in writing which of its deliverables are preparation and which, if any, come from an independent assessor.
Suppress, delete or compensate: which call recording path fits
The preferred path is to stop card verification codes from being recorded at all. Requirement 3.3.1 prohibits storing sensitive authentication data after authorization, and PCI SSC FAQ 1210 says that where technology exists to suppress or redact audio during data entry, it should be enabled. The organization must confirm that the telephony or payment platform actually pauses or masks recording while the code is captured, and that the pause works for every agent path, including transfers and fallback desks.
- Confirm the mechanism: Obtain the vendor's written description of how recording is paused or redacted during keypad entry, and test it on live call paths.
- Test failure modes: Check what happens if the payment step drops, the agent speaks the code aloud, or the call is transferred mid-entry.
- Keep configuration evidence: Retain screenshots, configuration exports and change records showing suppression is enabled on every queue.
- Sample recordings: Run periodic checks of recordings against known test cards to show no code is captured.
- Own the agent process: Agents must not repeat codes aloud, and training and monitoring must cover this.
Ask your vendor to confirm in writing which recording platforms and telephony configurations support suppression, because capability varies by product.
When suppression is not available, PCI SSC FAQ 1210 says the data should be securely deleted immediately after authorization. Deletion has to be real and verifiable. Deleting a file from a player interface while leaving copies in backups, archives, transcription queues or analytics stores does not satisfy the requirement, and an assessor will trace the recording's copies across systems.
- Map every copy: Document where recordings are written, replicated, backed up, transcribed and indexed, and who can export them.
- Define deletion triggers: Specify when deletion runs after authorization and how the process handles failed or partial deletions.
- Prove deletion: Keep job logs, deletion reports and sample verification showing that recordings containing codes are gone from every store.
- Address backups: Document how backup media age out or are purged so that codes do not persist there beyond what the process allows.
- Monitor exceptions: Alert on any failed deletion job and record the remediation.
Confirm with your recording and backup vendors which copies they make and how deletion propagates, since many platforms keep replicas that are not visible in the administrator console.
Where recordings with card verification codes cannot be securely deleted, PCI SSC FAQ 1210 gives an example of compensating controls. The example includes annual and change-driven risk assessments, protection of the stored data as PCI DSS requires, restricted access to the recordings and to the queries that retrieve them, and documented justification with evidence. These controls are validated during the annual assessment. Compensating controls are a last resort that depends on a documented business and technical reason, so the organization must be able to explain why deletion is not possible.
- Document the constraint: Write down the technical reason deletion or suppression cannot be done, with the vendor or system involved.
- Run risk assessments: Perform the annual and change-driven assessments the example describes and record decisions.
- Restrict access: Limit recording retrieval to named roles, log every access and query, and review those logs.
- Protect the data: Apply the PCI DSS controls that cover the stored recordings, including encryption and key management.
- Retain evidence: Keep the justification, approvals and assessment results for the assessor.
Compensating controls are not a standing exemption. Confirm with your QSA how they will be documented in the Report on Compliance, because the assessor decides whether the control meets the requirement.
Some jurisdictions require call centers to retain audio recordings for a fixed period, for example for dispute resolution or financial conduct rules. PCI SSC FAQ 1210 states that PCI DSS does not override local or regional laws on retaining audio recordings, and it points call centers to the PCI SSC Information Supplement on protecting telephone-based payment card data. The legal obligation does not remove the PCI DSS obligation for card verification codes. The organization must reconcile the two, usually by suppressing the codes or restricting and protecting the recordings that must be kept.
- Identify the legal basis: Obtain written advice from counsel on which recordings must be kept, for how long and in which jurisdictions.
- Separate the conflict: Determine whether the law requires the whole recording or only the conversation, and whether the card code is needed for that purpose.
- Apply the PCI controls: Protect retained recordings with the stored-data, access and logging controls that apply to cardholder data.
- Document the decision: Record the legal requirement, the PCI DSS position and the controls chosen, and have the decision reviewed.
- Plan for change: Review the decision when recording law or call routing changes.
Take the Information Supplement and legal advice to your QSA early, because the assessor will test the reasoning, not only the controls.
How a telephone payment environment moves from scoping to assessment
The sequence takes a call center from knowing where card data enters its calls to a validated assessment, with each phase producing a record an assessor can check. Organizations own every decision in it, while implementation partners and assessors each carry a defined part.
Map every point where card data enters
Trace each route a card number or verification code can take: the IVR or payment prompts, the agent desktop and CRM fields, call recordings, agent notes, chat transcripts, email and any ticketing tools. The owner is the call center operations lead with the security team, and the output is a data-flow diagram and an inventory of every system that receives, stores or displays account data. The step is done when no entry point is left unlisted and each one has an owner.
Decide suppression or secure deletion for each recording
For each recording path, decide whether the telephony or payment platform can suppress or redact audio during data entry. Where suppression is available, it should be enabled. Where it is not, the organization must securely delete card verification codes immediately after authorization. The output is a written decision per channel, signed off by the data owner, with test evidence showing the setting is active in production.
Document compensating controls where deletion is not possible
If recordings that contain verification codes cannot be securely deleted, document a compensating control set. PCI SSC FAQ 1210 gives an example that includes annual and change-driven risk assessments, protection of the recordings under PCI DSS, restricted access to recordings and queries, and documented justification. The output is a compensating control worksheet with the constraint, the risk analysis and the evidence that each control operates, ready for the assessor to test.
Confirm VoIP and telephony scope
Confirm which telephony components sit inside your network and perimeter, including SIP trunks, softphones, session border controllers, call recording servers and the payment gateway connection. Systems within your infrastructure that carry account data are in scope, while the transmission of a call outside your infrastructure is not, because you cannot control how cardholders place calls. The output is a scoping statement reviewed by the assessor, supported by network diagrams that show the boundary.
Stop card data leaking into chat and email
Check whether agents or customers send card numbers through chat, email or SMS. Requirement 4.2.2 requires PAN sent through end-user messaging technologies to be secured with strong cryptography, and verification codes should never be requested through these channels unless authorization requires them and they are never stored. The output is a channel policy, agent training record and configuration evidence showing that the messaging tools block or redact card data where possible.
Check local recording retention laws
Before setting retention periods for recordings, confirm with legal counsel what local or regional laws require for keeping call audio. PCI DSS does not override those laws, so the organization may need to retain recordings that the standard would otherwise limit. The output is a documented retention decision that reconciles the legal minimum with the card data controls in the earlier phases, and a list of recordings that need a compensating control.
Select the validation route with the acquirer and assessor
Confirm with your acquirer or the payment brands which validation applies, whether a Self-Assessment Questionnaire or a Report on Compliance completed by a Qualified Security Assessor. Use the results of the earlier phases to decide the route, and confirm the assessor's independence from any consulting work. The output is an agreed validation plan, the evidence list the assessor will request, and a signed Attestation of Compliance once the assessment closes.
What makes the telephone payment scope larger or smaller
A telephone payment program is in scope wherever card data lands, and the same handful of decisions decide how much lands there. Each driver below is something you can change, and each has a named party who must confirm the answer before an assessor will accept it.
Audio suppression during entry
Ask whether your recording platform can pause or redact audio while the agent keys the card number and card verification code. If it can, enabling that feature is the first step. If it cannot, card verification codes must be securely deleted immediately after authorization, which makes deletion timing a daily operational control. Your telephony or contact center vendor must confirm the capability in writing, and your QSA will test it on a live call.
Number of recording systems and archives
Every place a call is stored, including backups, quality monitoring tools, speech analytics and exports to shared drives, is a separate storage location to inventory and secure. Reducing the number of copies narrows the scope and the evidence you must produce. Your telephony administrator should produce a complete list of recording repositories, and your assessor will compare it against network and data-flow diagrams.
Card data in agent notes and tickets
When agents type card numbers or verification codes into CRM notes, ticket fields or free-text comments, those systems become part of the cardholder data environment. Restrict free-text fields, mask card entry in the payment screen, and run periodic searches for stray card data. Your CRM owner and an internal reviewer should confirm that no ticket templates or chat logs contain account data before the next assessment.
Outsourced call center operations
A contracted call center that takes payments on your behalf brings its agents, workstations and recordings into your scope, and you remain responsible for how they are protected. A payment processor or telephone payment provider that handles the card data itself can reduce your exposure, but only if the provider's responsibility matrix and attestation cover the telephone channel. Ask the provider for its current attestation and a written split of responsibilities.
VoIP carrier and hosting location
Voice traffic carrying account data is in scope within your own network up to its external perimeter, so the hosting location of your phone system and recording servers matters. Calls placed by cardholders travel over carrier networks you do not control and are generally outside your scope. Your network team should map which segments carry voice with card data, confirm encryption on internal paths, and document the boundary with the carrier.
Retention obligations under local law
Local recording laws may require you to keep call audio for a fixed period, which can conflict with deleting card verification codes. PCI DSS does not override those laws, so the answer is usually a documented compensating control, such as restricted access and periodic risk assessment, rather than retention itself. Your legal or compliance team must confirm the applicable retention period in each jurisdiction, and your QSA must accept the justification.
Card data over chat, email and VoIP: what changes the scope
Card data that reaches your contact center through end-user messaging changes your PCI DSS scope before anyone reviews a recording. Requirement 4.2.2 requires the primary account number to be secured with strong cryptography whenever it is sent through technologies such as email, chat or SMS. If an agent or a customer pastes a card number into a chat window or an email, that channel becomes part of the cardholder data environment, and the transport, storage and mailbox or chat archive behind it must be protected. The practical decision is to stop the flow at the source: tell customers not to send card details by these channels, configure chat and mail tools to block or mask numeric patterns where possible, and confirm with your assessor how any residual transcripts are handled. Check whether your chat platform retains transcripts by default and who can search them.
VoIP is the second boundary to map. Under PCI DSS guidance, voice traffic that carries account data is in scope within your own network up to your external perimeter, so your PBX, softphones, session border controllers, call-recording servers and the network segments between them belong in your assessment. The part of the call path you do not control is the customer's carrier network and the public path to your perimeter. Customers place calls through their own providers, so that transmission outside your infrastructure is generally not treated as your scope. Ask your VoIP or carrier provider to document where their responsibility starts and ends, including encryption of signaling and media (SIP over TLS and SRTP, where used) and whether any call leg is handled by a third party. Then ask your assessor to confirm that boundary in writing, because it determines which network diagrams and evidence you must keep.
Confirm three things before the assessment: which messaging and voice components you operate, which of them are provided by a third party who can attest to its own controls, and where the handoff between the two sits on your data-flow diagram. Record each decision in your scope documentation with the date and the person who approved it. A written boundary that your provider and assessor have both reviewed is far easier to defend than an assumption that voice traffic is out of scope because it runs over a carrier.
What must be in place before the assessment
A telephone payment environment is only assessable when its recording, suppression and access settings are documented and provable. The cards below cover the items an assessor will ask to see before testing begins, and each one includes a practical way to check it.
Documented recording and suppression settings
Write down which calls are recorded, which platform records them, and whether pause-and-resume or automatic redaction is enabled during card entry. Under Requirement 3.3.1, card verification codes must not be stored in any audio recording after authorization, so suppression must be switched on and verifiable wherever the technology exists. Check it by placing a test payment on a non-production line, then searching the recording store for the test card verification code.
Data-flow diagram including call recordings
The data-flow diagram must show every path card data takes during a phone payment, including the telephony platform, the recording server, quality-assurance tools, ticketing notes and any backup copies. Recordings are easy to leave off because they sit outside the payment application. Check the diagram against live systems by tracing a sample call from the handset to the storage location and confirming each hop appears on the diagram.
Risk assessment for each compensating control
If recordings holding card verification codes cannot be securely deleted, the organization needs a documented compensating control, and the example in FAQ 1210 expects annual and change-driven risk assessments. The assessment should name the specific recordings affected, the protections applied and the residual risk. Check it by confirming it has a date, an owner, a trigger for re-assessment after telephony changes, and evidence that the assessor can reproduce.
Restricted access to recordings and query tools
Access to stored recordings, playback tools and any search or query interface must be limited to people with a documented business need. Quality teams and supervisors often receive broad access by default. Check the access list against the current roster, confirm that playback and export actions are logged, and verify that search tools cannot return raw audio containing card data to users who do not need it.
Retention rules that reflect local law
Retention periods must reflect the recording laws that apply to each call location and customer base, and PCI DSS does not override those laws. Document the legal basis for each retention period, the deletion schedule, and who approves exceptions. Confirm the rules with counsel, not the vendor, and check that automated deletion actually runs by reviewing deletion logs for a sample period.
Who owns the call center controls and who prepares the evidence
The organization that takes the payments owns its PCI DSS controls, including the decisions that most affect call center scope. Those decisions are whether card verification codes are ever requested by phone, whether calls are recorded at all, how long recordings and transcripts are kept, and whether the environment needs compensating controls because a recording cannot be securely deleted. Local recording and retention laws also sit with the organization and its legal counsel, because PCI DSS does not override them.
- Retention decisions: Document how long recordings, notes and call logs are kept and who approves any exception.
- Policy ownership: Maintain the written procedures agents follow when taking card details by phone.
- Suppression or deletion rules: Decide whether audio is suppressed during entry or deleted immediately after authorization.
- Compensating control justification: If the approach depends on a compensating control, own the risk assessment and the evidence behind it.
- Staff accountability: Assign named owners for agent training, access reviews and recording access.
Before you commit to a design, confirm with your acquirer and your QSA which of these decisions they expect you to document.
An implementation partner such as DeployOpen can plan and configure the systems that support the call center process, prepare the technical evidence and help write the documentation that describes it. Where suppression settings or recording controls are in scope, the partner can test that they behave as documented and record the results. The partner works on the systems and evidence the organization has chosen to use. It does not decide the control design on the organization's behalf, and it does not certify the result.
- System configuration: Set up recording, call routing and storage components inside the client's own environment, following the organization's chosen design.
- Suppression testing: Where audio suppression is in scope, test whether card data is captured in recordings and report the findings.
- Evidence preparation: Collect configuration exports, access lists, retention settings and test results in a form an assessor can review.
- Documentation support: Draft network and data-flow diagrams and runbooks that match the deployed systems.
- Remediation: Fix gaps found in testing and retest them before handover.
DeployOpen does not issue reports on compliance or attestations. Ask any partner to state in writing which outputs it prepares and which belong to the assessor.
A Qualified Security Assessor or other independent assessor tests the controls against the standard and produces the formal output. For a larger merchant or service provider, that output is a Report on Compliance. For smaller organizations that qualify for a self-assessment, the output is a Self-Assessment Questionnaire with an Attestation of Compliance. Only the assessor's documented testing supports a validation, and the assessor must be independent of the team that designed the controls.
- Independent testing: The assessor samples recordings, reviews configurations and interviews staff rather than relying on the organization's summary.
- Compensating control review: The assessor checks the risk assessment, the protections and the restricted access described in any compensating control.
- Evidence sampling: Expect requests for recording samples, access logs, deletion records and change history.
- Formal output: The ROC or the SAQ with its Attestation of Compliance is the only accepted validation, and certificates are not recognized.
- Scope confirmation: The assessor confirms which systems, including VoIP components, are in scope.
Ask your assessor early which evidence they will request and in what format, so the other roles can prepare it in time.
Questions call center leaders ask about PCI DSS and phone payments
Can agents read card numbers aloud during a phone payment?
Yes, agents can take card details by phone, but the card data then sits in the call center's environment and falls under PCI DSS. The reader's main decision is how far that data travels. Every system that hears, displays, records or stores the card number is part of the cardholder data environment. The PCI SSC's telephone payments guidance notes that organizations taking card details by phone may record full cardholder details to meet other regulatory demands, which puts them in contravention of PCI DSS. Before agents read numbers aloud, confirm which systems receive the data, whether screens mask it, and whether a payment capture method keeps agents out of the flow entirely.
Must call recordings be deleted after a card payment?
Card verification codes must not remain in any digital audio recording after authorization. The PCI SSC's FAQ 1210 says that where technology exists to suppress or redact audio during data entry, it should be enabled. Where it does not, the data should be securely deleted immediately after authorization. Other card data on the recording may follow different retention rules, and your own policies and local law also apply. Ask your recording vendor whether pause-and-resume or automatic redaction is available, and whether deletion is verifiable in logs.
What does a compensating control require for call recordings?
A compensating control is an alternative measure used when a requirement cannot be met as written, and it must be documented and validated in your annual assessment. PCI SSC FAQ 1210 gives an example for recordings with card verification codes that cannot be securely deleted. It describes annual and change-driven risk assessments, protection of the data under PCI DSS, restricted access to recordings and queries, and documented justification with evidence. Expect to produce the risk assessment, access lists, query logs and the business reason the recordings must be kept. Each of these needs an owner and a review date.
Is the telephony or VoIP provider in scope for PCI DSS?
Your own telephony systems that carry account data are in scope up to your external perimeter. PCI SSC FAQ 1153 explains that for calls with cardholder data, your systems are in scope, but transmission outside your infrastructure is not, because you cannot control how cardholders place calls. A hosted or cloud telephony provider that stores, processes or can affect card data may still fall within scope, so confirm its responsibilities in writing. Ask the provider for its PCI DSS responsibility matrix and its current attestation, and check which recording, storage and logging functions it runs for you.
How do local call recording laws interact with PCI DSS?
PCI DSS does not override local or regional laws on retaining audio recordings, and the two must be reconciled in your own policy. PCI SSC FAQ 1210 points call centers to its Information Supplement on protecting telephone-based payment card data for further guidance. Legal retention obligations may require you to keep recordings that PCI DSS would prefer to delete, which makes the compensating control path relevant. Involve legal counsel early, document which law requires which retention period, and record the decision in your risk assessment. Confirm the requirements in each jurisdiction where you take calls.
How much effort does a phone payment program need from the team?
The effort depends on how many payment paths exist, how recordings are handled and how many systems touch card data. Costs are one-time for scoping, configuration and documentation, and recurring for annual assessment, risk reviews, access reviews and log checks. The PCI SSC does not publish a fixed effort figure for call centers, so ask for a count of agent desks, telephony platforms, recording systems and downstream databases before comparing estimates. Any quote should list which assessment (SAQ or ROC), which technical changes and which evidence work are included.
Can our team handle telephone payment compliance in-house?
Many organizations keep ownership in-house and bring in outside help for specific tasks. Your organization owns its controls, and an implementation partner can prepare systems, configuration and evidence, but only an independent assessor issues a Report on Compliance or validates an Attestation of Compliance. Confirm that your staff can maintain the risk assessment, access reviews, recording configuration and change records over time. If they cannot, use a fixed-scope engagement for setup and a retainer for ongoing support, and check that any QSA you hire remains independent of the consulting work.
Where call center PCI projects usually stall
Most call center PCI projects lose time to four problems that surface late: recordings sitting in systems nobody inventoried, agents typing card numbers into CRM notes, teams assuming a compensating control needs no paperwork, and retention law colliding with deletion. The first step for each is a check you can run this month. Ask your telephony, quality monitoring and cloud teams to list every place a call recording, transcript or screen capture lands, including vendor-hosted speech analytics and backup copies. Add those locations to your system inventory and data-flow diagram before the assessor asks for them. Recordings you did not know existed are the most common reason a scoping exercise has to restart.
Agent notes are the second recurring gap. When an agent types a card number into a CRM free-text field, the data is now stored in a system that was never built to protect it, often with broad read access and copies in exports. The preventive step is to make the payment flow itself the only place card data is entered, using DTMF masking or a hosted payment capture, and to configure the CRM with input restrictions and a periodic search for PAN patterns. Pair this with agent training that states clearly what must never be written down. Treat any discovered PAN in notes as a finding to remediate and document, not a quiet cleanup.
The third stall is treating a compensating control as a paperwork exception. The example in PCI SSC FAQ 1210 for call recordings that cannot be securely deleted expects annual and change-driven risk assessments, restricted access to recordings and queries, and documented evidence that is validated during the assessment. Each of these needs an owner, a schedule and records from the start. The fourth stall is retention law. PCI DSS does not override local rules on keeping audio, so a recording rule that requires long retention can conflict with a deletion requirement. Ask your legal and privacy teams to confirm, in writing, which jurisdictions and contracts apply, and resolve that conflict before you finalize the recording design.
