PCI DSS Compliance 

If your customers speak their payment information to agents in your call centre who then enter the details into their desktop, it opens your organisation to all kinds of compliance issues, including:

  • 222 security controls that need to be applied to the desktop and the network it operates on.
  • Ensuring Sensitive Authentication Data is not stored on call recordings.
  • Minimising the risk of a security breach by vetting new agents with the Criminal Records Bureau (an expensive and time consuming process for hundreds of agents).
  • Making sure data cannot be removed by any means (usually by banning pens and paper and mobile phones).

Cardholder data such as the Primary Account Number (PAN) can be stored if it is encrypted either in systems or on call recordings. However, section 3.2 of the PCI DSS (version 1.2) states that sensitive authentication data, which includes the CAV2/CVC2/CVV2/CID/CW numbers, cannot be stored – even when encrypted.

Because most call centres record all of their calls for auditing, training and coaching, this sets a difficult challenge. In the past, three methods have been used to ensure PCI compliance:

Automated IVR payment solutions: Using voice recognition or keypad entry, these systems allow payments to be taken without the card details being recorded. However, customers are likely to drop out at the first sign of any difficulty, meaning they end up giving their payment details to an agent.

PCI compliant call recording solutions: Pausing the call recording at the moment a payment is being taken is often suggested as a way for call centres to comply with PCI DSS. But with this method, both the agent and the desktop they are using are still within scope for PCI DSS, as the sensitive data passes through them.

Encryption of call recordings: Many organisations believe that encrypting their call recordings will manage the risks of storing sensitive card data. However, the CVC security code should not be stored under any circumstances, even if it is encrypted.

Semafone believes that these alternative PCI solutions have failed to provide a comprehensive answer to the problem and that a far simpler remedy is to stop sensitive payment information from entering your systems in the first place. This takes your call centre out of scope for PCI DSS and has the added benefit of reducing fraud risk. Read more about the Semafone solution. 

 
Data Element
Storage PermittedProtection Required
PCI DSS Req. 3.4
Cardholder Data Primary Account Number (PAN) Yes Yes Yes
Cardholder Name Yes Yes* No
Service Code Yes Yes* No
Expiration Date Yes Yes* No
Sensitive Authentication Data Full Magnetic Stripe Data No N/A N/A
CAV2/CVC2/CVV2/CID No N/A N/A
PIN/PIN Block No N/A N/A

*These data elements must be protected if stored in conjunction with the PAN.  This protection should be per PCI DSS requirements for general protection of the cardholder data environment. Additionally, other legislation (for example, related to consumer personal data protection, privacy, identity theft, or data security) may require specific protection of this data, or proper disclosure of a company's practices if consumer-related personal data is being collected during the course of business. PCI DSS, however, does not apply if PANs are not stored, processed, or transmitted.

Sensitive Authentication Data must not be stored after authorization (even if encrypted).

Because most call centres record all of their calls for auditing, training and coaching, this sets a difficult challenge. Different methods have been employed to work around the problem (click here for details), but until now no single solution has resolved the issue of PCI compliance.

Semafone ensures that no sensitive information is recorded or stored in contact centre systems, vastly reducing the burden of the PCI DSS. Plus, the agent does not hear the payment details, which eliminates the risk of security breaches. Find out more