What You Should Know About the Changing Nature of Telephone-Based Payments

Karl Steinkamp, Director, PCI Product and Quality Assurance

In March 2011, the PCI SSC released the initial version of the “Protecting Telephone-Based Payments Card Data” Information Supplement as a guide to help assessors assess environments where cardholder data was stored, processed, and/or transmitted over the telephone. It was a pivotal guidance document at the time that set the stage for a broader focus on telephony technologies. As of November 2018, that time has finally arrived. The revised document provides a comprehensive dive into various telephony architectures (specifically VoIP, ISDN, and PSTN) and related people and processes that are required to be considered within scope for PCI DSS compliance.

Who is impacted by the change? How so?

  1. Potential for PCI Scope Expansion
    • Entities such as merchants that use telephony as a card acceptance payment channel.
    • Entities such as merchants, customer service centers, call centers, or contact centers that outsource or are considered as outsourcing telephony payment acceptance to a third-party service provider.
    • Service providers that accept payments over the telephone or manage transactions over the telephone on behalf of merchants or other entities.
    • Technology vendors providing, maintaining, and/or managing telephone payment systems.
    • Providers of telephony services (e.g., interactive voice response [IVR] or Dual-Tone, Multi-Frequency [DTMF] masking/suppressing).
    • Acquirers, payment service providers, and payment gateways that support relevant entities.
  2. Potential for Additional QSA/ISA Testing Required
    • Qualified Security Assessors (QSAs) and Internal Security Assessors (ISAs) that support any of the above entities.
    • Card issuers that support the secure distribution of payment cards to cardholders.

What is the impact of the change to my organization’s telephony-based payment environment?

  1. Defining segmentation/demarcation points for the telephony environment is critical. The convergence of voice and data networks can have the effect of bringing the entity’s wider infrastructure into PCI DSS scope.
    • Achieving network segmentation when using a single VoIP phone system that links in-scope and out-of-scope systems will be difficult.
  2. Telephony infrastructure responsible for call routing, handling, and management are required to be in scope for the entity’s (or service provider’s) PCI compliance efforts, as they are handling customer calls with card data.

  3. When VoIP is used for transmissions of payment account data, the entity’s systems and networks used for those transmissions are in scope for all applicable controls.

  4. Carriers providing only access to public networks are generally considered out of scope for PCI DSS.

  5. Particular attention should be given to home workers, as controls that would commonly be implemented in a “formal call center” don’t traditionally exist.

  6. Entities should consider technology solutions where personnel do not have to hear or enter account data into the systems (i.e., DTMF masking)

  7. Use of softphones to capture payment card data brings the workstation and the network into PCI DSS scope.

  8. Organizations that have legitimate constraint to retain SAD in recordings should discuss and obtain approval from their acquiring and/or payment brand.

  9. In instances where pause-and-resume technology exists (especially agent initiated), regular checks (weekly recommended) should be implemented.

Some of these changes may seem dramatic to some entities, but it’s important to keep in mind that this release is an information supplement and not a change to the PCI DSS standard itself. The clarifications in the supplement are intended to bring clarity to how changing technologies should be understood relative to the PCI DSS. Coalfire was one of the QSA companies involved in helping develop this new information supplement; if you have questions on how this document might affect your environment, we are here to partner with you in understanding this new guidance.

Karl Steinkamp


Karl Steinkamp — Director, PCI Product and Quality Assurance

Recent Posts

Post Topics



Accounting Agency AICPA Assessment assessments ASV audit AWS AWS Certified Cloud Practitioner AWS Certs AWS Summit bitcoin Black Hat Black Hat 2017 blockchain Blueborne Breach BSides BSidesLV Burp BYOD California Consumer Privacy Act careers CCPA Chertoff CISO cloud CMMC CoalfireOne Compliance Covid-19 credit cards C-Store Culture Cyber cyber attacks Cyber Engineering cyber incident Cyber Risk cyber threats cyberchrime cyberinsurance cybersecurity danger Dangers Data DDoS DevOps DevSecOps DFARS DFARS 7012 diacap diarmf Digital Forensics DoD DRG DSS e-banking Education encryption engineering ePHI Equifax Europe EU-US Privacy Shield federal FedRAMP financial services FISMA Foglight forensics Gartner Report GDPR Google Cloud NEXT '18 government GRC hack hacker hacking Halloween Health Healthcare heartbleed Higher Education HIMSS HIPAA HITECH HITRUST HITRUST CSF Horror Incident Response interview IoT ISO IT JAB JSON keylogging Kubernetes Vulnerability labs LAN law firms leadership legal legislation merchant mobile NESA News NH-ISAC NIST NIST 800-171 NIST SP 800-171 NotPetya NRF NYCCR O365 OCR of P2PE PA DSS PA-DSS password passwords Payments PCI PCI DSS penetration Penetration Testing pentesting Petya/NotPetya PHI Phishing Phising policy POODLE PowerShell Presidential Executive Order Privacy program Ransomware Retail Risk RSA RSA 2019 Safe Harbor Scanning Scans scary security security. SOC SOC 2 social social engineering Spectre Splunk Spooky Spraying Attack SSAE State Stories Story test Testing theft Virtualization Visa vulnerability Vulnerability management web Wifi women XSS