PCI Data Security Standards

The Payment Card Industry (PCI) Data Security Standards have gained significant attention in the call center market. In this section of the whitepaper we will discuss what those standards are, how they affect recording applications, and what you can do to help ensure your recording system operates in respect of those standards.

We have researched this topic extensively; however, NICE is not affiliated with the PCI Security Standards Council™. The information presented in this whitepaper is based on our research using the information provided at www.pcisecuritystandards.org, interviews with peers in the industry, and feedback from our clients.

What is PCI?

PCI stands for Payment Card Industry. The PCI Security Standards Council was founded by American Express, Discover Financial Services, JBC, MasterCard Worldwide, and Visa International. The Council’s stated mission is “To enhance payment account data security by fostering broad adoption of the PCI Security Standards.”

Who Enforces PCI?

While the PCI Security Council established and maintains the Data Security Standards (DSS), each card brand still manages its own compliance programs. If you have questions or concerns regarding your company’s compliance status or the risks and penalties for falling out of compliance, we recommend you contact the payment brands you are contracted with.

Why All the Fuss?

We could fill volumes with the reasons that PCI Security Standards are important, but in this case the above picture is worth 1,000 words. Identity theft is pervasive in today’s economy, and consumers need to be protected. The PCI DSS take great measures to help safeguard consumer account information and minimize or eliminate the potential for identity theft.

What Are the DSS?

What follows is an outline of the PCI DSS, and notes on how a recording system may be impacted by those standards. The full PCI DSS version 1.1 is available at www.pcisecuritystandards.org.

Build and Maintain a Secure Network

Requirement 1: Install and maintain a firewall configuration to protect cardholder data

Most recording applications will not have an impact on the existing firewall; they will be on your network behind your firewall. This will be different for hosted applications, however.

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters

While we cannot speak for all vendors in the industry, part of NICE's standard installation procedure is to reset/remove all default passwords. Other measures can be taken to ensure employees do not create overly-simple passwords. This includes the ability to restrict any users from resetting their own passwords, thus providing the capability to maintain a higher standard for password security (such as a higher number of characters, requirements for both upper- and lower-case alpha, numeric, and special characters in the password).

Protect Cardholder Data

Requirement 3: Protect stored cardholder data

Encrypting the stored data, i.e. your audio and screen recordings, is perhaps the best way to protect the stored cardholder data. In the unlikely scenario that a person could access your secured data center, remove the hard drives from your recording server or storage unit, and connect those drives to another server, that person could access unencrypted data on those disks. It is an unlikely scenario, but after all it happened at Los Alamos…

Requirement 4: Encrypt transmission of cardholder data across open, public networks

Hosted systems aside, a call recorder will be on your network behind your firewall, and will not be on an open public network. If you offer remote access to the system by third parties, such as a client accessing a system at an outsourcer facility, that access should be through a secured connection such as VPN, and not over the public Internet.

Other data transmissions that could be encrypted include screen capture data sent from a PC to your recording server, audio and screen files that are downloaded or streamed from the server for playback, or recordings that are exported from the system.

Maintain a Vulnerability Management Program

Requirement 5: Use and regularly update anti-virus software

Contact your vendor to see if there is a recommended anti-virus program for the recorder. We strongly advise against installing any anti-virus software on your existing recorder without first verifying that it is compatible with the recording software!

Requirement 6: Develop and maintain secure systems and applications

Most, if not all, recording applications have sophisticated permissioning systems to ensure that unauthorized users cannot access recordings. Exceptions may be tape recorders or units that tap a handset and save the recordings to a local PC. Notwithstanding those exceptions or hosted recorders, you should have the ability to restrict user access at the network level by denying access to the server IP address, in addition to user name and password authentication. The server itself will require authentication through Windows for an administrator to log on.

Implement Strong Access Control Measures

Requirement 7: Restrict access to cardholder data by business need-to-know

User permissions should be able to restrict what records each user can access, or deny any person from having access to the server. You can also use IP restrictions in your data network to further ensure the unauthorized employees cannot reach the server from their workstations.

Requirement 8: Assign a unique ID to each person with computer access

Whatever you do, DON’T SHARE YOUR LOGINS!!!

Requirement 9: Restrict physical access to cardholder data

The recording server should be in a locked computer room / data center at your facility. For a hosted solution, check with your hosting provider to ensure access to the server is restricted. Having encryption for your stored files is also helpful in restricting physical access to the data.

Regularly Monitor and Test Networks

Requirement 10: Track and monitor all access to network resources and cardholder data

Most PCI compliant companies are likely to have something in place that is monitoring network activity. In addition to your network management protocols, your recorder should log user access and user activity within the system as it pertains to accessing recordings.

Requirement 11: Regularly test security systems and processes

While we cannot speak for other vendors, as we add new features to cc: Discover and other CallCopy software, part of our QA process is to conduct regression testing to ensure new components to not have unwanted effects on existing modules.

Maintain an Information Security Policy

Requirement 12: Maintain a policy that addresses information security

If your vendor has direct access to your recorder through modem, VPN, or other means, you should ensure that vendor has a policy for information security.

Exceptions to the DSS

“PCI DSS requirements are applicable if a PAN [Primary Account Number] is stored, processed, or transmitted. If a PAN is not stored, processed, or transmitted, PCI DSS requirements do not apply.”

What Can Be Stored

Information on what can and can’t be stored is reprinted from the Payment Card Industry (PCI) Data Security Standard Version 1.1, Release:

September 2006. Descriptions for the

CVC2/CVV2/CID are taken from the Glossary available at www.pcisecuritystandards.org.

Data Element Storage Permitted Protection Required PCI DSS Req. 3.4

What Can’t Be Stored

Data Element Storage Permitted Protection Required PCI DSS Req. 3.4

*The second type of card validation value or code is the three-digit value printed to the right of the credit card number in the signature panel area on the back of the card. For American Express cards, the code is a four-digit unembossed number printed above the card number on the face of all payment cards. The code is uniquely associated with each individual piece of plastic and ties the card account number to the plastic. The following provides an overview:

CID Card Identification Number (American Express and Discover payment cards)

CAV2 Card Authentication Value 2 (JCB payment cards)

CVC2 Card Validation Code 2 (MasterCard payment cards)

CVV2 Card Verification Value 2 (Visa payment cards)


After extensive research on the Internet and through personal interviews, we have not been able to find any conclusive rulings regarding the PCI DSS and call recording applications. As with the two-party state recording laws, our recommendation is to err on the side of caution and implement the solution that best addresses the PCI DSS.

The aspect of the PCI DSS that poses the greatest challenge to the recording industry is the prohibited storage of the CVC2/CVV2/CID – the three- or four-digit security code, depending on the card type. This information is stored in your audio and screen recordings.

So how can you remove or block the security code from your recordings?

Manual Editing

Manual editing is one way to remove that data, but we do not recommend this method. It seems with the goal of PCI DSS being to limit access to the cardholder data, manually editing the recordings is exactly the opposite – it is requiring someone to access the data, however temporary that access may be. Not to mention the labor requirements…

Automated Editing

There are challenges with automated editing of records as well. A recording that has been tampered with or edited may not be usable in court. You also need to ensure the right sections of the call are edited. This can be an automated or manual trigger sent to the recorder to update the record with start and stop points, between which is the sensitive data. With CallCopy’s cc: Discover platform, we offer a bcc: Compliance module that allows users to send these triggers, and there is a blackout applied to the sensitive data.

If this is a manual trigger, then you are relying on your staff to always remember to click a button to initiate and end the process. This is obviously subject to human error, and the result will be some recordings where an agent forgot to start the blackout and some where the agent forgot to end it.

Our recommendation is for automated triggers based on activity in a desktop application or web form. In this scenario, a trigger to start a blackout would be sent when an agent clicks on the field to enter the security code, and it would end when the agent submits the account information. This method is still not infallible, as a customer may provide account information before the agent takes the action that starts the blackout.


We recommend a recording system that is able to offer encryption for your stored data as well as encryption for all client-server communications. This includes screen data being sent across your networks and audio/video playback.

Exported Records

Perhaps the most critical time to encrypt calls is when they are exported from the system. We do not recommend that calls with sensitive cardholder data be exported unless they are encrypted and password protected.