A big thank you to a reader for suggesting this post with a post to my Miscellaneous Questions page with a number of questions related to call centers.
Based on their questions, the first clarification that needs to be made is in regards to pre-authorization data. In a call center environment where operators are taking orders over the phone and accepting credit/debit cards for payment, until the card transaction is either approved or declined, we are talking pre-authorization data. Only cardholder data after authorization or decline (also known as post-authorization data) is covered by the PCI DSS.
However, as I have noted before, the card brands expect pre-authorization data to be protected with the same voracity as post-authorization data. The PCI DSS can provide organizations with a guideline on how to protect pre-authorization data, but pre-authorization is not in-scope for PCI compliance.
That said, just because it is not in-scope for PCI compliance; do not think a QSA is not going to consider it. Any good QSA should review the pre-authorization process and identify any issues that might be present that could result in the compromise of pre-authorization data.
“Do we need a “clean room?””
From a PCI compliance perspective, the answer is ‘no’, although there are a number of PCI requirements that would lead you to restrict what is in the actual call center. However, best practice is to operate any call center handling potentially sensitive data in a ‘sterile’ environment. That means clean desks, no personal items at the workstation, no paper and pens for writing things down, locked down workstations and other restrictions so that sensitive information is not leaked from the call center.
The idea for creating a sterile environment by banning cell phones and giving personnel lockers to secure their personal items is in line with what we see in call centers. In addition, I think most call center organizations find that their clients require such approaches to ensure that their customers’ privacy and security is maintained.
In addition to all of the physical security, call center personnel need to be trained regarding security and privacy. Call center personnel need to sign an agreement that says they acknowledge that they will be in contact with cardholder data and that the cardholder data is to be protected in compliance with the PCI DSS and other regulatory and legal requirements.
“Is it necessary to segregate our team responsible for taking credit card information?”
The PCI DSS does not require credit card handling call center personnel to be segregated from other cal center personnel. But again, best practice would be to put your credit card handling team together for a variety of other reasons. Another best practice is to segregate call center teams that handle sensitive data from personnel that do not handle sensitive data.
“The PCI standard 3.3 is not very clear on the subject in my opinion.”
“ … however, parts of the standard seem to me very unclear.”
The first thing people responsible for call centers should do is read the PCI SSC’s FAQ (#5362) on call center recordings and PCI compliance. The next thing they should do is read my postings on call center recordings.
- Call Center FAQ Significantly Changes
- Call Center FAQ Changes – AGAIN
- The Missing Link In Call Center Recordings
Requirement 3.3 of the PCI DSS is very clear in my opinion.
“Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed).”
What I am sure is confusing are the caveats surrounding this requirement. The first caveat states that personnel with a business need to know can have access to the full primary account number (PAN). These personnel are typically accountants that work chargebacks and disputes, not call center personnel. In a call center environment, the system may display the PAN for customer confirmation purposes. However, once the PAN is submitted for authorization, the full PAN must no longer be available and must be masked to the first six digits and/or the last four digits.
The second caveat is that where legal or regulatory conditions apply, requirement 3.3 is superseded by any legal or regulatory conditions. The best example of this is that United States’ federal law mandates the last four digits of the PAN be displayed on a POS receipt. However, this second caveat should not impact any call center as they do not generate any documentation that would be regulated.
“I know that there are system requirements.”
Another area where call centers can be at risk is the call center workstation. The reason is that the workstation comes into contact with the cardholder data. Depending on how the workstation is used and configured, will determine the level of security surrounding the workstation.
The big move in call centers today is to use virtual workstations either through Citrix, VMware or similar solutions. In these situations, the workstation is just a display device. The server creating the virtual desktops needs to be physically and/or logically segregated from other virtual servers.
The threat to a physical workstation in any environment is that a keyboard logger is installed to record everything typed into the physical workstation. As a result, the physical workstation needs to have their system/event logs monitored and have anti-virus, anti-malware and critical file monitoring implemented.
Hopefully this answers a lot of the questions call centers have regarding PCI compliance.
Hi PCI Guru
Do call centre personal lockers need to be located outside of the call centre itself?
Just to be clear, this is not a PCI requirement, this is a “best practice” from the call center industry.
Yes, personnel lockers should be located outside the actual call center. That way personal items are not accessible unless the person leaves the call center.
Much appreciated
Thank you
Regards,
Dan
In regards to scope for call centre apps… If a call centre had a number of bespoke in-house crm apps that don’t hold any card holder data. Would these apps fall out of scope for PCI DSS compliance?
http://orbisps.com/pci-compliance
“Every merchant that accepts credit cards must comply with PCI, but smaller merchants often achieve compliance by using compliant services. If you don’t store, transmit or process any credit card data, then your systems are out of scope for PCI DSS compliance.”
Do you know why this descoping would this be limited to smaller mechants?
Where can I find examples of PCI scoping excersizes? Can a company have apps that fall out of scope fo PCI DSS compliance and still label itself as PCI compliant?
First you are a call center and you are asking about cardholder data being stored. That implies that your call center operators take cardholder data.
Applications that do not store cardholder data are always out of scope. That said, you need to prove that is the case as a QSA cannot just take your word for it as fact. And you cannot just assume that there is no cardholder data stored in your CRM when you are processing it over the phone. The worst thing that could happen is for your organization to declare itself PCI compliant only to find out at some later point there was cardholder data recorded in comment or other fields of the database.
The scope of a PCI assessment is related to the cardholder data environment. The cardholder data environment is defined as where cardholder data is processed, stored and/or transmitted. In a call center environment that is usually the operator workstations, call recording system and any servers that might be involved in serving up data entry screens or validating payments. If your network is not properly segmented then your entire environment will be in-scope.
I have a number of posts on network segmentation as well as call centers and even some that discuss scoping.
“Applications that do not store cardholder data are always out of scope.” – This is not entirely correct.
Firstly applications that process or transmit cardholder data are also in scope, even if not storing it.
Secondly, applications may be in scope if they are connected to, or can impact on the security of, other applications and systems that store, process or transmit cardholder data. The reasoning behind this is that attackers will find multiple routes into systems that contain cardholder data. A vulnerable application that can be compromised to then pivot attacks to a system with cardholder data also represents a risk – a risk that PCI DSS seeks to reduce.
(Apologies for resurrecting an old post but I only recently came across this)
You are correct that an application that processes or transmits is in-scope including any application that has access to the CDE although how and what it has access may mitigate that fact. Regardless a QSA needs to assess everything connecting to the CDE to determine the risk and relevance.
Unfortunately, I had a email conversation with the individual and then wrote the reply and that conversation was not conveyed in my response. The application in question was not part of the CDE which is what is missing and why I stated it was not in-scope. I apologize for that fact.
All your points are right and they are really useful for those who do not know about it,i am glad that you gave us some ideas about it,in Finland country issue for call center are really common and never been encounter that things.
hi PCI Guru
I agree with all of your points (and Emma’s) and think that this is a very comprehensive list of all things that should be considered when securing a callcenter. As Emma points out, there are some solutions that not only de-scope the agent entirely but also the callcenter entirely regardless of how customer data is received (online form, email, fax, postal mail, application, at home agent etc). I would suggest looking at our system PeepSafe and/or Semafone’s system which can jointly de-scope all of the above to remove the headache of PCI whilst eliminating the risk of agents seeing cardholder data.
Hi PCI Guru,
A very balanced look at this, thanks. (Disclosure: I work for a company which specializes in helping contact centers to isolate CHD from their people, systems, call recorders, etc.)
One thing I was surprised about was that you didn’t link to the PCI SSC’s specific paper which addresses cardholder data in contact center environments. It’s called “Protecting telephone-based payment card data”, and it’s here: https://www.pcisecuritystandards.org/documents/protecting_telephone-based_payment_card_data.pdf. This guide, released in March 2011, has really helped to clarify questions in this area.
On your final point, there are a few systems on the market which isolate call center agents entirely from the cardholder data, and can prevent keyloggers from capturing any CHD at the desktop level. This is not a PCI requirement, but more and more companies (particularly outsourcers) seem to be taking the view that agents should be shielded from CHD.
(Also, just check the third URL above – it’s not constructed right. Feel free to edit out this line)
Emma.
Thank you Emma for your comments and for catching my oversight of not pointing to the PCI SSC white paper.