On January 22, 2010 the PCI SSC issued an update to their clarification regarding their FAQ on call centers storing CVV/CVC/CID in their call recordings. The bottom line is that call centers are no longer allowed to store such cardholder information in recordings that are maintained digitally, regardless of whether they are encrypted.
The new FAQ (#5362) states that:
“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; as card data can easily be extracted using freely available software.
On an exception basis, storage of CAV2, CVC2, CVV2 or CID codes in an analog format after authorization is allowed; as these recordings cannot be data mined easily. However the physical and logical protections defined in PCI DSS must still be applied to these analog call recording formats.
Audio recording solutions that prevent the storage or facilitate the deletion of CAV2, CVC2, CVV2 or CID codes and other card data are commercially available from a number of vendors. All other recordings containing cardholder data captured by call centers must be protected in accordance with the PCI DSS, including PCI DSS requirement 3.4.”
I am assuming that this change in policy is the result of the PCI SSC determining that, regardless of what we have been told in the latest reports from Verizon Business Services and other sources, there have been breaches of cardholder data that were the result of compromising digital audio recordings.
A big thank you to Emma Jenkins at VeriTape for pointing out this change.
UPDATE: It appears that the FAQ has been changed again. It now reads “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.” adding back the “if that data can be queried” language. There are plenty of commercial and open source tools that will search audio recordings, so of course this data can be queried. Not sure of the motive here in this change.
