Key takeaways
- PCI DSS prohibits storing the card security code after authorization, even encrypted, and call recordings count as storage.
- The PCI Council's telephone payment guidance says every possible effort must be made to eliminate sensitive authentication data from the telephone environment.
- Pause-and-resume recording can take the recording system out of scope, but staff and their desktops stay in scope.
- A VoIP system that carries card data puts the business's own phone network in scope.
- Using a compliant payment provider does not make the business compliant on its own; responsibilities must be documented.
Why do phone payments create a PCI compliance problem?
A card number read aloud can pull your phone system, call recordings, staff desktops and notepads into PCI DSS scope. When a client reads a card number to a receptionist, that number passes through the phone system, may land in a call recording, may be typed on a desktop, and may be jotted on a notepad. The PCI Security Standards Council addressed this directly in its information supplement on protecting telephone-based payment card data (version 3.0, November 2018). The supplement does not replace the standard, and it was written when PCI DSS v3.2.1 was current, so its requirement numbers differ from v4.0.1. Its core point still holds: the fewer places card data reaches, the smaller the compliance burden.
This matters to any firm that takes cards by phone: an insurance agency collecting a premium, a law firm taking a retainer (see where trust accounting meets PCI), a nonprofit processing a pledge, a practice settling an invoice. The obligation sits with the business, because card brands and acquiring banks enforce PCI DSS through the merchant agreement.
Can you keep call recordings that capture a card security code?
No. The three or four digit security code is sensitive authentication data, and PCI DSS v4.0.1 Requirement 3.3.1.2 prohibits storing it after authorization, even if it is encrypted. A merchant may ask for the code to authorize a card-not-present transaction, but it cannot keep it.
The Council's telephone guidance applies that rule to audio. It says every possible effort must be made to eliminate sensitive authentication data from the telephone environment. Where a recording system cannot be prevented from capturing it, the data must be deleted once the transaction is processed, and any that remains must be secured and must not be searchable. In practice, a phone system that records every call by default, with long retention for quality or dispute purposes, is the most common way firms end up storing security codes without knowing it.
Does pausing the recording solve it?
Only partly. The Council's guidance says pause-and-resume recording can take the recording and storage systems out of scope, but it does not reduce PCI DSS applicability to the agent or the agent's desktop. The person on the phone still hears the full card number and code, and the computer they use is still part of the payment flow.
Manual pausing also depends on people. The guidance flags the obvious failure: a staff member forgets to pause, or resumes too early, and the code lands in the recording anyway. Automated pausing triggered by the payment screen is more reliable than a button the receptionist has to remember.
What is DTMF masking, and what else keeps card data off the line?
DTMF masking, secure payment links and transfers to an automated payment line all keep card data away from staff, because the caller enters the card details and your staff never hear them. The Council's guidance prefers solutions that do not expose staff to card data at all, and describes several:
- DTMF masking or suppression. The caller types the card number on their phone keypad while staying on the call. The tones are replaced with flat or random tones, or removed, before they reach your staff and recordings. The guidance says a properly designed and deployed masking solution can take the telephony environment out of scope and may reduce scope for the agent desktop, provided no tones leak through.
- Secure payment links. Staff send the client a link by text or email to a hosted payment page run by a compliant provider, so the card number never travels over the phone.
- Transfer to an automated payment line. The call moves to an interactive voice system operated by a validated provider, and the caller returns to staff once payment is done.
The guidance is clear that scope reduction has to be verified. If card numbers still exist anywhere else in the environment, such as in a CRM note, a spreadsheet or an email, the reduction does not hold.
Does a VoIP phone system put you in scope?
A VoIP phone system can put your own network in PCI DSS scope. The Council's guidance says that when card data travels over VoIP, the business's own systems and networks in that path are in scope, and a VoIP network carrying account data faces the same PCI DSS requirements as any internal network. Carrier transport outside your infrastructure is generally not in scope. Many small firms run cloud or VoIP phones on the same network as their computers, so a spoken card number can extend scope to that network unless it is segmented or the card data never reaches the line.
What about the notepad on the front desk?
Yes, a front-desk notepad that holds card numbers is in scope. The guidance tells businesses to restrict access to notebooks, pens and mobile phones that can capture card data in areas where staff take payments, and to enforce a clean-desk policy. A card number written on a sticky note and typed in later is stored card data. The same applies to card numbers typed into an email, a chat message or a client record "for next time."
Does outsourcing phone payments make you compliant?
No. Under PCI DSS Requirements 12.8.1 through 12.8.5, the business manages its third-party service providers, and the Council's v4.0 summary of changes states that using a compliant provider does not make the business compliant. The telephone guidance adds that the business and the provider should clearly document who is responsible for which systems, processes and people. Outsourcing well can still change which Self-Assessment Questionnaire applies. For example, SAQ C-VT covers merchants that key one transaction at a time into a third-party virtual terminal on an isolated computer with no electronic storage of account data. Your acquiring bank decides which SAQ you file, and our guide to which PCI SAQ you need explains the options.
What should you do this quarter?
Start with an honest map of where card data goes today, then shrink it.
- List every way a card number reaches the firm by phone: main line, direct dials, mobile phones, voicemail and after-hours services.
- Check whether your phone system records calls, how long recordings are kept, and who can search or download them. Ask your provider in writing.
- Search voicemail, email, chat and client records for card numbers, and remove what you find.
- Pick one method that keeps the card number away from staff, such as payment links or DTMF masking, and make it the default.
- Write down who is responsible for what with your phone and payment providers, and keep their attestations of compliance on file.
- Record the result in your scope documentation. Requirement 12.5.2 expects scope to be confirmed at least every 12 months and after significant changes, and a new phone system is one.
How does s90 help?
s90 offers PCI DSS as a solo add-on to our managed IT services. We map where card data enters your phones, recordings and desktops, help you move to a method that keeps it off the line, and keep the scope documentation and provider evidence current. If you want a second look at how your firm takes phone payments, we are glad to walk through it with you.
