Updated Industry Guidance on Accepting Telephone Payments

Article PCI DSS
Accepting Telephone Payments

 

In November 2018, the PCI SSC published an updated version of their information supplement for protecting telephone-based payment card data and reducing associated risks. This guidance explores common examples of technologies used in telephone-based payment environments, including Voice over Internet Protocol (VoIP) systems, which are quickly replacing traditional analog phone lines in  many offices and call center environments. Other technologies like dual-tone multi-frequency (DTMF) masking solutions, interactive voice response (IVR) systems, and online chat applications, are also discussed in the document. A significant change between this update and the March 2011 version of the document is that manual pause-and-resume processes for call recording are now acceptable for PCI compliance when appropriately implemented.

The move towards VoIP technology has created multiple concerns and uncertainties for PCI compliance. If phone calls include the transmission of cardholder data, whether spoken or keyed in, that data is in scope for PCI DSS. Your VoIP system could be bringing your entire network into PCI scope without you even realizing it. Third-party service providers will often offer multiple services like call-recording, data storage, call analytics, hosted VoIP, etc., but it is important to understand what these services mean for your organization’s scope, how to define responsibilities between third-parties, and how to prevent the potential exposure of cardholder data.

As CampusGuard reviewed this updated guidance, we wanted to pass along our primary takeaways for you to consider:

  • Overall, the basic guidance remains the same: No payment card data should be stored unless necessary to meet the needs of the business. Sensitive authentication data (SAD), like the card security code, can never be stored after authorization. Unless you are legally or contractually required to record phone calls, don’t!
  • The transmission of cardholder data over VoIP is in scope and all PCI DSS requirements now come into play.
  • The use of softphones that are installed on an end user’s workstation with either a headset or USB-style phone can bring the workstation, and the network it is connected to, into PCI DSS scope.
  • You can also consider technology solutions where call center staff do not hear or enter cardholder data into the system. Technologies that allow the cardholder to use their telephone keypad or enter data into a secure webpage prevent your organization and employees from accessing that information. Dual-tone multi-frequency (DTMF) masking can be used as a solution. However, if DTMF bleed occurs, it could potentially place a previously de-scoped environment back in-scope for PCI.
  • Many organizations have incorrectly assumed that the use of pause-and-resume call recording ensures they are not storing cardholder data and keeps them compliant with the PCI DSS requirements. The new Council guidance highlights the fact that neither manual nor automated pause-and-resume technology is 100% accurate, and organizations need to implement additional controls to verify that this feature is functioning correctly on a regular basis.
  • Depending on what services are being provided by the telephone service provider (encryption, etc.), they may not necessarily be deemed out of scope. It is important to review up to date data flow diagrams to analyze how they can impact the security of the cardholder data on their networks.
  • When possible, outsource all call center responsibilities to PCI-listed service providers in order to minimize your PCI compliance responsibilities. However, as with any third-party, you can never completely outsource PCI compliance, so it is important to verify what your responsibilities are and what theirs are. For example, is the third-party using any campus network resources, systems, etc.? Are your staff members employed by the vendor? Who owns the merchant ID? Have you requested the appropriate PCI compliance documentation? Do contract agreements define who is responsible for the cardholder data in the event of a data breach? The answers to these questions will have a distinct impact on your PCI compliance responsibilities.
  • Lastly, don’t forget the people aspect. It is important to ensure that only the minimum number of employees necessary have access to cardholder data. Train all staff handling CHD, and clearly define their responsibilities for protecting data and identifying and reporting suspicious behaviors. Prior to being hired, all employees working with payment data should undergo background checks (per Requirement 12.7). Organizations/call centers should also enforce clean desk policies, forbidding materials and devices that could record data. Particular attention should be given to remote workers in order to maintain the ongoing security of systems and equipment where payment card data is involved.

Some additional guidance from the CampusGuard Security Advisor team:

[Ko]: The PCI DSS is a more mature standard and many of the “big rocks” have been addressed which means that the PCI Council is focusing on the “smaller rocks” like VoIP. CampusGuard recommends encrypting all VoIP traffic and not using IP softphones for handling any sensitive data. We will continue to monitor this space for new technologies, threats, etc., and keep you informed of any changes in compliance requirements and overall security best practices.

Share

About the Author
Katie Johnson

Katie Johnson

PCIP

Manager, Operations Support

As the manager of Operations Support, Katie leads the team responsible for supporting and delivering CampusGuard services including online training, vulnerability scanning, and the CampusGuard Central® portal. With over 15 years of experience in information security awareness training, Katie is also the Product Lead for CampusGuard’s online training services. As a Senior Customer Relationship Manager for a limited number of customers, Katie assists organizations with their information security and compliance programs and is responsible for coordinating the various teams involved.