Regulatory voice recording compliance needs to be addressed within the Contact Centre environment especially if your trading requires the use of credit cards for transactional payments
So what is PCI compliance?
The Payment Card Industry Data Security Standard (PCI DSS) is a set of requirements designed to ensure that ALL companies that process, store or transmit credit card information maintain a secure environment. Essentially any merchant that has a Merchant ID (MID). The Payment Card Industry Security Standards Council (PCI SSC) was formed in September 2005 to manage the on-going evolution of the Payment Card Industry (PCI) security standards with focus on improving payment account security throughout the transaction process.
The PCI DSS is administered and managed by the PCI-SSC committee (www.pcisecuritystandards.org), an independent body that was created by the major payment card brands (Visa, MasterCard, American Express, Discover and JCB). It is important to note, the payment brands and acquirers are responsible for enforcing compliance, not the PCI-DSS council.
PCI-DSS – Payment Card Industry Data Security Services Criteria
• 12 Requirements to Protect Credit Card Information
• 3 Levels based on transactions per annum
- >6m transactions per annum
- 150k to 6m transactions per annum
- <150k transactions per annum
• They were formed in September of 2005
By five leading credit card vendors VISA, MasterCard, Amex, Discover, and JCB
• Why should you care – within the Contact Centre?
- A company that has transactions with Credit Cards where that information is spoken over the phone needs to be secure
• Consequences of Non-Compliance
- Steep monetary fines (circa £500K upwards) and
- Revocation of credit card business trading privileges
Why do you need to review your PCI DSS strategy
It is not just about the installation of technology once and then you are compliant. Most industry suppliers will spin a story about installing a piece of technology like voice recording, or secure firewalls or putting in place a DMZ area for your servers to give the impression that that is all that is needed to be done – this is not the case. Successful completion or installation of some technology or a system scan or assessment for PCI is but a snapshot in time. Fraudsters attack non-stop and get stronger every day, which is why PCI compliance efforts must be seen as a continuous process of assessment and remediation to ensure proper safety of cardholder data.
The pass mark for PCI is 100%, not 99% so if you fail even one of the criteria, you are not PCI compliant. The standard is not meant to be something to strive for; it is essentially a floor, a basis for further security measures. Failing to achieve even one of the requirements, is failing to meet a basic standard for handling cardholder information. All companies that routinely handle this type of data should be aiming to exceed the standard. It’s just good business.
In a recent UK based survey on companies about PCI compliance; across organisations in a variety of market sectors, including healthcare, government, e-commerce, finance and banking, the report findings indicated that PCI compliance is important to eight in 10 UK organisations – which shows good intent. However, 57%, are either PCI compliant or actively working toward becoming compliant. While this represents good progress, it also indicates that the UK is trailing the United States in adoption of PCI compliance.
Shockingly 16% of organisations don’t know what it means to be PCI compliant and nearly one in five companies reported not knowing if PCI compliance is important. "With over 40% of UK organisations not serious about PCI compliance, sensitive customer and cardholder data is still in jeopardy for many of the online transactions that take place".
The key thing to understand is that it is an ecosystem and each party plays a part in a game. You can't put all the blame on just the retailers. The key to preventing data breaches after reaching PCI compliance is knowing your infrastructure and what is changing. Battening down the security landscape involves doing more than focusing on stolen laptops and hackers breaking into networks.
Be aware that for those vendors that state that their technology has been PCI certified, are not correct – so don’t get fooled into this allegation – technology can be used to help ensure a secure environment or remove credit card data. PCI compliance is a process, and a continual process of evaluating your security and protection of PII (Personal Identification Information) data.
The Merchant consideration:
For the purposes of the PCI DSS, a merchant is defined as any entity that accepts payment cards bearing the logos of any of the five members of PCI SSC (American Express, Discover, JCB, MasterCard or Visa) as payment for goods and/or services. Note that a merchant that accepts payment cards as payment for goods and/or services can also be a service provider, if the services sold result in storing, processing, or transmitting cardholder data on behalf of other merchants or service providers. For example, an ISP is a merchant that accepts payment cards for monthly billing, but also is a service provider if it hosts merchants as customers
The company consideration:
Many vendors offer an array of software and services for PCI compliance. No single vendor or product, however, fully addresses all 12 requirements of PCI DSS. When marketing focuses on one product’s capabilities and excludes positioning these with other requirements of PCI DSS, the resulting perception of a ‘silver bullet’ might lead some to believe that the point product provides ‘compliance’, when it’s really implementing just one or a few pieces of the standard.
The PCI Security Standards Council urges merchants and processors to avoid focusing on point products for PCI security and compliance. Instead of relying on a single product or vendor, you should implement a holistic security strategy that focuses on the ‘big picture’ related to the intent of PCI DSS requirements. Part of the problem is a lack of constant, vigilant oversight of one's compliance status. A company can be PCI complaint today but fall out of compliance next week.
What are the PCI compliance ‘levels’ and how are they determined?
All merchants will fall into one of the four merchant levels based on Visa transaction volume over a 12-month period. Transaction volume is based on the aggregate number of Visa transactions (inclusive of credit, debit and prepaid) from a merchant Doing Business As (‘DBA’). In cases where a merchant corporation has more than one DBA, Visa acquirers must consider the aggregate volume of transactions stored, processed or transmitted by the corporate entity to determine the validation level. If data is not aggregated, such that the corporate entity does not store, process or transmit cardholder data on behalf of multiple DBAs, acquirers will continue to consider the DBA’s individual transaction volume to determine the validation level.
Merchant Level Description
- Any merchant -- regardless of acceptance channel -- processing over 6M Visa transactions per year. Any merchant that Visa, at its sole discretion, determines should meet the Level 1 merchant requirements to minimize risk to the Visa system.
- Any merchant -- regardless of acceptance channel -- processing 1M to 6M Visa transactions per year.
- Any merchant processing 20,000 to 1M Visa e-commerce transactions per year.
- Any merchant processing fewer than 20,000 Visa e-commerce transactions per year, and all other merchants -- regardless of acceptance channel -- processing up to 1M Visa transactions per year.
Merchant levels as defined by Visa in the table above:
PCI Security Standard Council Statement
PCI DSS issued the following clarification for contact centres that record calls that contain cardholder data.
Are audio/voice recordings containing cardholder data and/or sensitive authentication data included in the scope of the PCI DSS?
This response is for call centres that record cardholder data in audio recordings, and applies only to the storage of card validation codes and values (referred to as CAV2, CVC2, CVV2 or CID by the payment brands). This response is intended to provide clarification for call centres regarding their potential storage of card validation codes and values, and their compliance with the 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 transaction authorisation.
Call centres may find themselves in the position of receiving cardholder data which includes sensitive authentication data, and they may be unable to delete this sensitive data since individual elements cannot easily be deleted from an audio recording. To clarify, these call centres and all cardholder data are IN SCOPE for PCI DSS. However, if the storage of card validation codes and values meets the unique circumstances described in this response AND these values are protected according to all applicable PCI DSS requirements, those card validation codes and values may be stored. Commercially reasonable technology does exist to delete these data elements, so these elements should be deleted. If the individual data elements within an audio file can never be queried, then only the physical and logical protections defined in PCI DSS version 2.0 must be applied to these audio files.
Additionally, if these audio files that can never be queried are copied to magnetic tape media, that media must also be protected in accordance with PCI DSS. However, if card validation codes and values stored on audio files are subject to technology that allows for the capture and transposition of the speech/audio data into a format that can be queried (for example digital or other file formats), then the sensitive authentication data, including card validation codes and values, must not be stored and must be deleted immediately after authorization. Again, this response applies only to call centres and card validation codes and values. All other cardholder data captured by call centres must be protected in accordance with the PCI DSS, including PCI DSS requirement 3.4. In addition, this response does not to apply to any other entity besides call centres, and all other entities must protect all cardholder data in accordance with PCI DSS, including req. 3.2 and 3.4.
The Standard can be found on the PCI SSC's Website:
https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml
PCI compliance strategy in the Contact Centre
It is important to understand that the whole process of compliance is about being able to maintain a consistent level of checks and processes that ensure that your customer data is always secure and that the correct levels of access are maintained. Contact Centre staff if not correctly managed can be the biggest area of risk within the process so it is important to note that one should look for solutions that prevent not only the voice recorded details of a customer’s credit card are masked but also the visual typed details from either a web portal page or screen scrape.
It is good security practise to put in place an environment within a Contact Centre to prevent the urge for Organised Crime syndicates to actively target new recruits in the Contact Centre industry and also to make it impossible for the agents to be able to be tempted to gather the data in the first instance.
Reducing the scope of PCI compliance
As mentioned before there is technology that will make it very easy for those who are regulated and need to record calls and transactions to prevent the card data from being saved. Some solutions are more complex than others so search around but one offering from ColabCom is to not only prevent the callers credit data from being recorded but also to remove the information from the agent, thereby removing the agents and their PC’s from scope when engaging in a PCI compliance audit. This solution puts the responsibility to input the card data by the caller’s phone keypad, this will null out the tones and mask the data in the screen. In addition the recording does not gather any of the data with this process.
There is more, a verbal signature is gathered at the end of the transaction which can be saved and also sent to the card holder by email as proof of transaction. This prevents additional fraud where the card holder can immediately notify a merchant that a CNP transaction was not them if it actually was not. The signature also prevents genuine transactions by the card holder typically on low value CNP transactions from being fraudulently denied and then credited by the merchant as often it’s too costly to chaise up.
When your business is looking to bring the PCI DSS certified QSA to audit your environment make sure that you can reduce the amount of scope that your business needs to audit, so removing agents and agent PC’s in your Contact Centre from scope will dramatically reduce costs, so invest wisely.
Summary
A well-planned and thought out PCI strategy will enable an organisation to remain within the law and ensure that the regulatory bodies do not impose the steep fines or remove the trading rights to your business.
A basic solution is for businesses to worry less about PCI compliance and concentrate more on their security, be sure to build the processes round keeping your business safe from PII (Personal Identification Information) storage and remember it is not one company that can make you compliant it is an ecosystem – fine those vendors that can really make a difference.
It is important to understand the facts that could reduce your compliance and make sure that one imposes regular checks and continual processes are done. Ensure any new or merged business into your corporation does not suddenly put your business at risk and out of compliance – this is an easy trap to fall in.
Just one fine from the merchant card suppliers, (starting at £500k & going into the millions) and possibly more damming the negativity on your brand in the market from falling out with the compliance body will more than justify any costs your business will incur to ensure full compliance within ones Contact Centre payments businesses.
By Craig Ashmole
cashmole@ccserve.co.uk
www.CCServe.co.uk