PCI DSS, Telephone Payments, and the Problems With VoIP

Merchants have been accepting payment cards over telephones for a long time, but changing interpretations of VoIP guidance have led to confusion about which PCI DSS requirements apply to telephone-based payment channels. Merchants that have used SAQ C-VT or P2PE to reduce the number of PCI DSS requirements that apply to telephone payment channels are discovering that they cannot use and benefit from these SAQs if they collect payments over VoIP.

Merchants typically encounter this issue when additional requirements appear in the annual PCI DSS compliance attestation web form provided by their processor after answering 'Yes' to a question about the use of VoIP. Merchants may also encounter this issue when their transaction volumes increase to the point that they can no longer self-assess and are informed by a QSA that they have been incorrectly applying the PCI DSS SAQ C-VT or P2PE to their telephone payment channel.

This post explains who is affected by the VoIP guidance interpretation, where this interpretation comes from, and how merchants can reduce the number of PCI DSS requirements applicable to their telephone-based payment channels and be prepared for their next assessment (with some QSA gripes along the way).

TrustedSec has long worked to move its clients into compliance with the PCI SSC guidance around how telephone payments via VoIP must be scoped and assessed and can assist other merchants struggling with this issue. If you need assistance with this, get in touch with us!

Who This Applies To

This issue applies to merchants using eligibility for PCI SAQ C-VT or P2PE to reduce the number of PCI DSS requirements applicable to a telephone-based payment channel when payment card account data is received over VoIP. This includes merchants that complete a ROC but use eligibility for SAQ C-VT or P2PE to determine the applicable controls within the ROC, as per PCI SSC FAQ 1331.

Merchants that attest to PCI DSS compliance via a guided questionnaire on their processor’s website may not be aware of which SAQ they are effectively using. Behind the scenes, the first few questions in these forms are usually used to determine which SAQ applies to the merchant, and the remaining questions are based on the requirements in applicable SAQ.

The following list can be used by merchants to determine which SAQ their processor has likely been applying to them and how many requirements to expect compared to the full set of 236 PCI DSS merchant requirements (not including the rarely used appendices). Note that all SAQ types are included in this list to help merchants identify which may be applied, but only SAQs C-VT and P2PE are subject to the VoIP issue described in this post.

The Interpretation

VoIP in PCI DSS

PCI SSC guidance states that the PCI DSS requirements apply to VoIP traffic from a cardholder to a merchant that contains payment card account data just as they would to any other network traffic that contains account data. This means:

• VoIP traffic is in scope for PCI DSS requirements as soon as it crosses the network boundary into the merchant environment.
• The VoIP telephone and/or workstation running a VoIP softphone is in scope.

The sources of this guidance are as follows:

PCI SSC FAQ 1153 concerns how PCI DSS applies to VoIP. The part of this FAQ most relevant to this issue is:

The FAQ also contains this relevant paragraph that tells us a transmission of account data from a cardholder to a merchant is in scope once it enters the merchant’s environment:

This topic is also covered in more detail with supporting diagrams throughout the Information Supplement on Protecting Telephone-Based Payment Card Data.

VoIP Effect on SAQ Eligibility

Each SAQ has eligibility criteria that determine under which scenarios a merchant may benefit from the reduced number of applicable requirements in that SAQ. The eligibility criteria are usually listed on page iii of the SAQ templates (or page iv in SAQ C) available from the PCI SSC Document Library.

There are lines in both the SAQ C-VT and P2PE eligibility criteria that combine to prohibit the use of these SAQs when account data is received via VoIP:

• Both the SAQ C-VT and P2PE eligibility criteria define the only authorized electronic channel for account data handled under each of these SAQs:
  • SAQ C-VT: “The only payment processing is via a virtual payment terminal accessed by an Internet-connected web browser”
  • SAQ P2PE: “All payment processing is via a validated PCI-listed P2PE solution”
• Both SAQs then go on to prohibit receiving account data electronically via other methods:
  • SAQ C-VT: “The merchant does not otherwise receive, transmit, or store account data electronically through any channels (for example, via an internal network or the Internet)”
  • SAQ P2PE: “The merchant does not otherwise receive, transmit, or store account data electronically”

This text is clear: There is only one authorized channel for electronic account data under each of these SAQs, and any other handling of electronic account data renders a payment channel ineligible for these SAQs. VoIP is neither “a virtual payment terminal accessed by an Internet-connected web browser” nor “a validated PCI-listed P2PE solution” so the receipt of electronic account data via VoIP violates the eligibility criteria in both of these SAQs. Merchants receiving payments via VoIP are therefore ineligible to benefit from the reduced set of requirements in these specific SAQs and must use a different SAQ.

This is true regardless of whether:

• The VoIP traffic is destined for a hardware phone sitting on a desk or a softphone application installed on a workstation or mobile device:
  • The merchant is receiving VoIP traffic containing electronic account data in violation of the eligibility criteria in both scenarios.
• Calls are not recorded or recording is paused when account data is read:
  • The merchant is receiving VoIP traffic containing electronic account data in violation of the eligibility criteria even if the account data is not stored.
• VoIP infrastructure is segmented from the rest of the network:
  • Segmentation may help keep the rest of the merchant’s network out of scope, but the VoIP infrastructure is still receiving electronic account data in violation of the eligibility criteria.
• VoIP traffic is encrypted:
  • Encryption can be used to get account data out of scope in certain circumstances but the paragraph on Encrypted Cardholder Data and Impact on PCI DSS Scope in section 4 of PCI DSS tells us that “encrypted cardholder data that is present in the same environment as the decryption key” is in scope. Something in the merchant’s environment (often the VoIP telephone or softphone) must have the decryption key if merchant personnel are able to hear the contents of a call, so the encrypted VoIP traffic is in scope when it is received and violates the eligibility criteria.

Options to Maintain Compliance

The good news is that the use of VoIP does not automatically make a merchant non-compliant; it just means the merchant cannot use SAQ C-VT or P2PE (the use of shorter SAQs is always optional). A merchant would only be non-compliant if it does not implement the other PCI DSS controls that apply due to ineligibility for SAQ C-VT or P2PE.

A merchant that finds itself receiving account data via VoIP in what it thought was an SAQ C-VT or P2PE eligible environment has a few options listed here, but this information is also described in more detail below:

• Stop taking telephone payments.
  • Eliminates PCI DSS applicability to VoIP by eliminating the payment channel
• Switch from VoIP back to POTS lines and keep using SAQ C-VT or P2PE.
  • Minimizes changes to existing processes, if POTS lines are still available
• Outsource telephone payment acceptance to achieve eligibility for SAQ A.
  • Minimizes compliance obligations by transferring them to a third party
• Change how telephone payments are processed to be eligible for another short SAQ that does not have this issue (B, B-IP, or C).
  • SAQ B-IP is the recommended option for merchants using P2PE solutions when none of the options above are viable.
  • Merchants with an existing payment application may consider processing telephone transactions via their payment application to achieve eligibility for SAQ C.
• Fall back to the default SAQ D Merchant and apply all PCI DSS requirements.
  • May be the only option for merchants that want to keep using a virtual terminal solution and cannot install POTS lines

Stop Taking Telephone Payments

Some of the merchants TrustedSec has worked with have determined that telephone payments represent such a tiny fraction of their payments that it’s not worth keeping them available as a payment channel.

Some merchants have call center personnel email or text a web payment link to customers instead of taking payment details via telephone. The VoIP infrastructure will be out of scope for PCI DSS in this scenario, as it no longer accepts account data. The website that accepts payments will be in scope, but this is often a merchant’s own payment site that is already in scope for PCI DSS as part of another payment channel, or a payment page outsourced to a PCI DSS compliant third party that is eligible for SAQ A from the merchant perspective.

Some merchants integrate web payment systems with call center software so that call center personnel can see when payments have been completed online without bringing the call center itself into scope for PCI DSS.

Switch to POTS Lines

SAQ C-VT was written in the era of POTS lines, and using a regular old telephone from that era would maintain eligibility (POTS lines would also maintain eligibility for SAQ P2PE). Some of TrustedSec’s clients have reinstalled POTS lines for their call centers, but it is not very popular as POTS lines are as hard to come by these days as imprint machines.

TrustedSec has also heard of some merchants using mobile phones to accept payments instead of VoIP phones, but this approach strays into a grey area within PCI DSS that warrants further discussion in another post: Modern smartphones that connect and receive voice traffic via IP-based protocols are just as sophisticated as desktop and laptop computers, and are increasingly susceptible to malicious attacks. It’s hard to make a case that it would be acceptable to use a smartphone, which is essentially an IP-connected softphone running on a very small workstation, when it is not acceptable to use an IP-connected softphone running on a normal sized workstation.

Outsource Telephone Payments

Many merchants have had success outsourcing the parts of the telephone call that require handling payment card account data. This results in eligibility for SAQ A which, as applied in this scenario, is the shortest of the SAQs.

There are a few different ways this can be implemented, such as:

• On one extreme, the merchant can completely outsource the entire call process to third-party personnel.
• Another popular option is to use merchant personnel to receive calls but transfer the payment stage of the call to an IVR solution that steps in to receive and process the account data on a third-party system.

Care must be taken when designing an IVR solution to keep the merchant systems from falling in scope. In some solutions the call continues to be routed through the merchant environment to the third-party IVR solution after the payment process starts. In this scenario the merchant environment would remain in scope (and ineligible for SAQ A, C-VT, and P2PE) because the VoIP traffic with account data is still moving through the merchant environment as shown in section 6.4.1.2 of the PCI Information Supplement on Protecting Telephone-Based Payment Card Data. The call routing should occur outside the merchant environment to keep it out of scope and achieve eligibility for SAQ A as shown in section 6.4.1.1 of that document.

Regardless of the method used, the merchant must outsource to a PCI DSS compliant TPSP. This is explicitly required in SAQ A.

Only six requirements in SAQ A usually apply to an outsourced telephone payment process with no paper, making for a very easy compliance program:

• Requirements 12.8.1-12.8.5 related to managing the PCI DSS compliance of the service provider
• Requirement 12.10.1 for an Incident Response plan

Change How Telephone Payments are Processed

The eligibility criteria for SAQs B, B-IP, and C all prohibit electronic storage of account data, and SAQ B-IP prohibits transmission of account data from anything other than the approved payment terminal device, but none of them prohibit receiving electronic account data. Effectively this means a payment process receiving account data via VoIP could be eligible for these SAQs even though it would be ineligible for SAQs C-VT and P2PE. Yes, dear reader, this makes absolutely no sense, but as a QSA we conduct our assessments according to the text of the official documents.

SAQ B

SAQ B is only for payments keyed into dial-out terminals using POTS lines. These terminals would need to replace the use of a virtual terminal under SAQ C-VT or the P2PE solution terminals under SAQ P2PE.

There is some advantage to replacing a virtual terminal with dial-out terminals as SAQ B for dial-out contains less requirements than SAQ C-VT for virtual terminals.

This advantage goes away when replacing P2PE terminals, as SAQs P2PE and B have roughly the same number of applicable requirements. It’s likely cheaper and easier for merchants to use POTS lines to replace their VoIP phones and achieve eligibility for SAQ P2PE rather than buy new dial-out terminals to replace a P2PE solution.

SAQ B-IP

SAQ B-IP is for payments keyed into IP-connected payment terminal devices. A P2PE solution could be made eligible for SAQ B-IP without replacing any hardware. Merchants using a virtual terminal under SAQ C-VT would need to buy and use hardware terminals as part of a P2PE validated solution.

The main challenge when using SAQ B-IP is that the payment terminal hardware must be isolated from all other merchant systems as per the eligibility criteria:

This should be considered as part of the design when deploying new hardware terminals to replace an SAQ C-VT virtual terminal, but is also a concern when replacing or reusing existing P2PE terminal deployments. One of the advantages of a P2PE solution is that the terminals often do not need to be isolated, but a merchant ineligible for SAQ P2PE due to the use of VoIP must isolate the terminals to become eligible for SAQ B-IP.

SAQ C

SAQ C is for payments keyed into a payment application. The application would need to replace the use of a virtual terminal under SAQ C-VT or the standalone P2PE solution terminals under SAQ P2PE.

Deploying a payment application is a significant effort, and SAQ C contains many more requirements than the other short SAQs discussed here. This solution is only recommended for merchants that already have an existing payment application eligible for SAQ C that they can begin using for telephone payments.

Transactions can be keyed directly into the payment application, effectively replacing the virtual terminal website with the payment application itself. Merchants that previously used SAQ P2PE may also connect their hardware terminals to the payment application as is typical of a POS system.

Some merchants try to use their own eCommerce as the payment application under SAQ C, but this raises some potential issues with the SAQ C eligibility criteria which state that the payment application must be on the same devices or LAN, and that the payment application is isolated from all other merchant systems:

• “The merchant has a payment application system and an Internet connection on the same device and/or same local area network (LAN)”
• “The payment application system is not connected to any other systems within the merchant environment (this can be achieved via network segmentation to isolate payment application system/Internet device from all other systems)”

Modern eCommerce sites are often hosted by third parties, which would violate the first of these eligibility criteria, and eCommerce sites often connect to various other merchant systems, which would violate the second of these eligibility criteria. Determining whether an eCommerce site is eligible for SAQ C would be on a case-by-case basis depending on how the eCommerce site is deployed and configured.

Apply All PCI DSS Requirements

If none of the options above are feasible, the only remaining option is to apply all of the PCI DSS requirements from SAQ D Merchant to the telephone payment process. This is generally not recommended unless absolutely necessary due to the number of requirements that will be applicable and the amount of effort required to document compliance.

There will likely be many requirements from SAQ D that are not applicable to a telephone payment process because the merchant is not performing an activity that the requirement applies to. The merchant will need to individually justify why these requirements are not applicable when completing an SAQ (a form for this is in Appendix C of the SAQ template) or ROC (the QSA or ISA will handle documentation). For example, a merchant can justify the non-applicability of Requirement 3 (Protect Stored Account Data) if account data is never stored.

The following is a rough outline of PCI DSS requirements that usually do not apply to simple telephone payment channels, assuming the merchant:

• Is using a virtual terminal
• Has no wireless in or connected to the CDE
• Is not storing account data in any format (e.g., call recordings or paper slips)

This list contains 103 sub requirements from PCI DSS (including the appendices and some other requirements not in SAQ D Merchant), which leaves 177 potentially applicable requirements. This is not an official list, and merchants will need to individually confirm the non-applicability of these requirements to their environment.

Some of the remaining applicable requirements may be handled by the provider of the virtual terminal solution, e.g., they may take responsibility for much of requirement 4 related to the encryption of transmitted account data. Merchants should contact their service provider for information on the sharing of PCI DSS responsibilities as per requirements 12.8.5 and 12.9.2 and adjust the list of applicable controls accordingly.

QSA Gripes and A Way Forward

As a QSA, writing this post brings me no joy; it is instead a task made necessary by collisions between various documents released by PCI SSC over the span of more than a decade that has led to nonsensical conclusions and confusion (made worse by processors that only relatively recently began enforcing this interpretation). As a QSA, I am not free to rewrite PCI DSS the way I see fit and can only assess the requirements in accordance with the text of the standard and guidance provided to me by PCI SSC. This post was an attempt to help our clients (and maybe other QSAs and ISAs struggling with the same issue) find a path through the nonsense.

I believe the PCI SSC guidance to treat VoIP traffic the same as any other network traffic makes sense (even though it may not have when the VoIP FAQ was published in 2012). Advances in voice recognition in the years since that FAQ was released make it much easier for an attacker to automatically extract a list of card numbers from intercepted VoIP traffic. If this wasn’t a real threat then, it definitely is now.

In that spirit, I will admit that it frustrates me that VoIP is treated differently depending on what the merchant keys account data into after sounds arrive at their ears. If the concern is that an attacker may intercept the VoIP audio, this concern should apply equally to any payment channel with VoIP regardless of what the data is keyed into. This would logically leave two options to resolve this conundrum and create consistency (of which I prefer the first option):

1. Adjust the shorter SAQs discussed here so that merchants using VoIP are eligible for all of them while adding requirements that only apply to VoIP, just like various SAQs already contain requirements that only apply to paper records.
2. Make merchants using VoIP ineligible for any of the shorter SAQs if PCI SSC deems only the full set of PCI DSS controls sufficient to address VoIP risks.

Adding to this, it frustrates me that the current situation with the interaction between SAQ eligibility criteria and VoIP guidance leaves SAQ C-VT nearly useless in a world that has almost completely transitioned to VoIP. I do not think that was the intent of PCI SSC, but I cannot ignore the plain text of the eligibility criteria and VoIP guidance to allow merchants to use C-VT because I think I can read minds. This is unfortunate because SAQ C-VT used to be a great tool in the heyday of POTS lines.

An update to the telephony guidance document referenced above is also on this QSA’s wish list. It’s easy to say VoIP traffic should be treated “just as other IP network traffic containing payment card account data would be”, but in practice VoIP is often poorly understood, even by the people managing it (and, I hate to say, some QSAs). It is still often seen as something 'other' than regular network traffic, like the old POTS system was somehow teleported into Ethernet, rather than just another IP-based network protocol like HTTPS. The rise of VoIP softphones running on workstations in applications that don’t even feel like phones (e.g., Microsoft Teams) and cloud-based VoIP solutions muddy these waters further for people who don’t understand how VoIP works.

I would appreciate something official from PCI SSC to clear this up further because I find myself explaining all too often why a merchant is not (and never should have been) eligible for SAQ C-VT, why the applicable number of requirements seemingly tripled overnight, why not recording calls doesn’t take VoIP out of scope, why encryption doesn’t take VoIP out of scope, why hardware VoIP phones and any device running a softphone are part of the CDE, and why anything on the same network as VoIP phones and devices with softphones is dragged into the PCI DSS scope (but this would all go away if you reinstalled POTS lines).

Here’s looking forward to the public comment period for the next revision of PCI DSS—this QSA will certainly have a few things to say.