White Paper Call recording – How to meet PCI compliance

White Paper
Call recording – How to meet
PCI compliance
Revision 1.0
January 2008
Author:
Robert Wright (robert.wright@audiosoft.co.uk), 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