White Paper Call recording – How to meet PCI compliance Revision 1.0 January 2008 Author: Robert Wright ([email protected]), BSc (Hons) © Ultra Electronics AudioSoft, October 2008. Whilst Ultra Electronics AudioSoft makes every attempt to ensure the reliability of the information contained in this document, we cannot assume responsibility for its accuracy. We duly acknowledge all trademarks and names mentioned. Web: www.ultra-audiosoft.com Tel: +44 (0) 1285 883800 Call recording – how to meet PCI compliance _____________________________________________________________________ 1.0 Introduction PCI compliance affects all call centres taking credit and debit card information. Only certain data from these transactions can be stored and precautions need to be in place so that this data is secure. In particular, CVC2/CVV2/CID codes (the three/fourdigit security number on the back of your card), may not be stored subsequent to authorisation, even if encrypted. This requirement can conflict with a business recording calls for training and quality purposes or even to meet legislative requirements. This white paper examines how businesses can remain PCI compliant whilst still recording phone calls. 2.0 PCI legislation A payment card transaction (via credit or debit card) may take place in several ways. This white paper considers transactions taken over the phone. It is usual for the following information to be taken for the purposes of processing the transaction: 1) Primary Account Number (PAN): The long number on the front of the card 2) Cardholder’s name 3) Expiry date 4) Issue number (when available) 5) Valid from (when required) 6) CVC2/CVV2/CID code: The 3- or 4-digit security number on the back of the card The Primary Account Number, 1, may be stored but must be protected, the definition of which is presented in Section 3.1. Items 2-5 may also be stored. They may not necessarily have to be protected if they are not collected with 1 but, in general, they will be collected with 1 and need to be protected. Whereas items 1-5 fall under the heading “cardholder data”, item 6 is classified as “sensitive authentication data”; item 6 may not be stored subsequent to authorisation, even if encrypted. This is clearly the most difficult condition to satisfy when recording calls and is dealt with in Section 3. 3.0 Staying compliant The requirements set out by the Security Standards Council that are particularly relevant to call recording are split into three sections: Section 1: X Building and maintaining a secure network X Encrypt transmission of cardholder data across open, public networks X Use and regularly update anti-virus software or programs 2 © AudioSoft 2008 Call recording – how to meet PCI compliance _____________________________________________________________________ These are standard network security conditions; if the call recorder is networked then the same safeguards need to be included on the recorder as any networked PC. This is straightforward to achieve. Alternatively, the voice recorder can be standalone and so the above requirements are irrelevant. Section 2: X Develop and maintain secure systems and applications X Restrict access to cardholder data by business need-to-know X Track and monitor all access to network resources and cardholder data The above conditions can be met through choosing a call recorder with: X Ability to encrypt data (e.g. 128 bit encryption) X Data stored in proprietary format X Each user given a username and password (separate to Windows) X Permission set configurable by function for each user / group X Audit trail of all user activity X Automatic log-out after a certain period of inactivity X Ability to set temporary access rights and expiry conditions Section 3: X Protect stored cardholder data (e.g. PAN) X Do not store CVC2/CVV2/CID code Reference [1] states that (“The MINIMUM account information that must be rendered unreadable is the PAN” and that “Only companies that have undertaken a risk analysis and have legitimate technological or documented business constraints can consider the use of compensating controls to achieve compliance”. [1] is also clear that the CVC2/CW2 code may not be stored after the transaction has taken place. If recording calls, the process needs to be carefully thought out so as not to contravene these rules. Blanket recording every second of every call on every line is likely to record card details that may not be stored so one needs to be selective about what is recorded. This may be achieved through: 1) Only recording lines that are not taking payment: This is unlikely to be practical for most organisations as they may not know which lines will be taking payments and will still want to monitor the calls in which payment is received. 2) Provide each agent with a pause switch to be used when taking payment and unpaused when the payment has been taken. As well as being technically difficult to achieve with a modern, centralised system, this puts added pressure on the agent at a crucial time in the sale and is likely to lead to mistakes in taking credit card information and forgetting to pause or unpause the recording process. 3) Provide an automatic way of removing the payment card information immediately after the call is completed. This is clearly a preferential choice to 1) and 2) as all call information will be preserved with the exception of the payment card information. 4) Use an integrated audio and screen recording system to pause audio recording using a trigger from the screen (such as moving to the payment box to enter credit card information). This solution is also preferential to 1) or 2) but is likely to be complex and costly to implement, with the cost increasing per agent. It is therefore not considered further in this white paper but further details on integrated screen and audio recording are available from AudioSoft 3 © AudioSoft 2008 Call recording – how to meet PCI compliance _____________________________________________________________________ on request. Instead this white paper will focus on solution 3), as the costs scale much better with the number of agents than solution 4). In order to achieve 3 automatically, it is necessary to employ key word spotting, an audio mining tool. Each agent will likely already have a script for a sales call, including when to ask for what payment card information. For example, the agent will typically say the following in the payment process: X X X X X X X “How do you want to make the payment?” “What type of card is it?” “Can I have the card number?” “Expiry date?” “Valid from?” “Please can I have the last three digits on the back of the card” “Thank you, your transaction has been processed” One can use key word spotting to search for the words that the agent says at the start and at the end of taking the payment and set a rule to delete this part of the recording. Using key word spotting straight after the call has ended, one could search all recordings for the first and last phrases and delete the part of the recording that falls between them, thus ensuring that all but the payment part of the call is recorded, allowing for quality monitoring and training whilst remaining PCI compliant. Please consult your call recording supplier for how you can use key word spotting to ensure that your calls can be recorded without affecting your PCI compliance. ..Benefits of Key-word spotting…………………………….. X Record calls but not payment card information X No extra requirements on agents X Remain PCI compliant ..When can this tool be used?…………………………………………………………..... X In any call recording situation where the call is stored in a non-proprietary format; please consult AudioSoft for further information. 4.0 References 1. PCI Security Standards accessed on 15/01/2008 web-site: https://www.pcisecuritystandards.org/ 5.0 Bibliography CSC – Card Security Code (CSC) / Card Verification Value or Code (CVV or CVC) PAN – Primary Account Number 4 © AudioSoft 2008