As a member of the global Payment Card Industry Security Standards Council (PCI SSC), we welcome the updated guidance on protecting payment card data in contact center environments. The tech landscape has evolved significantly since 2011 (which is when the initial version of the guidance was introduced), and fraud rates have continued to balloon since then (according to our research, almost half of US consumers have had their data compromised). With 72 percent of contact centers accepting card payments over the phone, we believe it’s more important than ever to standardize payment processes and secure sensitive payment data shared over voice channels.
We recently partnered with Verizon on a white paper examining contact center challenges in achieving sustainable PCI DSS compliance. Conclusions from the study found that 60 percent of organisations are still leveraging outdated pause-and-resume technologies to avoid storing sensitive data on call recordings. In order to align with new guidances and avoid disrupting a seamless customer experience, businesses must move away from their reliance on antiquated systems. This means businesses must replace pause-and-resume systems with modern Dual Tone Multi Frequency (DTMF) masking technology. By doing so, they’ll be able to eliminate data breaches at the contact center level by preventing payment data from entering the environment. This helps to reduce fraud loss by ensuring that, in the event of a breach, data will not be compromised.
Here are key considerations to be aware of:
- CNP fraud only needs PAN, expiry, cardholder name, and possibly CVV2. All of these and other personal data like address are captured during telephone payment conversations with contact centers.
- Transmissions over ‘good old fashioned’ PSTN are considered out of scope as man-in-the-middle attacks are considered low, but everything on the company’s side (from answering machines to relaying the call via PABX/SBC) is in scope.
- Transmissions over VoIP are considered in scope (including carrier’s VoIP networks if they do anything but just provide SIP trunks), and should be protected as normal (encryption, etc.).
- TelCos are out-of-scope for PCI compliance with respect to their public network, but can be in-scope if they provide other services relating to PCI data.
- Good diagrams shows how PCI data (even to a single call agent) renders the whole organisation in scope, showing how segmenting call agents off via firewalls, etc. can reduce scope (however, this requires properly implemented and thorough segmentation, and can cause issues if a low-security area is improperly segmented off from the PCI-handling part).
- People handling payment calls must be trained/screened/handled as per PCI DSS, as must people handling payment devices or payment records with PCI data, including the people managing those people. All of their equipment must be secure as well, including homeworkers, which can interfere with more modern working arrangements and complicate matters for more progressive businesses/businesses with injured workers or workers with children.
- Unless you’re an issuer or an issuer’s supplier (or have legal obligations preventing you), if you get CVV2, you must irretrievably erase this data post-call (and stop any manual records/copies ever being made). Even if you must retain this data as specified, it must be highly secured and non-queryable (can’t be automatically indexed or searched). The need to retain call recordings is not permitted as excuse to hold CVV2, requiring secure deletion of CVV2 promptly upon call’s end. This makes tokenization a useful option as it allows for repeat payments without re-taking data.
- DTMF is explicitly named as in-scope, with DTMF masking/suppression named as a solution.
- The document explicitly suggests minimising the amount of PCI data taken via telephony by outsourcing to PCI DSS validated service providers (amongst other options).
- Any DTMF bleed (often caused by slow-reacting DTMF detection) is called out as a problem and as potentially rendering a descoped environment in-scope.
Pause-and-resume technology is shown as not really descoping much even if you do firewall off the recording hardware, as well as detailing issues (e.g. sporadic data capture due to agents failing to pause correctly, loss of call recordings due to agents failing to restart recordings).