PCI in the Contact Centre – Simple Steps towards

A decade of innovating contact centre applications
capture
analyse
transform
PCI in the Contact Centre
– Simple Steps towards
Compliance
Introduction
Established in 2006, the Payment Card Industry (PCI) Security Standards Council seeks to enhance payment
account data security by promoting education and awareness of PCI security standards. The Council
publishes the Data Security Standard (PCI DSS) that applies to anyone taking credit/debit card payments
in-person, over the internet or by telephone.
The PCI DSS is well publicised yet many organisations have failed to put in place the necessary technology,
processes and procedures to ensure full compliance. The reasons quoted for failure to comply usually
include: (i) a lack of understanding of obligations under PCI DSS or (ii) an assumption that the steps required
for compliance are unduly complicated.
In what follows we will present a simple overview of the standards, who they cover and what needs to be
done to ensure compliance.
Background
Who or what is PCI
The PCI Security Standards Council is an open global
forum for the ongoing development, enhancement,
storage, dissemination and implementation of
security standards for account data protection.
The PCI Security Standards Council’s mission is to
enhance payment account data security by driving
education and awareness of the PCI Security
Standards. The organisation was founded by
American Express, Discover Financial Services, JCB
International, MasterCard, and Visa.
What obligations does it create
While the implications of PCI DSS are broad, it
can be brought into sharp focus as follows: no
organisation taking card payments can retain
sensitive authentication data, in any format,
whether encrypted or not. Sensitive authentication
data includes the full magnetic stripe data, card
validation codes and PIN numbers.
Who does it cover
In the past, the obligations of PCI DSS applied
only to larger merchants. Today it applies to all
businesses to accept card payments.
What are the penalties for non-compliance
The sanctions for noncompliance are implemented
by the card issuer – Mastercard, Visa, Amex etc.
They can impose monthly fines on businesses who
fail to comply. Aside from a small number of high
profile cases, individual issuers tend to be secretive
about the fines imposed on individual businesses
– the information is considered to be commercially
sensitive. In extreme cases, repeated failure to
comply can lead to the withdrawal of merchant
services which, for businesses that routinely take
card payment from customers, potentially stops
them from transacting business.
Quite aside from the matter of penalties, noncompliance can have an impact on customer
confidence that should not be overlooked.
Considerations for Organisations
that use Call Recording
It is easy to see why the requirements of PCI DSS
apply to payments systems, ecommerce systems
or CRM where payment card details might routinely
be required. PCI DSS applies however, to any type
of application and for many organisations this
will include call recording and screen recording
applications. Specific reference to call recording in
PCI SSC FAQ 5362 establishes the situation clearly:
Are audio/voice recordings containing cardholder
data and/or sensitive authentication data
included in the scope of PCI DSS?
“It is a violation of PCI DSS Requirement 3.2 to store
any sensitive authentication data, including card
validation codes and values, 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;
recognizing that multiple tools exist that potentially
could query a variety of digital recordings.
Where technology exists to prevent recording of
these data elements, such technology should be
enabled.”
This has implications for every organisation, no
matter how small or big they are and regardless
of the volume of transactions they process. It is a
breach of compliance obligations either to record
sensitive authentication data or to retain sensitive
authentication data that has been recorded
previously.
Consideration 1 - Moving the Agent
“Out-of-Scope”
IVR-based payment automation allows your
customer to interact with you in a full self-service
model or as part of a process that combines
self-service with agent-assistance. While the full
self-service model has obvious advantages in
productivity and cost, many businesses prefer to
involve the agent in the payment process. To ensure
PCI DSS compliance in this agent-assisted payment
process, the IVR solution allows the customer to
use the keypad on their phone to type in their card
details. The agent can stay on the line with the
customer but the card details are not displayed on
the agent screen and, if calls are being recorded,
the card details are not spoken so no sensitive card
details are recorded. This effectively moves the agent
“out of scope” of the payment process so, properly
managed, this approach can form a valuable
element of your PCI DSS Compliance strategy.
Consideration 2 - Historical Data
If you currently record calls then you may be storing
sensitive authentication data that you are not
allowed to keep.
Redaction of stored authentication data within
legacy call recordings will allow organisations with
non-compliant data stored over a number of years
to remove the section of the recordings in which the
problem is identified and so ensure that historical
data is compliant.
Consideration 3 - New Recordings
If you wish to continue recording calls then you need
to ensure that the recording no longer captures
sensitive authentication data.
There are a number of ways that you can change
how you record your calls, but it is important to
distinguish between changes that adhere to the PCI
DSS standards and changes which do not.
7
Encryption
Relying on encryption is not compliant, as is made
clear in Information Supplement: Protecting
Telephone-Based Payment Card Data from PCI SSC:
“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”.
7
Manual Pause & Resume
Here, the agent is given the option to manually
pause the recorder when the payment section of the
call is about to begin. In theory this could ensure
that the card details are not recorded.
This approach is expressly non-compliant as it is
subject to human error in that the agent may simply
forget to hit the pause button.
4
Automated Pause & Resume
To be considered compliant, the Pause & Resume
function must be automated, so that the potential
for human error is avoided. With automated Pause
& Resume, the recording is stopped when payment
application screen is launched on the agent desktop.
It is started again when the agent finishes with the
payment section and navigates to the next part of
the call.
7
Audio masking
With audio masking an audible tone is inserted over
the part of the call where payment details are being
collected. This approach is not PCI DSS compliant
because even though the sensitive authentication
data is being obscured, it still being retained.
4
Mute/UnMute
This approach mutes both the agent and the caller
audio within the recorder when the call reaches
the payment section. Nothing is recorded, so on
subsequent playback, the recording is silent when
the payment details are being taken.
With this approach, the sensitive authentication data
is not recorded and the call is captured as a single
instance with a full and accurate call detail record.
Consideration 4 – IT Administration for Call
Recorders
The primary thrust of PCI DSS is to ensure that
sensitive authentication details are not recorded
or stored and it is against this simple standard that
compliance will be judged.
Having said that, there are basic standards of IT
Administration and Security that should be applied,
included but not limited to, the items below. Your
preferred Systems Integrator or maintainer can
provide further details.
Do not use vendor-supplied defaults for system
passwords and other security parameters - a unique
set of strong passwords should be installed on
each system with customers encouraged to change
application passwords on installation.
Use and regularly update anti-virus software on all
systems commonly affected by malware - servers
should be installed with a virus checker with the
virus definitions automatically updated every night.
Develop and maintain secure systems and
applications – procedures to ensure applications are
regularly reviewed, risks identified and appropriate
updates applied to the system to mitigate that risk.
Assign a unique ID to each person with computer
access - comprehensive user security where different
users can be assigned different access rights
depending on their requirements.
Regularly test security systems and processes - every
event or action on the call recording system should
be audited including the type of event, the reference
object, the date/time, the user etc
Your Approach to Compliance
The benefits of Call Recording are well established
– its positive impact on Agent Quality and on
Customer Experience have made it an application
of choice in most service oriented organisations.
While PCI DSS does impact on Call Recording, the
drive for compliance should not restrict your ability
to record calls.
Your recording project should not end with the
implementation of the recorder. Because PCI
DSS includes a Self-Assessment Questionnaire
(SAQ), the project should include a full and
comprehensive test programme to prove that
you are not retaining any Sensitive Customer
Authentication Data.
The SAQ is a validation tool for organisations that
are not required to undergo an on-site data security
assessment. The SAQ includes a series of yes-orno questions about your security posture and
practices. The SAQ consists of two components:
a set of questions corresponding to the PCI DSS
requirements and an Attestation of Compliance.
The Attestation is your certification that you
are eligible to perform and have performed the
appropriate Self-Assessment.
With the right recorder and implementation by
professionals who understand your business, you
can continue to record customer interactions while
fully complying with PCI DSS requirements.
Conclusion
The implications of PCI DSS are real and they affect every organisation that takes card payments while
recording calls. They will be in breach of compliance obligations if they either record sensitive authentication
data or retain sensitive authentication data that has been recorded previously. Breaches may incur financial
penalty and will lead to an erosion of customer confidence. That said, the drive for compliance should not
restrict your ability to record calls.
Recorders that support Automated Pause & Resume or Mute/un-Mute functionality and, where appropriate,
the use of IVR for automated payments, will allow you to compliantly take card payments and at the same
time continue to enjoy the Agent Quality and Customer Experience benefits of Call Recording.
United Kingdom
New Zealand
Matrix House
Goodman Street
Leeds
LS10 1NZ
Tel +44 (0) 113 200 2020
1st Floor
Unit 3/107 Wrights Road
Addington
Christchurch 8024
Tel +64 (0)3 281 7558

Download Report