1. No category

White paper
How to take your contact centre
out of scope for PCI DSS
Reducing cost and risk in credit card transactions for contact centres
How to take your contact centre out of scope for PCI DSS
Reducing cost and risk in credit card transactions for contact centres
Executive summary
With 77 per cent of UK companies admitting to a security breach (Source: The Ponemon
Institute, 2009), and up to 97 per cent of companies falling short of PCI compliance, call
centre security looms large on the boardroom agenda.
“77% of companies
admit to a
security breach
and up to 97%
fall short of
PCI compliance.”
Increasingly however, merchants are finding that eliminating customer card data from their
infrastructure means they can reduce the scope of PCI DSS. By doing so, they can reduce
the risk of a breach of card data and cut the cost of PCI DSS compliance.
The two principal approaches to reduce cost, complexity and the PCI DSS audit scope for
cardholder data are:
1. Tokenization
2. Point-to-point encryption
These emerging technologies are established for both high street and online retail channels
but the contact centre and voice transactions still present additional challenges.
Semafone has incorporated these technologies into a unique solution to tackle both fraud
risk and PCI compliance by ensuring that no payment information is heard by the agent,
or stored by the company.
Reducing cost and risk in credit card transactions for contact centres | June 2011 |
2
How to take your contact centre out of scope for PCI DSS
Reducing cost and risk in credit card transactions for contact centres
Contents
“Reducing the scope
of the PCI audit can
drive down costs
by more than 75%.”
Executive summary Contents
PCI DSS background and audit scope
Two ways to eliminate the need for customer card data The challenge for the contact centre How Semafone removes card data from the contact centre Reducing the scope of PCI DSS audits for the contact centre Cutting the cost of PCI audits
Conclusion and glossary
Reducing cost and risk in credit card transactions for contact centres | June 2011 |
2
3
4
5
6
7
8
10
11
3
How to take your contact centre out of scope for PCI DSS
Reducing cost and risk in credit card transactions for contact centres
Introduction: PCI DSS background
The Payment Card Industry Data Security Standard (PCI DSS) is the card schemes’
compliance programme to combat fraud and protect consumer card data. It applies to
all organisations that store, process or transmit cardholder information, from any of its
members’ cards (Visa, MasterCard, American Express, Discover and JCB).
“Level 1 retailers
spend an average
of £1.8m to become
PCI compliant.”
Source: Gartner
Larger organizations must have their annual compliance assessment carried out by an
independent Qualified Security Assessor (QSA), while smaller companies can use a SelfAssessment Questionnaire (SAQ). The current version of the standard (v2.0 since March
2011*) specifies 12 requirements organized into six “control objectives”.
From July 2012 MasterCard says that Level 2 merchants either have to have their SAQ
completed by an external QSA or they need an Internal Security Assessor (ISA) with PCI
DSS training to sign off their SAQ.
Control objectives
PCI DSS requirements
Build and maintain
1. Install and maintain a firewall to
protect cardholder data
2. Do not use vendor-supplied defaults for
passwords and other security parameters
Protect cardholder data
3. Protect stored cardholder data
4. Encrypt transmission of cardholder
data across open, public networks
Maintain a vulnerability
management program
5. Use up-to-date anti-virus software on all
systems commonly affected by malware
6. Develop and maintain secure
systems and applications
Use strong access controls
7. Need-to-know access to cardholder data
8. Give a unique ID to each person
with computer access
9. Restrict physical access to cardholder data
Regularly monitor
and test networks
10.Track and monitor all access to network
resources and cardholder data
11.Regularly test security systems and processes
Maintain an information
security policy
12.Maintain a business-wide policy that
addresses information security
* https://www.pcisecuritystandards.org/documents/protecting_telephone-based_payment_card_data.pdf
Reducing cost and risk in credit card transactions for contact centres | June 2011 |
4
How to take your contact centre out of scope for PCI DSS
Reducing cost and risk in credit card transactions for contact centres
PCI DSS audit scope
PCI DSS has five types of SAQ to be completed. The table shows how different types of
SAQ require less controls and can therefore cut the cost of PCI DSS compliance.
“Each type of SAQ
offers a different
number of
required PCI controls
and the costs
that go with them.”
SAQ
Description
No. of
controls
A
Card-not-present (e-commerce or mail/telephone order)
merchants, all cardholder data functions outsourced.
This would never apply to face-to-face merchants.
4
B
Imprint-only merchants with no electronic cardholder
data storage, or standalone, dial-out terminal merchants
with no electronic cardholder data storage.
29
C-VT
Merchants using only web-based virtual terminals,
no electronic cardholder data storage.
60
C
Merchants with payment application systems connected
to the internet, no electronic cardholder data storage.
80
D
All other merchants not included in descriptions for SAQ
types A- C above and all service providers defined by
a payment brand as eligible to complete an SAQ.
286
Reducing cost and risk in credit card transactions for contact centres | June 2011 |
5
How to take your contact centre out of scope for PCI DSS
Reducing cost and risk in credit card transactions for contact centres
Two ways to eliminate the need for customer card data
Account Data
“Eliminating customer
card data from
their infrastructure
lets merchants
cut the cost of PCI
DSS compliance.”
PCI DSS requires that merchants must eliminate, render useless, substitute or secure
(encrypted to the standards of PCI DSS) all cardholder data. It is rare that cardholder
data can be totally eliminated as it is required for refunds, future purchases, loyalty
programmes, reconciliation, etc. Therefore, merchants focus on substituting their
stored card data or rendering it useless. This is already happening on the high street and
online through point-to-point encryption and/or tokenization.
Storage
Data Element
permitted
Render Stored Account
Data Unreadale per Req. 3.4
Cardholder
Primary Account
Yes
Yes
Data
Number (PAN)
Cardholder name
Yes
Service Code
Yes
No x
No x
Expiration Date
Yes
No x
Sensitive
Full Magnetic Stripe Data
Authentication
CAV2/CVC2/
No x
No x
Cannot store per Req. 3.2
No x
Cannot store per Req. 3.2
Data
CVV2/CID
PIN/PIN block
Cannot store per Req. 3.2
Figure 1 PCI DSS Applicability Information v2.0
1. Point-to-point encryption
Point-to-point encryption can be used to protect and secure cardholder data between two
end points. Visa Europe in March 2010 issued a “Best Practices for Data Field Encryption”
with these goals*:
1. Limit cleartext availability of cardholder data and sensitive authentication data to the
point of encryption and the point of decryption
2. Use robust key management solutions consistent with international and/or regional
standards
3. Use key-lengths and cryptographic algorithms consistent with international and/or
regional standards
4. Protect devices used to perform cryptographic operations against physical/logical
compromises
5 Use an alternate account or transaction identifier for business processes that require
the primary account number to be utilised after authorisation, such as processing of
recurring payments, customer loyalty programmes or fraud management
2. Tokenization
Tokenization can replace cardholder data, ie the credit or debit card number, with nonsensitive data that can be used as a reference or a token. The card data is then vaulted,
usually by a third party, where again it is protected through encryption.
Format-preserving encryption and tokenization
Encryption and tokenization can both be used, so that the encrypted value or the token
retains the format of the original card number. It is also possible to retain the first six
digits (the Banking Identification Number – BIN – which identifies the issuing bank) and
the last four digits which do not need to be masked for PCI DSS, so they can be used by
production applications and viewed by users.
* Visa Europe’s Best Practices for Data Field Encryption, Version 1.0
Reducing cost and risk in credit card transactions for contact centres | June 2011 |
6
How to take your contact centre out of scope for PCI DSS
Reducing cost and risk in credit card transactions for contact centres
http://www.visaeurope.com/en/businesses__retailers/payment_security/downloads__resources.aspx
The challenge for the contact centre
Technology and services for the de-scoping of high street and online retailers are already
well established, with chip and PIN machines where the customer is present, and payment
pages hosted by the merchant’s Payment Service Provider (PSP) for online transactions.
“The contact centre
has its own specific
challenges for PCI
DSS compliance.”
However, the contact centre has its own distinctive issues, with three specific challenges
to address for PCI DSS compliance:
• The physical contact centre environment
• Call recordings
• Agents and network
Securing the physical contact centre environment
PCI DSS requires that employees are screened for security purposes. But if paper and pens
are available then other controls come into play. So any writing paper needs to be secured
and later destroyed so cardholder data can not be reconstructed. Many contact centres
have adopted paperless environments with only white boards and markers available.
Agents’ access to cardholder data also means that PCI DSS requires a policy covering
access to mobile phones, the web and email, as staff could theoretically use these tools
to transmit cardholder data out of the merchant’s environment.
Draconian measures such as banning pens, paper, mobile phones, personal effects, email
access and web access can have very negative impacts on the contact centre. It can make
it harder to retain staff and those who do stay resent being treated as potential thieves,
making it very difficult to create a positive work environment. No email and web access
within a contact centre is also impractical as these are required to fulfil day to day activities.
Call recordings
Customers share both cardholder data and Sensitive Authentication Data (SAD) ie the
PAN (Permanent Account Number), expiry date, issue number and their security code
(CVC, CVC2, etc). If merchants don’t take the security code then the call recordings can
be protected through encryption.
PCI DSS does not permit capturing the security code on call recordings even if the
recordings are encrypted. Barclaycard’s white paper, Safe and Sound – Processing
Telephone Payment Securely, details the challenges of the contact centre*.
Agents and network
The fact that contact centre agents generally input customers’ cardholder data on their
behalf brings the contact centre agent desktop into scope for PCI DSS, as the machine is
being used to enter this cardholder data.
Also, as the contact centre desktop is connected to the merchant’s network, this immediately
brings the merchant’s network into scope.
* Barclaycard Safe and Sound white paper
http://www.barclaycard.co.uk/business/documents/pdfs/processing_telephone_payments.pdf
Reducing cost and risk in credit card transactions for contact centres | June 2011 |
7
How to take your contact centre out of scope for PCI DSS
Reducing cost and risk in credit card transactions for contact centres
Removing cardholder data from the contact centre
Semafone is a contact centre solution that shields all PAN and CVC data from agents,
call recordings and screen recordings. Agents do not hear or see cardholder data, call
recordings do not capture either the PAN or CVC, and screen recordings only capture
asterisks and the last four digits of the PAN.
“The agent will only
see asterisks on the
Semafone hosted
web page as the
cardholder enters
their card data.”
Agents do not ask cardholders to speak their card details, they ask them to use their
telephone keypad to enter their PAN and CVC. Semafone masks the DTMF (Dual Tone
Multi-Frequency) tones from the cardholder’s telephone and replaces them with a flat
tone. This is achieved while voice communications remain intact between the agent and
the cardholder.
The agent can then call up Semafone’s ‘enable payment’ page for the merchant’s preferred
Payment Service Provider (PSP), passing across the cardholder name, transaction
reference, amount and any other payment details required for authorization (such as
cardholder address). The agent will only see asterisks on the Semafone hosted web page
as the cardholder enters their card data but other than the last four digits, no other digits
of the PAN and CVC are transmitted to the page.
The agent then verbally collects further payment details such as valid from, valid to and
issue number and enters these details into Semafone’s payment page. If the cardholder
makes a mistake, they can tell the agent who will then reset the PAN or CVC field from a
button on the hosted web page, or simply press the “star” button on their phone.
From the first six digits of the PAN (the BIN) Semafone can determine the length of the
PAN. Once the last digit of PAN has been entered by the cardholder the agent receives an
audio prompt and a visual cue in terms of the last four digits of the PAN being displayed
on the Semafone hosted web page. Semafone performs a Luhn digit check (an algorithm
that validates the card number) and if this fails Semafone shows the agent a message
indicating an invalid card number has been entered. The agent is then able to ask the
cardholder to re-enter their card details.
Once the transaction details have been collected, the agent can request the transaction
authorization. Semafone combines the details from its hosted payment page with the PAN
and CVC it has collected from the cardholder’s DTMF tones. Semafone then securely
transmits these transaction details to the merchant’s PSP through the PSP’s Application
Programming Interface (API) service.
The PSP returns to Semafone the results of the authorization including the authorization
code and the transaction token. These can be displayed by the Semafone hosted page or
can be posted back to the agent application.
Reducing cost and risk in credit card transactions for contact centres | June 2011 |
8
How to take your contact centre out of scope for PCI DSS
Reducing cost and risk in credit card transactions for contact centres
Removing card data from call recordings
Call recordings are an essential part of the modern contact centre, and mandated by
the FSA for mortgage companies when handling collections over the phone. They’re
also required for dealing with complaints and managers may use them for training and
instruction purposes.
“It is impossible
to reverse engineer
any card data
from the call
recording, putting
it safely outside
PCI DSS scope.”
However, it is important that customers’ credit card data is not retained in the recordings.
Semafone copes with this requirement by automatically removing the card data from the
recordings as they happen. The call recording will capture all voice communications but
DTMF tones are masked and only a flat tone is recorded. It is therefore impossible to
reverse engineer any card data from the call recording and Semafone has put the call
safely outside PCI DSS scope.
The Semafone approach has several advantages over the alternative approach of pausing
recordings:
1. Pausing call recordings is often in conflict with regulatory bodies that mandate
complete recordings
2. Triggering “pause” and “resume” by hand is not a robust system, with human
error resulting in either the capture of card details on the call recording (and thus
the loss of PCI DSS compliance) or the missing of important sections of the call,
which is causing major issues for quality monitoring and business improvement
Reducing cost and risk in credit card transactions for contact centres | June 2011 |
9
How to take your contact centre out of scope for PCI DSS
Reducing cost and risk in credit card transactions for contact centres
Reducing the scope of PCI DSS audits for the contact centre
Semafone in the cloud
By capturing card data (PAN and CVC), Semafone is technically in scope for PCI DSS.
However, Semafone can be deployed within the telephony cloud of the merchant’s network
provider rather than the enterprise itself.
“The merchant will
be deemed to have
outsourced their
payment process for
PCI DSS purposes,
as it will not
have handled any
cardholder data.”
While the telephone network provider will have to be PCI DSS certified, the merchant will
be deemed to have outsourced its payment process for PCI DSS purposes, as it will not
have handled any cardholder data.
In this case, if they have no customer facing card transactions they can complete an
SAQ A form and attest to two statements (“Restrict physical access to cardholder data”
and “Maintain a policy that addresses information security”), leaving just four controls to
implement for PCI DSS.
If the merchant has no customer-facing transactions, they can complete an SAQ C
attesting to 80 controls, automatically cutting out 206 controls from SAQ D.
Voice
DTMF
PSTN
PVG
WWW
C82
Provider
Edge
Network
DMZ LAN
SIP or TDM
connection
Firewall
DPM Server
SBC/CCM
Telco Data Centre DMZ
Firewall
Payment
Gateway
Customer Site – Out of Scope
PBX/ACD
Voice
Agents
LAN
CRM
Reducing cost and risk in credit card transactions for contact centres | June 2011 | 10
How to take your contact centre out of scope for PCI DSS
Reducing cost and risk in credit card transactions for contact centres
Figure 2 Semafone deployed within a telephony cloud
Semafone in the enterprise
Level 1 merchants gain
Level 1 merchants need to have a QSA
complete their Report on Compliance
(ROC) with the full 286 controls within
SAQ D. But if the merchant qualifies
for SAQ C with the permission of
their acquirer the amount of controls
is reduced to just 80.
Where a merchant does not deploy Semafone within their telephony network provider, but
within their enterprise itself, it is still possible to limit the scope of PCI DSS. The Semafone
telephony cards and servers can be segregated by firewalls, so the network outside the
firewall will be de-scoped. Importantly, this will include the contact centre environment,
including the agents’ desktops.
The merchant will still need to complete an SAQ C for the Semafone environment but will
not need these controls outside of the segregated area. As agents do not hear or see card
data there is no requirement to secure the physical contact centre environment.
So agents can have web access, email access, mobile phones and the use of paper and
pens at their desks. This helps to create a more productive environment and ensure higher
The story can be even better for Level
1 merchants that qualify for SAQ
A (a growing list, including utilities
such as gas, electric, water, phone,
cable, satellite TV, and ecommerce
businesses such as Amazon,
eBay, LastMinute.com and Expedia).
Qualifying for SAQ A means that with
their acquirer’s consent they can
report “Not Applicable” to 282 of
the 286 controls, leaving just
4 within scope.
Payment
Gateway
Voice
PSTN
DTMF
Firewall
WWW
“As agents do not
hear or see card
data there is no
requirement under
PCI DSS to secure
the physical contact
centre environment.”
PCI
Chassis
TPM/DPM
Server
On-Site DMZ
PBX/ACD
Voice
Firewall
Agents
LAN
CRM
Customer Site – Out of Scope
rates of staff retention.
Reducing cost and risk in credit card transactions for contact centres | June 2011 | 11
How to take your contact centre out of scope for PCI DSS
Reducing cost and risk in credit card transactions for contact centres
Figure 3 Semafone deployed within the merchant’s enterprise
Cutting the cost of PCI audits
“By removing the need
to handle customer
card data, merchants
can significantly
reduce the costs of
implementing and
maintaining PCI
DSS compliance.”
IT research firm Gartner reported in 2008 that merchant spending to protect cardholder
data and become PCI compliant increased by almost five times during the previous 18
months. Among the Level 1 retailers (more than 6 million transactions per year) Gartner
surveyed, an average of £1.8 million was spent to become PCI compliant, excluding the
costs of PCI assessment services.
Level 2 merchants (1-6 million transactions per year) spent £730,000 on PCI compliance
and Level 3 merchants (20,000 - 1 million transactions per year) spent an average of
£103,000, excluding security assessment. Gartner did not discuss Level 4 merchants in
the report.
The Ponemon Institute reported in March 2010 that Tier 1 merchants are spending
£150,000 for their annual PCI DSS audits. Ten per cent of these merchants were spending
more than £330,000.
The rising cost of compliance
Auditing costs for Level 2 merchants are set to rise significantly from this year with the
announcement that from June 2011 MasterCard will require that all Level 2 merchants must
either have an external audit through a qualified QSA or that their internal auditors have
attended and passed the PCI Internal Security Assessor (ISA) training.
By removing the need to handle customer card data, merchants can significantly reduce
the costs of implementing and maintaining PCI DSS compliance. Large enterprises can
pay over £150,000 for logging tools, for example, a sum that can be cut if the need for
such tools is outsourced.
Maintaining all of the latest security patches can also be a significant drain on compliance
budgets, especially if they need to be applied to each agent’s desktop, with the individual
testing that requires.
Reducing PCI audit scope cuts costs
Reducing PCI scope from SAQ D to SAQ C can drive down PCI compliance and audit
costs by more than 75 per cent. For merchants with no customer-facing transactions that
can de-scope to SAQ A, the reduction is closer to 90 per cent. Reducing the size of a
merchant’s card data environment also significantly reduces the cost of achieving and
maintaining PCI DSS compliance.
In a recent series of estimates carried out by Semafone, the annual cost per agent seat can
range from £11,324 for a small ten-agent contact centre with only anti-virus tools in place,
dropping to a Semafone-enabled SAQ A rating at a cost of £2,282, saving more than 75
per cent per year. In larger contact centres with greater economies of scale, costs can drop
from £1,213 to just £140, a saving of almost 90 per cent.
Reducing cost and risk in credit card transactions for contact centres | June 2011 | 12
How to take your contact centre out of scope for PCI DSS
Reducing cost and risk in credit card transactions for contact centres
Conclusion
PCI DSS compliance is continual and not just an annual audit. Merchants need to set longterm objectives to reduce their risks from cardholder data and to measure the ongoing
cost of doing so.
Glossary
API Application Programming Interface
For most organisations this will be to avoid managing cardholder data. The ability to
achieve this on the high street and online has been well understood for some time but this
has left the Achilles heel within the contact centre.
CVC Card Verification Code
DTMF Dual Tone Multi-Frequency
PAN Permanent Account Number
PCI DSS Payment Card Industry
Data Security Standard
PIN Personal Identification Number
Semafone is the only company that allows merchants to close the gap in their de-scoping
strategy by allowing them to remove their contact centres from PCI DSS compliance.
Semafone can reduce costs, ease the admin burden and contribute to a more productive
working environment for staff, helping merchants to finally realise the cost savings that
they want to achieve.
Advantages of Semafone for contact centres
Significantly reduced costs for PCI DSS compliance
Zero negative impact on staff working conditions
Enhanced security for customers
PSP Payment Service Provider
ROC Report on Compliance
SAD Sensitive Authentication Data
SAQ Self-Assessment Questionnaire
QSA Qualified Security Assessor
Reducing cost and risk in credit card transactions for contact centres | June 2011 | 13