I've seen some emails about this. Does anyone understand what it all means?

If you mean PCI compliance for handling any credit/debit card details. With regards to call recording, I understand for PCI compliance it is necessary to switch extension side recording off when credit/debit card details are given.

Hi,

PCI DSS is basically a standard endorsed by major Credit/Debit card providers and should be adhered to if your company accepts or stores Credit/Debit card information.

It's not a law kind of more like industry compliance guidelines.

Here's a link to the website.

https://www.pcisecuritystandards.org/index.htm

I've read that VISA and other card providers are set to charge "fine" Companies heavily if there is a case where cardholder data laxity is traced back to a company and that the company may lay itself open to being sued for large amounts by the cardholder.

Has anyone heard of software to avoid this?

A previous post from Paul Miller mentioned PCI DSS and recording of telephone calls. Recording is not required to stop during the taking of the actual credit card number itself (1234 1234 1234 1234), but companies are not allowed to store (in any form including audio) the 3- or 4-digit security code from the back of a card.

(With the disclaimer that I work for Veritape), you may be interested in some further information related to PCI DSS and recording telephone calls we posted recently here .

CR.

Companies are likely to pay higher charges to the card companies if they are not PCI DSS compliant.

The standards also call for encryption (depending on your recording architecture) and a strong audit trail capability to be able to review who has listened to what and when. If you use screen recording then some data needs to be masked at the point of recording.

This has become a hot topic for any organisation that handles card transactions - but the big companies are going to be hit the hardest and first.

With respect to Jeremy Jackman's question - all of the major call recording solution providers have claimed PCI-DSS compliance. I beleive that some are further down the line than others but if you stick with a major player you should have a solution available shortly. Despite what Cam's article says - you can be PCI compliance in a trunkside recording solution.

If you were running on a hosted platform, which Company would you go to to obtain a compliant package?

A year on from the previous post in this topic, and the world of PCI DSS has become a lot clearer, and most organisations are now compliant. Or are they?

According to The Logic Group, a company which researches this market, only 15% of companies taking credit card payments are compliant, and that's not increased much since last year (see here for the report). It's not stated, however, how many companies were surveyed, and how the mix between the larger Level 1 Merchants and smaller companies is represented.

I suspect that there are still a lot of contact centres with questions about how PCI DSS applies to them.

So, in the spirit of trying to encourage some conversation, here's a few thoughts for us to consider:

1. Do you know what PCI DSS is?
1b. Does it apply to your company?

2. How is it impacting your business at the moment?
2b. How has it impacted your business in 2008 as a whole?

3. What (if anything) remains unclear for you, about PCI DSS?

4. In 2009, what do you think will change in your company to address PCI DSS?

CR.

Just a note that last Friday the PCI DSS clarified their position on storing credit card details in recorded telephone conversations.

If you are able to log in to the PCI's Talisma server (you'll know what that means if you can), then here is the new text.

If you can't log in, then we've repeated the text on PCI DSS and call recording here

CR.

Thanks for posting that,

It makes things slightly clearer now, although there's
still mud in the water :-)

Regards

DaveA

Once again (twice within a month) the "Frequently Asked Questions" on call recording have been changed by the governing body of the payment card industry, the PCI SSC. We have a summary here: http://www.veritape.com/2010/02/pci-dss-compliant-call-recording-in-call-centres-latest-changes-to-faq-by-pci-ssc-on-18-feb-2010/

CR.

It seems obvious to me that call recording must be switched off or DTMF tones that the caller creates entering a number of any kind will be recorded and therefore could be hacked.
The NewVoiceMedia PCI DSS compliant IVR switches off call recording during the IVR and then if the call centre requires recording it can be switched on again afterwards before the call is returned to the agent.
There is no agent on the line to listen to the DTMF.

Based on the revised statment from the council is it a requirement that the call recording server be encrypted?

It is a violation of PCI DSS requirement 3.2 to store any sensitive authentication data, including card validation codes and values, after authorization even if encrypted.
It is therefore prohibited to use any form of digital audio recording (using formats such as wav, mp3 etc) for storing CAV2, CVC2, CVV2 or CID codes after authorization if that data can be queried; recognizing that multiple tools exist that potentially could query a variety of digital recordings.
Where technology exists to prevent recording of these data elements, such technology should be enabled.


It is obvious therefore that Call Recording should be turned off during the presentation of the Cardholder Data. Encryption of the call recording is not valid.