Over a billion old call recordings containing millions of payment card details are being stored by thousands of UK merchants in environments that fail to comply with Payment Card Industry Data Security Standards (PCI DSS).
These recordings, referred to as toxic legacy call recordings, affect large UK merchants ranging from household retail brands to local government authorities.
Thanks to insufficient data security protocols, these card details can be accessed, downloaded and sold on the black market. Such were the claims aired at the PCI London conference on July 2, 2013.
The consequences for Level 1 and Level 2 merchants falling foul of PCI-DSS due to non-compliance or compromised payment card details includes fines of up to £500,000 per breach. Besides: the potential damage to an organisation’s brand.
The issue of toxic legacy data has come about because many organisations are required by the Financial Conduct Authority (FCA) to retain and protect call recordings in case they are needed during the resolution of complaints or disputes, or for regulatory reasons. Some companies subject to financial sector regulations have policies to store recordings for up to seven years.
However, FCA rules conflicts with PCI DSS regulations that only permit merchants to store payment card details for a legitimate reason and, if they have to, to protect that data to the PCI standard. Although new methods can stop payment card data being recorded during calls made today, historical calls recordings stretching back many years do contain payment card data, and these recordings foul of the PCI regulations.
Recent figures from the UK Cards Association suggest that Britons spend almost half a trillion pounds on plastic each year, with nearly 10 billion separate card transactions taking place. Of these card transactions, 256 million were made over the telephone in 2012 according to UK Payments Administration.
Matthew Bryars, CEO of card security software firm Aeriandi, estimates that while the proportion of recorded calls that contain payment card data will vary, they could easily rise above half in contact centres processing large numbers of card not present (CNP) transactions.
Bryars says: “We believe up to one billion call recordings containing toxic legacy data now exist in the UK as a subset of the tens of billions of overall call recordings made over the past seven years. While it’s fine for most call recordings to be stored in any old storage system, any legacy toxic call recordings must be stored within PCI DSS requirements.”
Bryars cites the example of a tier one merchant, a household brand, that processes six million card payments at its contact centres each year. This company alone was found to hold over 140 million old call recordings, up to a third of which contained payment card details, that had to be shifted into a secure, PCI-compliant repository.
He says: “This example is the exception in that it took rapid steps to address the problem. In most cases toxic legacy data is an issue that most business leaders either don’t know exists, or have yet to address.”
Payment card data stolen from call recordings is most likely to be used for CNP fraud, which cost UK merchants £220.9 million in 2011. CNP has become the largest segment of card fraud, accounting for 65% of all card losses according to the Financial Fraud Action (FFA UK).
Bryars adds: “Over the past 24 months I’ve met with many public and private sector organisations that take payment card data over the phone and – without exception – they all recognise that they have inherited a major toxic legacy call recording problem. However, few have yet to take any meaningful steps to migrate this toxic data into a secure and compliant data centre which means, for now at least, there is a very juicy new payment card target for opportunistic bad guys to exploit. These merchants have an obligation to wake up to the issue of legacy toxic call recordings, and take urgent steps to deal with it.”
About Aeriandi
Aeriandi specialises in PCI-DSS compliance and implements solutions that take sensitive card data out of contact centres so they can meet FSA and PCI-DSS obligations.
Meanwhile, the PCI Security Standards Council (PCI SSC), the forum for the development of payment card security standards, published recently version 4.0 of the PIN Transaction Security (PTS) Point of Interaction (POI) requirements.
These requirements, with the Hardware Security Module (HSM) requirements provide standards for device manufacturers to ensure merchants and others have secure devices for accepting and processing payment cards.
Point of Interaction (POI) devices, such as PIN entry devices, continue to be a primary method for accepting and processing credit payment cards and a target for criminal attack. As part of its ongoing standards development process, the PCI Council makes updates based on industry needs and changing threats, to ensure the strongest technical standards for payment security.
Changes introduced in version 4.0 of the PTS POI requirements focus on increasing the robustness of the devices through enhanced testing procedures and streamlining the evaluation and reporting processes for both device vendors and testing labs.
The PTS POI requirements are updated on a three-year cycle, based on feedback from the PCI community. The development process also allows for minor update releases as needed – in October 2011, for example, the Council issued version 3.1 to support deployment of point-to- point encryption (P2PE) and mobile technologies. The new version builds on these updates to underscore the requirements’ applicability to traditional POI deployments – including Point-of- Sale devices, unattended kiosks, mobile dongles – and many other types of devices.
Changes include:
• Restructured Open Protocols Module – helps ensure POI devices do not have communication vulnerabilities that can be remotely exploited to gain access to sensitive data or resources within the device

• Enhanced interface testing and logical security requirements – by requiring more stringent documentation and assessment of all interfaces of the device, will help ensure that no interface can be abused or used as an attack vector
• Added source code reviews – additional mandatory source code reviews enhance the robustness of the testing process
• Introduction of a vendor provided security policy – provides guidance that will facilitate implementation of an approved POI device in a manner consistent with the POI requirements, including information on key management responsibilities, administrative responsibilities, device functionality, identification, and environmental requirements
The requirements are available on the PCI SSC website at: https://www.pcisecuritystandards.org/security_standards/documents.php
