PCI Compliance for Call Recording
•Download as PPTX, PDF•
1 like•773 views
Everything you need to know about achieving PCI compliance when recording calls where payments are made and the different options available.
Recommended
Recommended
More Related Content
More from Business Systems (UK) Ltd
More from Business Systems (UK) Ltd (17)
Recently uploaded
Recently uploaded (20)
PCI Compliance for Call Recording
- 1. PCI Compliance for Call Recording Atiq Rehman Copyright Business Systems UK Limited 2013
- 2. PCI Compliance – What Is It? • PCI – Payment Card Industry • PCI DSS – Payment Card Industry Data Security Standard - Security standard for organisations that handle cardholder information for the major debit, credit, prepaid, e-purse, ATM, and POS cards - PCI Security Standards Council formed by leading card providers … ∙∙→ Copyright Business Systems Copyright Business Systems UK Limited 2013 UK Limited 2010
- 3. Who Does This Apply To? All organisations or merchants regardless of size or number of transactions. Are There Any Implications For Call Recording? Yes, As Per PCI SSC FAQ 5362: “It is a violation of PCI DSS Requirement 3.2 to store any sensitive authentication data .... after authorisation even if encrypted. It is therefore prohibited to use any form of digital audio recording for storing CAV2, CVC2, CVV2 or CID codes if that data can be queried. Where technology exists to prevent recording of these data elements, such technology should be enabled.” ∙∙→ Copyright Business Systems Copyright Business Systems UK Limited 2013 UK Limited 2010
- 4. PCI DSS – Storage Of Info ∙∙→ Copyright Business Systems Copyright Business Systems UK Limited 2013 UK Limited 2010
- 5. PCI DSS – Storage Of Info km ∙∙→ Copyright Business Systems Copyright Business Systems UK Limited 2013 UK Limited 2010
- 6. PCI DSS – Storage Of Info ∙∙→ Copyright Business Systems Copyright Business Systems UK Limited 2013 UK Limited 2010
- 7. Consequences of Non Compliance • Monthly Fines for Non-Compliance • Withdrawal of Merchant Services • Erosion of Customer Confidence Only 5% of people are confident that financial data will be safe when given to an agent over the phone* 86% of consumers believe agents will misuse their personal card details* MONTHLY FINES Initially £3,500 - £65,000 Now up to £250,000 *Source: Survey of 1,000 UK consumers conducted by OnePoll on behalf of Eckoh ∙∙→ Copyright Business Systems Copyright Business Systems UK Limited 2013 UK Limited 2010
- 8. PCI Compliance For Call Recording 1 – Automated Payments via IVR 2 – Transfer Callers To Non Recorded Agents 3 – Turn Off Call Recording Poor Customer Experience ∙∙→ Impact on operational processes & productivity Increase average call duration Implications for dispute resolution /fact verification Copyright Business Systems Copyright Business Systems UK Limited 2013 UK Limited 2010
- 9. PCI Compliance For Call Recording 4 – Modify the Recording Solution Security Permissions Good practice but not enough Media Encryption “It is only the Primary Account Number (PAN) that can be retained in encrypted format. Sensitive Authentication Data, a key part in card transactions, cannot be stored whether encrypted or not.” Audio Masking Audio tone inserted over card details, but still retains sensitive authentication data Manual Pause / Resume of Recordings “Organisations must remove sensitive authentication data from recordings with no manual intervention by your staff.” ∙∙→ Copyright Business Systems Copyright Business Systems UK Limited 2013 UK Limited 2010
- 10. PCI Compliance For Call Recording 4 – Modify the Recording Solution Automated Pause / Resume of Recordings When agent enters payment details on screen, a trigger is generated to stop the recording API Driven Automated Mute / Un-mute of Recordings Similar to pause & resume but mutes the recording rather than stops it so you don’t have 2 separate unlinked recordings DTMF Collection of Payment Details Caller keys in credit card details via handset with phone system passing details directly to payment application ∙∙→ Copyright Business Systems Copyright Business Systems UK Limited 2013 UK Limited 2010
- 11. Our Recommendations • Security – Permissions • Security - Firewall • Media Encryption Used for Both Audio and Screen Recording • Automated Pause / Resume Desktop Based or API Driven OR • DTMF Collection of Payment Details ∙∙→ Copyright Business Systems Copyright Business Systems UK Limited 2013 UK Limited 2010
- 12. Getting it right Continue to monitor – make changes if required Test & validate End to end testing Consult with a PCI DSS QSA PCI COMPLIANCE Reduce cost & risk – suppliers who regularly integrate PCI solutions Leverage proven expertise ∙∙→ Minimise disruption and impact on business Options budget Copyright Business Systems UK Limited 2010 Copyright Business Systems UK Limited 2013
- 13. PCI Best Practice Guide Covers: • Options for compliance • Approaches to call recording • Getting PCI compliance right Complimentary copy:Available here > Copyright Business Systems UK Limited 2010
Editor's Notes
- As some of you have probably already had some sort of dealing with PCI you may already know this but for those of you that haven’t had the pleasure then let’s start by defining the PCI and PCI DSS acronyms. PCI is the Payment Card Industry and the PCI DSS is the PCI Data Security Standard. This is the set of rules that an organisation that handles card payments has to adhere to which has been put together by the PCI Security Standard Council, which was formed by leading card providers that include companies such as Visa, Mastercard and American Express to name a few.We’re now going to go in to a bit of detail around PCI Compliance but before we do here’s a little animation to get you in the mood ....
- Well, broadly speaking anyone and everyone that takes payments via card. It doesn’t matter if you are a small shop or a large retailer, you are affected. Now for certain organisations depending on the method used for card payment processing and the number of transactions there is an option to self certify but for anybody else it is normally advised to use a PCI QSA (Qualified Security Assessor) who can audit and advise and help you get PCI certified. For call recording purposes there are actually specific guidelines which we will cover next but in general as you can see from the quote here ‘It is a violation of PCI DSS to store any sensitive authentication data .... after authorisation even if encrypted. It is therefore prohibited to use any form of digital audio recording for storing CVV2 numbers if that data can be queried. Where technology exists to prevent recording of these data elements, such technology should be enabled.”
- So for general PCI Compliance and what can be stored and what can’t this handy table shows you at a glance. There are three main entities that can affect call recording environments and these are firstly, the Primary Account Number (or PAN or the long number across the card). This can be stored but it must rendered unreadable. Now in call recording terms as it is an audio file it is already unreadable but because it the audio file could be processed via some Audio Analytics engine and de-cyperherred the recommended method of rendering the data unreadable is to use some sort of encryption.
- Next, The expiration date is normally recorded on a call but as you can see the capturing and storing of this is permitted as it doesn’t really give away anything useful.
- However the next item is a critical component and that is the 3 digit security number from the rear of the card. It is typically also called CVV but may be called other things. As anybody who has paid for anything online or via the phone will tell you this number is almost always asked for now and it is used to prove that the person on the phone has (or is more likely to have) the card in front of them and therefore is more likely to be the real owner of the card. This number cannot be stored in any way.
- Now before we go in to the ways of dealing with the PCI regulations and how to be PCI compliant when using a call recording system here are some consequences of not being PCI compliant. From what we know about the way this is enforced is that if there is a breach then an investigation takes place and if you are found to be in breach of the PCI regulations then you can have various penalties applied.Firstly there could be fines applied and these are now quite hefty in nature, up to £250,000 which could be monthly and ongoing until a resolution is reached. They would normally start off a lot lower but increase as months went by. We have actually had customers who have urgently needed to become PCI Compliant as they have been fined – obviously we can’t name names but it is important to know that it is happening and is not just a case of idle threats. In fact, even if you are 100% PCI compliant and then have a breach of some sort you may still be fined but this is likely to be a lot lower but based on how many cardholder’s data was lost.Next we have the potential penalty of losing your merchant services altogether. If warranted the card providers can simply decide to no longer allow you to take card payments. How long can a business survive if it can’t take card payments any more? And then we have the one thing that if lost may never be restored and that is customer confidence. Most of you here are involved in contact centres and have to ensure that customers feel valued and trust you unreservedly. However according to polls only 5% of people feel confident that the data they give over the phone will be secure and 86% of consumers think that agents will misuse their personal data in some way. That is a massive number and it probably hasn’t been helped with various news stories over the last few years of security breaches, loss of data and of course cases of agents in call centres abroad selling credit card details.So how do we address the need to be PCI compliant specifically when it comes to call recording?
- There are four ways and the first three are probably the easiest but not exactly practical. Firstly we have the option to take payments via an automated IVR where at the end of the call the customer is passed to an IVR to complete their transaction. Now this may also happen in the middle of a call which adds not only complexity to a call but also turns it in to a poor customer experience.The second option is to have a spare set of agents who only process payments and are excluded from any recording system. This may not be a cost efficient method and it has an impact on the internal processes of the company, means you have to transfer customers around and increases your average call duration. In addition if you only have a small number of payment taking agents what happens if they are all taking payments during busy periods – can you really ask customers to hold when they want to give you their money.Option 3 is like a doomsday scenario. Basically what you’re saying here is it’s too complicated and costly and therefore I will just no longer record calls at all. However there are a lot of organisations that, although they don’t have to record calls, they need to record calls and that’s because of dispute resolution. If a mistake occurs you need to know how it occurred and rectify especially if there are financial implications involved so once again this isn’t a practical alternative for the majority of organisations. So that leaves us with option 4.
- Option 4 is where you need to modify the recording solution in some manner to allow you still record calls for either dispute resolution or for Quality Monitoring purposes, but still be able to be PCI Compliant. So what methods are there and how to do they stack up with the PCI regulations?Firstly we have security permissions. Sounds simple enough and every recording system out there will have some form of account name, password and security privileges settings. However that alone isn’t enough to be PCI compliant but its a valid starting point.If you want to or need to capture the PAN or the long number of the card then you should ensure you make this as secure as possible. The general consensus in terms of call recording is that media encryption can be used to secure this data. This is normally on top of any proprietary recording formats that may be in use on the system already. This ensures that from the point of capture to storage and replay the data is secure. However for any other data such as CVV number using encryption alone is not a valid method to be PCI compliant.There is a method to insert some sort of audio masking over the card details. The way this works is that actually the data all does get recorded but on replay a flag is inserted that puts static or silence over the bits that are flagged as being sensitive data. This involves having to work out where in a call to actually insert the flags and also has the downside that anybody with full admin access will be able to still replay the audio file with complete card information. And as the data is still recorded any security breach or copying of the file could mean that data is accessible by third parties. Moving on then to manual pause and resume of recordings. This is typically triggered either by a desktop application or via buttons on an agent’s phone where they can pause a recording whilst taking credit card payments and then resume once it is complete. Officially speaking this doesn’t really meet the PCI requirement as there should be no manual intervention in the process and this is because you do have the potential risk of people simply forgetting to press the button. However if for technical reasons other options are not available to you then it may be possible, maybe temporarily, to get exemptions to allows this method of working.
- Now we can look at methods that are generally regarded as being PCI compliant for call recording.The first method is to use automated pause and resume. This can work in a couple of ways. The first is to use desktop triggering applications to work out the agent process of taking payments and to establish if there is a trigger that can be used from the desktop application or internet browser. You have to work through your application and decide on where a good point is to create an automated trigger to allow the system to pause and then a second trigger to allow the system to resume recording. These triggers technically look at the screen activity and when the trigger point is reached they will send a command to the recording system to pause the recording at that point. Likewise when the second trigger point is reached a command to resume recording can be sent. This allows you to record the call and keep your customer interaction processes the same. However the triggers must be clearly and accurately defined. And if the payment application ever changes in any way these triggers must be tested or re-defined at the time to ensure they still function correctly.A similar way to achieve the same thing is to use in-house programmers or third party programmers who have access to the payment system to use the API commands of the recording system to actually embed software code in to the payment application to send the triggers for pausing and resuming. This will typically work well for environments where a bespoke or in-house payment system is used but when using a hosted or external payment gateway they are unlikely to allow changes to be made to their systems. The added benefit of using this method is that if you perform screen recording it can also be used to pause and resume those recordings so that you don’t inadvertently capture the card data in a screen recording. Automated mute and un-mute is very much the same as the above method of pausing and resuming but instead of stopping and restarting recordings the recording is muted during the trigger points. I will say however that of the two options the more common practice appears to be the pause and resume rather than the mute and un-mute.And finally we come to a method known as DTMF collection of payment details. This typically will involve a slight change in process of how payments are handled but doesn’t require any special programming or working out trigger points on desktop applications. In basic terms an additional piece of hardware is inserted between the recorder and the telephony environment and an additional USB device is attached to the agent phone and connected to the agent desktop. During the payment process the agent moves their mouse to the required field (for example credit card number) and asks the customer to type in their credit card information in to the phone rather than say it verbally. The digits are then heard by the phone as DTMF tones which are then converted by the USB device in to text on the screen. In the backend recording environment the hardware device intercepts these DTMF tones and ensures they do not get to the recorder. So not only have you avoided capturing any audio with credit card details but also any DTMF tones that could potentially be transcoded back to text. Furthermore if you are using screen recording, or want to ensure that agents don’t see the numbers on the screen, a special software can be added that ensures that on screen all the duigits are seen as asterisks. Overall this solution is the least labour intensive but can also be quite costly. However the long term benefit may far outweigh the one time costs involved in deploying such a solution.
- Now we can look at methods that are generally regarded as being PCI compliant for call recording.The first method is to use automated pause and resume. This can work in a couple of ways. The first is to use desktop triggering applications to work out the agent process of taking payments and to establish if there is a trigger that can be used from the desktop application or internet browser. You have to work through your application and decide on where a good point is to create an automated trigger to allow the system to pause and then a second trigger to allow the system to resume recording. These triggers technically look at the screen activity and when the trigger point is reached they will send a command to the recording system to pause the recording at that point. Likewise when the second trigger point is reached a command to resume recording can be sent. This allows you to record the call and keep your customer interaction processes the same. However the triggers must be clearly and accurately defined. And if the payment application ever changes in any way these triggers must be tested or re-defined at the time to ensure they still function correctly.A similar way to achieve the same thing is to use in-house programmers or third party programmers who have access to the payment system to use the API commands of the recording system to actually embed software code in to the payment application to send the triggers for pausing and resuming. This will typically work well for environments where a bespoke or in-house payment system is used but when using a hosted or external payment gateway they are unlikely to allow changes to be made to their systems. The added benefit of using this method is that if you perform screen recording it can also be used to pause and resume those recordings so that you don’t inadvertently capture the card data in a screen recording. Automated mute and un-mute is very much the same as the above method of pausing and resuming but instead of stopping and restarting recordings the recording is muted during the trigger points. I will say however that of the two options the more common practice appears to be the pause and resume rather than the mute and un-mute.And finally we come to a method known as DTMF collection of payment details. This typically will involve a slight change in process of how payments are handled but doesn’t require any special programming or working out trigger points on desktop applications. In basic terms an additional piece of hardware is inserted between the recorder and the telephony environment and an additional USB device is attached to the agent phone and connected to the agent desktop. During the payment process the agent moves their mouse to the required field (for example credit card number) and asks the customer to type in their credit card information in to the phone rather than say it verbally. The digits are then heard by the phone as DTMF tones which are then converted by the USB device in to text on the screen. In the backend recording environment the hardware device intercepts these DTMF tones and ensures they do not get to the recorder. So not only have you avoided capturing any audio with credit card details but also any DTMF tones that could potentially be transcoded back to text. Furthermore if you are using screen recording, or want to ensure that agents don’t see the numbers on the screen, a special software can be added that ensures that on screen all the duigits are seen as asterisks. Overall this solution is the least labour intensive but can also be quite costly. However the long term benefit may far outweigh the one time costs involved in deploying such a solution.
- So there you have the various methods available to you but overall how do you get it right.Well you have to see where you are at present and start by consulting with a PCI QSA who can advise you on what needs to be done to be signed off as being PCI compliant. You have to look at the options and decide on what is most appropriate for you both technically and financially.By all means consult with other parties and try and leverage the experience gained by others and talk to suppliers who regularly integrate and provide PCI compliant solutions. Perform an end to end test and ensure that things work but most importantly continue to monitor and make changes if and when needed.Hopefully by following these points you, the next time you are asked if you are PCI compliant, you can say a resounding yes.
- I hope you have found this useful and informative and obviously if you wish to discuss further feel free to grab one of us during the break periods. Just to end by saying that more information on PCI can be found on our website – businesssystemsuk.co.uk including a white paper on PCI compliance, which is also available at the back of the room if you want a copy.Also don’t forget that we are running a prize draw and someone today will win a Kindle Fire HD so please complete our social media questionnaire to be automatically entered for the draw and hand it in and we will draw the winner before lunch.