The Inner Circle Guide to PCI DSS Compliance in the Contact Centre

Transcription

1 The Inner Circle Guide to PCI DSS Compliance in the Contact Centre Sponsored by

2 The Inner Circle Guide to PCI DSS Compliance in the Contact Centre ContactBabel 2015 Please note that all information is believed correct at the time of publication, but ContactBabel does not accept responsibility for any action arising from errors or omissions within the report, links to external websites or other third-party content. 2

3 Contents PCI DSS: Background and Requirements... 8 The card payment ecosystem: A glossary... 8 PCI DSS: the background PCI DSS: The 12 regulations PCI DSS: the view from the contact centre Card payments and PCI compliance in UK contact centres today Changes in PCI DSS version Q1: What are the main changes to the standard that will affect contact centres in version 3.0 of PCI DSS? QSAs and self-assessment Q2: As PCI DSS standards change frequently, how can we futureproof our contact centre so that we don t have to keep investing in new solutions or re-engineering processes? Division of responsibilities Q3: Who in the organisation should run the PCI compliance operation? Balancing PCI DSS with other regulations Best practice Current PCI compliance methods used Q4: We don t take many card payments (e.g. fewer than 10,000 per year). Are there any PCI solutions that make sense for us? PCI Compliance Solutions and Moving Out-of-Scope Handling Card Payments: Technological Solutions IVR payment DTMF Suppression Tokenisation Handling Card Payments: HR and Business Processes Q5: Is it true that the greatest risk comes from agents rather than cyber attack (although the latter is potentially catastrophic)? Where should we be concentrating our efforts?

4 Handling homeworking agents Clean rooms & payment teams Handling Call Recordings Turning off recordings Pause and resume Legacy call recordings Cloud / hosted provision Market Landscape The Vendor Community IP Integration Implementation Considerations Q6: How can I persuade senior management that the financial case for investment in PCI-related technology and processes stacks up? About ContactBabel

5 IPI is dedicated to creating the smartest, most efficient contact centres in the world. Not just today but tomorrow. Your Customers Demand A better experience. More efficiency. Increased ownership. Better outcomes. That takes an integrated Contact Centre technology that s smarter. Progressive systems from truly dedicated partners. Technology to improve every interaction. To deliver results beyond all expectations. The Same As Your People. Our 30+ years of contact centre expertise in market sectors from banking to gaming has earned us the trust of our clients, from large corporations to SMEs. With innovation in our DNA, we deploy pioneering solutions to help create the smartest, most efficient and secure contact centres in the world. Optimised hubs that offer a more satisfying, more cost-effective customer experience. Our expertise is divided into six core services: Consulting, Applications, Unified Communications, IT Services, Network Services and Security & Compliance. Yet their relationship is symbiotic. Each supporting the other for holistic growth. And just as our offering is complete, so too is our support. Helping you to not just prepare for what s to come, but to embrace it. Consulting. Because out of date is out of the question. With a range of innovative solutions and access to pioneering technologies, our experts will analyse and shift your contact centre s capabilities to the ever-evolving reality of your business. Applications. They're all around you. Every one of our applications is designed around your needs, from tools that give you complete visibility of your Contact Centre performance, to software that enables better management of people and systems. We create packaged applications that are quick and easy to deploy, delivering immediate benefits to your business. Unified Communications. Great things happen when you bring everything together. Bringing all forms of communication together through Unified Communications (UC) does great things for your customers, and your business. IPI delivers UC for the 21st Century Contact Centre. IT Services. Treating customers like kings. Systems that ensure both your contact centre and IT infrastructure run at peak efficiency, are seamlessly connected, completely reliable, and secure. Ensuring your customers can get in touch whenever they want. All while improving your agent productivity, reducing costs and increasing revenue. 5

6 Network Services. Because your network is your business. Visibility and control. Both are vital when it comes to your network. IPI understands this and offers a range of services to help you get to grips with your network. Make your network work harder for your business, today, tomorrow, always. Security & Compliance. Because your core business isn't payments and data. All you need to know is that you got paid, not the full details of the payment. The best way to protect your organisation from losing sensitive data is to completely avoid being exposed to it in the first place. Data protection and fraud prevention regulations are costly so compliance is key. Contact: a: IP Integration Ltd, Integration House, Turnhams Green Business Park, Pincents Lane, Reading, Berkshire RG31 4UH (UK) t: (Service Centre Freephone): e: ipi.info@ipintegration.com Linked In Twitter 6

7 TRANSFORMING CONTACT CENTRES TODAY AND IN THE FUTURE. IPI is dedicated to creating the smartest, most efficient contact centres in the world. Not just today but tomorrow. YOUR CUSTOMERS DEMAND A better experience. More efficiency. Increased ownership. Better outcomes. That takes an integrated Contact Centre technology that s smarter. Progressive systems from truly dedicated partners. Technology to improve every interaction. To deliver results beyond all expectations. THE SAME AS YOUR PEOPLE. T +44 (0) E ipi.info@ipintegration.com W ipintegration.com DELIVERING BEYOND TODAY.

8 PCI DSS: BACKGROUND AND REQUIREMENTS THE CARD PAYMENT ECOSYSTEM: A GLOSSARY In order to understand the landscape of payment card processing, there first needs to be a clear understanding of the players within it. The PCI Security Standards Council has detailed definitions of many commonly used terms 1, and here are some of those relating to the most important entities within the card payment ecosystem: Acquirers: usually the bank or other financial institution that processes payment card transactions on behalf of the merchant. The acquirer receives authorisation requests from merchants, and passes the request to the card brand for approval, with funds from successful transactions then being deposited within the acquiring bank. Acquirers are responsible for making sure that merchants comply with PCI DSS. If non-compliance is proven, acquiring banks will pass on the fines that they receive from the card brands onto the merchants, as well as being able to increase the cost per transaction or even deny merchants the ability to take card payments. It is important to remember however that merchants always bear full responsibility for their PCI DSS compliance Card brands: the providers of payment cards. Visa Inc., MasterCard, JCB International, American Express and Discover Financial Services banded together in 2006 to form the PCI Security Standards Council (PCI SSC), which is responsible for developing the PCI standard and for supporting organisations attempts to become compliant. The card brands created the PCI SSC to reduce fraud risk, acting together so that they all have the same regulations and not one of them had a competitive advantage over the other. The card brands have contracts with the acquiring banks, who themselves have contracts with merchants Merchants: organisations which accept payments made by credit or debit cards Qualified security assessors (QSA): individuals or organisations that are qualified by the PCI SSC to help organisations interpret the PCI standard and become compliant Service providers: organisations that are directly involved in the processing, storage, or transmission of cardholder data for organisations other than or in addition to, their own. This includes organisations that provide security and control of cardholder data such as managed firewall providers, cloud solution providers and payment service providers, as well as outsourced contact centres. All organisations and entities that store, process or transmit cardholder data are responsible for complying with PCI DSS regulations

9 Card brands categorise merchants into one of four levels, depending upon criteria such as the volume of card transactions and whether a merchant has had a previous account data compromise. Depending upon the level of the merchant, requirements are specified, differing by the type and frequency of compliance assessments and network scans. For most brands, a Level 1 merchant will have more than 6 million card payments a year; Level 2 between 1 million and 6 million; Level 3 between 20,000 and 1 million; and Level 4 fewer than 20,000 card transactions annually. Some card brands state that Level 1 merchants that choose to conduct an annual onsite assessment using an internal auditor rather than a QSA must ensure that internal auditor staff engaged in validating PCI DSS compliance attend PCI SSC ISA Training and pass the associated accreditation program annually. Validation requirements for Levels 2 to 4 are somewhat less stringent for some card brands than others. Details of merchant level calculation and specific validation requirements by card brand may be found here: Visa (US) Visa (Europe) Visa (Asia) MasterCard American Express JCB International Discover Financial Services Regardless of merchant level, businesses that take any form of card payment from customers are required to comply with PCI DSS. Penalties for non-compliance can be considerable. As they are discretionary, there is no specific tariff to refer to, but ongoing fines of many thousands or tens of thousands of pounds per month may be charged to the acquiring banks by the card brands, which will almost certainly be passed on to the merchant. The banks may also decide to remove the merchant s ability to take card payments or charge increased transaction fees. Additionally, the damage to brand and trust that a high profile card payment data breach could cause is potentially even more damaging than financial sanctions. 9

10 PCI DSS: THE BACKGROUND The Payment Card Industry Data Security Standard (PCI-DSS) is the creation of five of the largest payment card providers: VISA, MasterCard, American Express, Discover and JCB International, which together have named themselves the PCI Security Standards Council. The PCI SSC wished to clarify and align their various fraud prevention measures and regulations into a single agreed global framework. PCI DSS provides guidance to merchants as well as payment card processors around how to process, store and transmit information about the payment card and its owner, with the aim of reducing the incidence of card fraud and promoting best practice in information security. Although compliance with PCI DSS is not enforced by law, the card brands may fine those which do not follow its regulations, or even deny the merchant the ability to take card payments at all. Changes to PCI DSS are made every three years, based on feedback given to the PCI SSC. It is not a prescriptive methodology to be followed to the letter, but should be viewed as a set of rules or guidelines that organisations and external QSAs can interpret in conjunction with the business s existing processes, technology and policies to reach the required level of information security. The recently published Verizon 2015 PCI Compliance Report 2 - which is a key piece of research around this subject - reports that only 20% of businesses are fully compliant with PCI DSS, although the average compliance rate (i.e. the proportion of all requirements & sub-requirements that are met) is close to 94%. It also finds that less than a third of companies were found to still be fully compliant a year after successful validation, which is a concern that version 3.0 of PCI DSS looks to address, with its focus upon compliance as being business as usual. It is easy to become non-compliant if the procedures and processes for managing maintaining it are not put in place, and that compliance assessment is only ever a snapshot of the specific services, devices and processes being checked at that particular moment. Verizon comments that PCI DSS is a baseline, an industry-wide minimum acceptable standard, not the pinnacle of payment card security, and that it should be seen not in isolation but as part of a ongoing security and risk minimisation process, involving regular testing. While EMV cards, otherwise known as Chip and PIN have been very successful at reducing Cardholder Present fraud, this is meant a displacement in attempted card fraud, rather than an overall reduction. The increasing uptake in EMV cards in the US is likely to bring in increased wave of attacks in Cardholder Not Present environments, such as the contact centre

11 PCI DSS: THE 12 REGULATIONS There are 12 requirements to fulfil in order to achieve PCI DSS compliance (full details are available here 3 ), with many specific sub-requirements within them. Build and Maintain a Secure Network and Systems Requirement 1: Install and maintain a firewall configuration to protect cardholder data Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters Protect Cardholder Data Requirement 3: Protect stored cardholder data Requirement 4: Encrypt transmission of cardholder data across open, public networks Maintain a Vulnerability Management Program Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs Requirement 6: Develop and maintain secure systems and applications Implement Strong Access Control Measures Requirement 7: Restrict access to cardholder data by business need to know Requirement 8: Identify and authenticate access to system components Requirement 9: Restrict physical access to cardholder data Regularly Monitor and Test Networks Requirement 10: Track and monitor all access to network resources and cardholder data Requirement 11: Regularly test security systems and processes Maintain an Information Security Policy Requirement 12: Maintain a policy that addresses information security for all personnel. While all of the requirements will have some impact upon the workings of the contact centre, it is generally considered that Requirements 3, 4 and 12 may have the greatest relevance

12 Requirement 3: Protect stored cardholder data This requirement is about reducing the impact of any data breach or fraud, by minimising the holding of any unnecessary data as well as reducing the value of any stored payment card information. Data must only be stored if necessary, and if stored must be strongly encrypted, and only kept for the period where it is actually needed, with a formal disposal procedure. Businesses should revisit the necessity of data storage on an ongoing basis, and it should be remembered that the storage of sensitive authentication data such as card verification codes, is prohibited even if encrypted, and must be permanently deleted immediately after authorisation. The requirements of other regulations (which may mandate keeping recordings for a long period of time) may need to be balanced against PCI DSS guidelines, with possible compromises occurring such as archiving encrypted call recordings offsite in a secure facility, with access to them only in the case of fraud investigation or when proving industry-specific regulatory compliance. Sensitive authentication data such as the card verification code should normally never be stored, even in an encrypted format. PCI DSS requirements also indicate that the full card number (PAN) should only be available on a need-to-know basis, and should otherwise be hidden, with XX- XXXX-7890 considered the minimum masking format. For businesses which choose for agents to type in card details, post-call masking and role-based access to the full PAN should be considered, along with strong cryptography when stored. For contact centres, the most obvious place where data is stored as in the recorded environment, and the options for management of this is addressed elsewhere within the report. The Verizon report notes that there is an increased use of RAM scrapers, which is a form of malware that takes data from volatile memory as it as being processed and before it is encrypted. Organisations have to determine all of the locations which credit card data could potentially be stored, even if it is not part of the formal card handling process. For example, there is nothing to stop the customer sending their credit card details, including the card verification code, by or web chat: if the or chat interaction is then stored, then a risk exists, and the operation is not PCI DSS compliant. There is an increasing use of data loss prevention solutions as a way to track data that has somehow moved out of the original environment, and PCI DSS version 3.0 states more clearly than previously that businesses need to have a good inventory not just of the equipment and infrastructure, but also of their logical environment as well. Requirement 4: Encrypt transmission of cardholder data across open, public networks In the event of a security breach, it is important to make sure that credit card data (such as the PAN, or long card number ) is not readable through the use of strong cryptography, not only at its stored location but also as it is being passed across the network. The network is only as strong as its weakest link, and badly configured wireless networks, with out of date security and weak passwords are a particular concern. 12

13 Requirement 12: Maintain a policy that addresses information security for all personnel All employees should be made aware, in writing and through daily exposure to information security guidelines, of what their responsibilities are in terms of handling data. The regular and ongoing minimisation of potential security risks is perhaps even more important for homeworking agents, who are less likely to be in a rigidly maintained environment, and whose vigilance and adherence to security guidelines may therefore be less rigorous. Compensating controls Businesses that are unable to fully comply with PCI DSS objectives, for technical or business process reasons perhaps, may consider implementing compensating controls, which act as workarounds to achieve roughly the same aim as the PCI control in situations whereby the end result could not otherwise be achieved. These are not meant as an alternative to the control objectives, to be used in cases where the business simply does not want to meet the regulations, but are supposed to act as a last resort allowing the business to achieve the spirit of the control, if not actually the very letter. Guidelines for valid compensating controls indicate that it must meet the intent of the original requirement, and provide a similar level of defence, go at least as far as the original requirement and not negatively impact upon other PCI DSS requirements. Some card brands state that all compensating controls must be approved by a QSA, even if a merchant s level would not otherwise require this. The use of compensating controls is by definition subjective, and depends to a great extent whether the QSA feels that it is acceptable and reasonable alternative. As each business is different, judging compensating controls neutrally and objectively against fixed criteria cannot be done: it is at least as much an art as a science. 13

14 PCI DSS: THE VIEW FROM THE CONTACT CENTRE Potential danger points within the contact centre fall into three main areas: storage, agents and infrastructure. The storage element will revolve around the recording environment - both voice and screen - and the potential and opportunity for dishonest employees to access recordings or write down card details should also be considered. In terms of infrastructure, this is not simply a matter of considering the CRM system or call recording archives, but also includes any element that touches the cardholder data environment. This could include, but is not limited to the telephony infrastructure, desktop computers, internal networks, IVR, databases, call recording archives, removable media and CRM / agent desktop software. As with so much else in the contact centre environment, the common trinity of People, Process and Technology should all be considered in context of PCI DSS compliance in order to make sure that all bases are covered. The various elements of card data may be handled in different ways. Figure 1: Data elements and storage in PCI DSS Data Element Storage Permitted Must Render Data Unreadable Primary Account Number (PAN) Yes Yes (e.g. strong one-way hash functions, truncation, indexed tokens with securely stored pads, or strong cryptography Cardholder Data Cardholder Name Yes No Service Code Yes No Expiry Date Yes No Full magnetic stripe data No Cannot store Sensitive Authentication Data CAV2/CVC2/CVV2/CID (Card Security Codes) No Cannot store PIN / PIN Block No Cannot store 14

15 CARD PAYMENTS AND PCI COMPLIANCE IN UK CONTACT CENTRES TODAY The statistics and findings in this section are taken from the "UK Contact Centre Decision-Makers' Guide ( th edition)", the major annual report studying the performance, operations, technology and HR aspects of UK contact centre operations. Data are segmented and analysed along vertical market (business sector) lines, to highlight the specific issues and environments particular to that vertical industry, and the following table explains what is included within each vertical market. Figure 2: Vertical market definitions Vertical market Finance Housing Insurance Manufacturing Outsourcing Public Sector Retail & Distribution Services Technology, Media and Telecoms (TMT) Transport & Travel Utilities Sub-sectors Banks, credit cards, loans, debt collection, credit checking, corporate Housing associations Insurance for life, motor, house, corporate, reinsurance, etc. Mainly B2B sales and support, along with customer helplines Large full-service outsourcers and smaller telemarketing firms Government, central and local, agencies, emergency services Retailers, home shopping, catalogue, parcel carriers, logistics Non-physical service offerings to public and business Technology sales and service; Mobile and fixed line operators, TV and cable providers; Broadband Transport information, booking, travel agents, airlines, hotels, Electricity, water and gas providers 15

16 71% of UK respondents' operations take card payments from customers over the phone, although the services and manufacturing sectors are amongst those least likely to do so, probably as a result of much of this business being high-value, invoiced B2B work. Payments are normally taken by agents (in 66% of cases), although vertical markets such as utilities, housing, finance and public sector may well offer a fully-automated as well as a human payment option to their customer base. Figure 3: Does your contact centre take payments over the phone? (by vertical market) multiple options allowed Does your contact centre take payments over the phone? (by vertical market) Average 29% 29% 66% Services 12% 50% 50% TMT 31% 44% 50% No card details taken Utilities 29% 57% 57% Via automation Manufacturing Insurance 8% 27% 33% 42% 58% 60% Via an agent Finance 40% 40% 60% Public Sector 24% 48% 72% Outsourcing 22% 22% 74% Transport & Travel 11% 11% 78% Retail & Distribution 18% 82% Housing 54% 92% 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 16

17 The following two charts show the level of concern that respondents believe that their organisations have towards contact centre fraud. (NB: as this specific research was about PCI compliance, businesses which do not take card payments within the contact centre were excluded). Respondents were asked to score their concern over potential contact centre fraud on a scale of 1 to 10, where a score of 1 meant that they were very unconcerned, and 10 meant that they were very concerned. Focusing upon those at either end of the spectrum is likely to offer greater insight into real issues, so only those reporting little concern or great concern are shown. There are two findings that are immediately apparent: many respondents are extremely confident that contact centre fraud is not a major risk within their own business, with 40% scoring this as 1/10 or 2/10; and that a significant proportion of the finance sector takes this potential threat extremely seriously. The latter finding is perhaps less surprising, given the nature of the business and the unparalleled access that financial services customer contact agents have to sensitive financial information, systems and personal data. However, the widespread confidence that contact centre fraud is not a direct threat that is shown elsewhere in the contact centre industry is interesting, and may be misplaced, particularly in light of detailed industry-wide research such as Verizon s. Figure 4: How concerned is your organisation that contact centre fraud could harm your business? (by vertical market) How concerned is your organisation that contact centre fraud could harm your business? (by vertical market) Average 18% 22% 1% 8% Utilities 20% 20% Services 27% 9% Retail & Distribution 29% 29% Manufacturing 20% 20% Housing 10% 40% Public Sector 31% 19% 6% 6% Outsourcing 18% 36% 9% Insurance 11% 11% TMT 25% 13% 13% Transport & Travel 20% Finance 40% 40% 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 1 - very unconcerned 2 - unconcerned 9 - concerned 10 - very concerned 17

18 When looking at contact centre size bands, small operations are far more likely to feel that contact centre fraud is not a risk to them, with 55% of respondents from this sector expressing a great deal of confidence about this, compared to only 24% within large operations. Almost 1 in 8 respondents from 200+ seat contact centres were extremely concerned about the potential that contact centre fraud has to damage their business. Figure 5: How concerned is your organisation that contact centre fraud could harm your business? (by contact centre size) How concerned is your organisation that contact centre fraud could harm your business? (by contact centre size) Average 18% 22% 1% 8% Large 9% 15% 12% Medium 23% 20% 10% Small 24% 31% 3% 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 1 - very unconcerned 2 - unconcerned 9 - concerned 10 - very concerned 18

19 Although over half of respondents from contact centres which handle card payments are satisfied that their existing approach to PCI compliance, and the systems and processes that support this do not require change, 27% of respondents who are PCI compliant are open to an alternative approach if it can be seen to deliver superior benefits or save significant time and cost. 19% of respondents handling card payments state that they are not yet fully PCI compliant, and although the majority of those are actively working towards becoming so, there are still a small handful who seem to be ignoring the need to comply with these regulations. However, the 2015 Verizon report on PCI compliance 4 state that only 20% of organisations surveyed were fully PCI compliant. This is not necessarily a contradiction, as elements within the purview of the contact centre - such as the handling and storage of sensitive authentication data in the call recording environment - may be compliant with PCI requirements, whereas outside the contact centre, there are various elements which are not. Of course, it may also be the case that contact centre management believe that their operations are compliant, whereas an external assessor may disagree. These findings do not fully match up with the widespread dismissal of risk demonstrated in the past two charts. Further in this chapter, we find that only a minority of respondents have implemented payment solutions that take agents out of the equation altogether, so there may well be a disconnect between the reality of risk, and businesses perception of the threat of fraud. Figure 6: Organisational attitude towards PCI compliance (only respondents which handle card payments) Organisations' attitude to PCI compliance (only those which handle card payments) Do not have PCI compliance, and are not looking to become PCI compliant 2% Do not have PCI compliance, but are looking to do so, or have an active project underway to achieve it 17% Have PCI compliance - have an agreed approach implemented and will be sticking to it (no change) 54% Have PCI compliance, but are open to an alternative approach if it delivers benefit or saves significant cost and time 27%

20 CHANGES IN PCI DSS VERSION 3.0 According to the press release issued by the PCI Security Standards Council on 7 th November , Version 3.0 will help organizations make payment security part of their business-as-usual activities by introducing more flexibility, and an increased focus on education, awareness and security as a shared responsibility. Overall updates include specific recommendations for making PCI DSS part of everyday business processes and best practices for maintaining ongoing PCI DSS compliance; guidance from the Navigating PCI DSS Guide built in to the standard; and enhanced testing procedures to clarify the level of validation expected for each requirement. Perhaps the most obvious change in PCI DSS version 3.0 is a great increase in the number of sub requirements. While the 12 major requirements stay very much the same, with the occasional tweaking of words, the number of sub-requirements has greatly increased to well over 200. Some solution providers interviewed for this report state that version 3.0 requires over 600 pieces of data to be passed through to a QSA, up from 120 in version 2.0 (there was no consistent agreement on exact figures, but all interviewed parties stated that the number of sub requirements and attendant pieces of data had gone up very considerably). PCI DSS 3.0 attempts to lead to clarity around the responsibilities within the payment processing chain, with the phrase business as usual (BAU) occurring frequently within PCI DSS literature and commentary, in order to emphasise that that an annual compliance check is no longer an appropriate way to guard against card fraud. Guidance around BAU includes the monitoring of third parties, logs and systems; the identification of control system failures and implementation of policies reporting these; and ongoing monitoring, testing, reporting and auditing throughout the year, with emphasis being placed on increasing the awareness of employees of data security and their responsibilities around this. There is the general notion of security being a shared responsibility, both within an operation and also involving third-party solution providers and partners. Merchants now have to sit down in a formal environment with third-party suppliers of payment processing solutions and other related technology, and agree who has responsibility for each part of the card payment process, including storage and transmission of data. Solution providers have to be PCI compliant as well, and if an Attestation of Compliance (AOC) certificate is not present, then the merchant must audit that supplier themselves. In reality, the merchant may simply take the easy way out and look for a fully compliant alternative supplier

21 Requirement 3, which looks at the protection of stored cardholder data, has several updated controls relevant to the contact centre. In particular, control 3.2 clarifies that all sensitive authentication data must be rendered unrecoverable after the authorisation process has been completed. Requirement 3 is stated by Verizon to be the second-least complied-with control, often as a result of data being held without an actual business need and misconfigured systems unintentionally storing data. Verizon has seen a very high use of compensating controls within Requirement 3, particularly with control 3.4 (Render PAN unreadable anywhere it is stored), due to technical challenges around the implementation of encryption. It notes that organisations are increasingly adopting tokenisation over encryption, as it is seen as offering superior security, with hosted tokenisation in particular protecting data at all stages within the merchant environment. Requirement 4 - the encryption of transmissions of sensitive information across public networks - throws up greater complexities as the uptake of cloud continues. In early 2013, the PCI SSC issued the PCI DSS Cloud Computing Guidelines Information Supplement 6 which details the responsibilities of the cloud provider and the customer and provides guidance on the security of payment data and compliance with PCI DSS in the cloud. Requirement 12 - on maintaining an information security policy - may not seem at first glance relevant to the contact centre in particular, but the management of the responsibilities and controls of third parties such as outsourcers and payment service providers is noted as being an increasingly important part of version 3.0. Written policies are vital part of protecting and reducing the risk from users misunderstandings of what is expected of them, and formal risk assessments of nontraditional environments such as homeworkers and third-party providers are a greater part of the updated standards. The sub-control looks to clarify which PCI DSS controls are handled by the merchant and which by their service provider, which hopefully will reduce or eliminate grey areas where either party thinks that the other is taking care of this. The service providers Attestation of Compliance should clarify exactly what their responsibilities are in this area in a formal written statement, allowing more accurate selection of vendors and clarifying the controls for which the merchant is responsible. Organisations can access the standards and detailed summary of changes from v2.0 to v3.0 at the PCI SSC website:

22 Q1: WHAT ARE THE MAIN CHANGES TO THE STANDARD THAT WILL AFFECT CONTACT CENTRES IN VERSION 3.0 OF PCI DSS? Well the good news is that, whilst version 3.0 has many changes, as contact centres are always Cardholder Not Present (CNP), they seem to have sidestepped the additional requirements of version 3.0 and the impact on the contact centre is minimal. Many of the changes between version 2.0 and 3.0 are additional guidance and general clarification. Additionally, five areas of compliance have specific changes; penetration testing, inventorying system components, vendor relationships, anti-malware & physical access to systems. 22

23 QSAS AND SELF-ASSESSMENT Depending on the merchant level (see the earlier section on The Card Payment Ecosystem), businesses can either self-certify PCI compliance or use a Qualified Security Assessor (QSA) who is accredited by the PCI SSC. Only Level 1 merchants with over 6 million transactions per year or who are a Compromised Entity (having experienced attacks before) must have an annual QSA audit rather than the self-assessment questionnaire. Businesses should be encouraged to see QSAs as expert consultants, rather than as auditors who are just there to tick boxes, agree compliance and then disappear for a year. Service providers have two levels rather than four, with a cut-off point of 300,000 aggregated card transactions per year. Service providers also have to prove compliance, but to each card brand, rather than to an acquiring bank (which merchants have to do). The proof of compliance is a formal Attestation of Compliance (AOC) which is usually signed by the Financial Director, and states that all PCI requirements have been met. Each card brand provides a list of compliant service providers on its website. QSA-audited PCI certification offers independently confirmed security, which removes the issue of how an organisation might interpret a PCI requirement in an internal self-assessment. Merchants who are looking for a service provider should investigate the limit of the scope that any self-assessment is taken, for example a cloud-based solution provider only applying it to the segments of their platform that handle sensitive data. Merchants may feel that a holistic perspective of security is more appropriate, and should also ask how the service provider tracks its assets (for example software versions, servers, operating and transport systems), in order to identify risk and react more quickly. Businesses should be aware that proving compliance is not simply a matter of making sure all of the requirements are covered, but is also about understanding which parts of the business fall into the scope of the PCI compliance audit. It is important that whoever runs the PCI compliance programme, whether internal or external, is experienced in interpreting it fully. QSAs should look at intent and risk - what was the PCI requirement trying to achieve, and what risk was it trying to minimise? 23

24 Q2: AS PCI DSS STANDARDS CHANGE FREQUENTLY, HOW CAN WE FUTUREPROOF OUR CONTACT CENTRE SO THAT WE DON T HAVE TO KEEP INVESTING IN NEW SOLUTIONS OR RE-ENGINEERING PROCESSES? We would say the change has generally been in terms of the rules becoming tighter. As the cybercriminals become more intelligent, so must the rules and the processes that merchants use to protect their customers data. The fundamental principles of PCI DSS have remained the same over the years and the changes have mainly come from clarification over what used to be some slightly woolly guidelines. Good information security practices within the contact centre are something all quality organisations should and do take seriously, so investing in security around the infrastructure, process and people in a contact centre is never money wasted, as long as it is done in a pragmatic, balanced way. De-scoping your payment environment using our tools allows the merchant to put the onus on the third party for the compliance. So rather than manage each change yourself, we do it for you with technology removing most of the headache and cost. 24

25 DIVISION OF RESPONSIBILITIES In recent ContactBabel research carried out in , just over half of all respondents managed their PCI compliance program by having dedicated trained and qualified personnel (either singular, or as a team) look after the process, this being particularly prevalent in medium and large operations. As there is likely to be a positive correlation between the number of card payments taken and the size of the contact centre, this would seem to make sense. This is not to say that smaller contact centres necessarily have a laissez-faire approach to PCI compliance, as they seem just as likely as large operations to seek external advice, whether through the auditing of self-assessment questionnaires or through consultancy provided by qualified security advisors. Figure 7: How is your PCI compliance programme run? (by contact centre size) 70% How is your PCI compliance programme run? (by contact centre size) 60% 58% 56% 50% 51% 40% 30% 20% 18% 25% 36% 39% 29% 17% 21% 20% 36% 22% 20% 21% 31% 10% 0% Small Medium Large Average Self-assessment questionnaire, non-audited or audited internally Self-assessment questionnaire, audited externally Qualified security advisor (external) A trained and qualified person or team (internal) PCI DSS compliance will usually involve different stakeholders from different departments, all of whom have varying responsibilities, experience and priorities. The security department wants compliance at all costs, whereas those working in the contact centre or involved in improving the customer experience will want to optimise the customer journey. The Head of Finance will have to find the budget to pay for compliance projects, and will also be responsible for paying any fines due to fraudulent activities and or non-compliance. Externally, the requirements of various regulatory bodies may have to be met. 7 The 2014 UK Contact Centre Decision-Makers Guide 25

26 Q3: WHO IN THE ORGANISATION SHOULD RUN THE PCI COMPLIANCE OPERATION? Good question! PCI compliance places a significant requirement on IT, so it is fairly typical that this would rest within the IT department and often for SMEs this would be an IT Director or Head of. Within larger organisations, PCI would again commonly sit with IT but with support of a Compliance Manager or team. Something we ve seen since the changes to v3.0 is a swing towards a risk-based compliance strategy which not only encompasses IT and technical infrastructure, but the entire organisation. So, rather than a hands-on technical implementation which has historically seen the responsibility sit with IT, the shift we are seeing is to more of an operational level (Operations Managers, Compliance Managers non-it) to manage the PCI journey. 26

27 BALANCING PCI DSS WITH OTHER REGULATIONS Just as PCI DSS compliance can mean a balancing act between customer experience, risk and cost, there can also be potential trade-offs between vertical market-specific regulations and payment card standards. In general, the standard methodology for how PCI DSS guides the handling of data in the presentation, storage and in transit stages of payment processing is also appropriate to meet the aims of many healthcare providers as well as the parts of the financial services industry which are most interested in guarding customers personal data. However, there are certain vertical markets and regulations that seem potentially to cross swords with the PCI DSS s aim to minimise the storage of cardholder data, whereas others broadly match the PCI DSS s aim of protecting, deleting and/or encrypting sensitive data.: The Telemarketing Sales Rule 8 (US) states that telemarketers must create an audio recording of the entire phone transaction The Financial Conduct Authority (UK - formerly the FSA) requires organisations to retain recorded calls and communications The Health Insurance Portability and Accountability Act (HIPAA) requires organisations to meet security and privacy standards in health data Other regulations and agreements that affect call recording within the financial services sector include: o AML (Anti-Money Laundering) o Basel II & Basel III Accords o ECOA (Equal Credit Opportunity Act) o FDCPA (Fair Debt Collection Practices Act) o GLBA (Gramm-Leach-Bliley Act) o MiFID (Markets in Financial Instruments Directive) o Sarbanes-Oxley Act o SEC 17-a-4/NASD 3010 (Securities Exchange Act 1934) o TILA (Truth in Lending Act) o USA Patriot Act There are also many national and state-wide (US) regulations around telephone recording

28 PCI DSS certification, referring as it does to the security of data, shares many of its aims with other, vertical market specific regulations that concern personal identification. For example, the Health Insurance Portability and Accountability Act (HIPAA) refers to issues concerning personally identifiable information in the healthcare sector of the US. While HIPAA certification in itself does not exist, there is a shared focus on the encryption of data, managing call recordings and other issues that mirror PCI requirements. HIPAA guidelines strongly encourage personal identification information to be removed or not collected within call recordings, and we see that PCI DSS compliance continues to become part of an ongoing, business-as-usual corporate attitude towards information security even in cases where other regulations must also be followed. On the face of it, there are huge amounts of cross-over between PCI DSS and many vertical marketspecific regulations, as the aims of a superior information security strategy, and the methods chosen to achieve this are widely applicable to most businesses. There are a few occasions where PCI DSS and specific industry regulations do bump heads however. In particular, the UK s Financial Conduct Authority (FCA) requires recorded interactions to be kept for long periods, so that it is available as evidence for future cases of mis-selling, customer complaint or fraud. The FCA wants call recordings to be full, unequivocal and untampered with, so as to guarantee the accuracy and completeness of any evidence - a desire which is clearly at odds with PCI DSS regulations around the storage of sensitive authentication data. FCA regulations state that calls that conclude with agreements must be recorded and stored securely so that they may not be tampered with, and must be easily accessible for no less than six months, which does not sit easily with the PCI DSS ideal of strong encryption, minimal storage of card information and the strict nonrecording of card verification codes. The later part of this report that investigates the handling of call recordings looks at various measures by which both aims can be achieved. 28

29 BEST PRACTICE Compliance with PCI DSS should be seen in the wider context of a far-reaching information security framework, which may also take into account industry-specific regulations. There is likely to be a balance to be found between compliance with the various regulations in the context of the business s unique processes and internal guidelines. There may be policies and activities that are helpful for most, if not all businesses: make sure that contact centre employees do not share passwords or user IDs with each other, in order to maintain a segmented and auditable security and access environment limit the number of employees given access to full card information. For example, restrict access to call recordings based on logging and corporate role, only allowing screen recording playbacks that display payment card information to managers and compliance officers, having it masked for all other users manage the physical and logical access to stored recordings and regularly report upon those accessing this information do not allow payment card data to be transferred through non-encrypted means, including , web chat, SMS or other means, and have the means to identify and delete it immediately if present initial focus should be on improving business processes, rather than implementing technology. For example, analysing and restricting access to cardholder information to only those employees who actually need it will significantly reduce the risk of fraud even before implementing any technology quarterly vulnerability scans should be carried out via an external approved scanning vendor approved by the Payment Card Industry Security Standards Council (PCI SSC), which holds a list of these. ASVs perform penetration tests on the company s network in order to verify that it cannot easily be hacked use secure data centres and limit physical access to servers which store payment card information do not record sensitive authentication data such as the card validation code in any circumstances if possible use strong encryption for the storage and transit of voice traffic, call recordings, screen recordings and personal identification data, making sure that the most current guidelines on encryption and transmission protocols are adhered to up-to-date, fully patched and automated malware, anti-virus and personal firewall software (of particular importance to homeworkers) - requirements 5 and 6 regularly review stored data, and keep only that which is necessary for business or regulatory purposes. For example, hotels need to keep customers credit card details from the reservation point until checkout: there is no hard and fast rule. 29

30 CURRENT PCI COMPLIANCE METHODS USED The following tables shows the methods that 200+ UK contact centre operations were using in 2014 to work towards PCI compliance in the contact centre. 59% of respondents chose to stop or pause voice recording during the payment process, a significant increase on 2013 s figures. Just over half use manual processes and train their agents about PCI compliance, rather than focusing on automation. A clean desk policy is in place in over one third of respondents operations and 1 in 4 obscure the data entered onto the agent s screen There has been a significant increase in the proportion of respondents using an automated IVR to take payment, up from around 1 in 6 in 2013, to over 1 in 4 in A minority use screen recording applications that do not capture the card details on screen, and 1 in 10 detect and block the phone s DTMF tones, with 9% using a cloud solution outside the contact centre. Figure 8: Methods of assisting with PCI compliance PCI compliance method % respondents Pause and resume voice recording, which stops while card payment is taken 59% Manual processes and training to ensure payment information is handled correctly 51% Clean desks / rooms - where pen, paper and mobiles are prohibited 37% Take payment via automated IVR mid-call or at the end of the call 29% Obscure the data entered on an agent's screen 25% Screen recording application does not capture card details on-screen 19% Detect and block the phone's DTMF tones 10% Cloud-based solution so that payment information does not enter the contact centre 9% 30