Sunteți pe pagina 1din 9

PCI-DSS Standards


I love my credit card. Over the last month I’ve paid for fuel, food, concert tickets, dinner, car insurance, a few CDs and some MP3s. I’ve bought things online, face to face, via automated terminals and even via the phone. It’s easy. Select the item, present the card, authorise it and hey presto (when I’ve not hit the limit), the goods and services are paid for.

Consumers love the ease of payment and being able to have the item now. Retail outlets love that their goods or services have been bought and paid for. Card companies love the interest and fees that are made from the service they offer. Compared to other payment methods, credit cards are one of the most flexible forms of payment and generally are accepted globally.

But how often does the average person think beyond the sale? Do they think where the card details are going, how they are being used, who can see them? In a busy restaurant, at the garage, online, most individuals just hand over their card or enter the details without a second thought. Do they know what is happening to their data from the card, will the last legitimate time the card is used be the gateway to the card being compromised within the merchant environment?

What is the risk?

Every transaction made has a risk attached to it. For the consumer the risk is his/her card holder data being compromised combined with the problems, heartache and potential upset that this would bring. For the merchant, the processing of card holder data makes them an attractive target for the data thief – the more transactions the merchant processes, the more worthwhile the target becomes.

The Primary Account Number (PAN) and the authentication data stored on the card or chip are the prize for the data thief. Once stolen, those details would be sold on and it could be maybe weeks or months before they are used for card-not-present frauds or other activities. UK fraud during 2011, was £220.9 million in card-not-present frauds (1).

However, risk goes beyond the stolen cards. Unlike the consumer where he or she would be compensated for any losses by the card schemes, the merchant can and has incurred heavy financial losses through fines, forensic investigation costs and quite often reputational damage from public disclosure of the losses.


Card companies have been continually trying to reduce the millions of pounds lost globally through fraud, which the card companies, merchants and ultimately the consumer pay for. The majority of card fraud can be traced back to the data thief exploiting flaws within merchant’s security or weak business practices. If the merchant could identify those potential security flaws, change their business practices before they are exploited, then in theory losses could be reduced significantly.

PCI-DSS – the Payment Card Industry Data Security Standard was born out five different programs:

Visa Card Information Security Program, MasterCard Site Data Protection, American Express Data Security Operating Policy, Discover Information and Compliance, and the JCB Data Security Program. Each program’s intention was to create an additional level of protection for card issuers by ensuring that merchants meet minimum levels of security when they store, process and transmit cardholder data – effectively plugging those aforementioned exploitable holes.

The Payment Card Industry Security Standards Council (PCI SSC 2) was formed, and in December 2006 when the councils founding payment brands, American Express, Discover Financial Services, JCB International, MasterCard Worldwide, and Visa Inc aligned their individual policies and released version 1.0 of the Payment Card Industry Data Security Standard (PCI DSS). Version 2.0, the current version, was released in October 2010.

PCI-DSS is now a mandatory standard that the card companies expect merchants to achieve and then maintain, regardless of their size and complexity.

What is PCI-DSS?

PCI DSS version 2.0 is the global data security standard that any business of any size must adhere to in order to accept payment cards, and to store, process, and/or transmit cardholder data.

There are six core goals with twelve requirements that must be met by the merchant, as described in table 1.

PCI – Data Security Standard


PCI-DSS Requirements

Build & maintain a secure network

1. Install and maintain a firewall configuration to protect cardholder data.

2. Do not use vendor-supplied defaults for system 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 and regularly update anti-virus software or programs

6. Develop and maintain secure systems and applications

Implement strong access control measures

7. Restrict access to cardholder data by business need to know


8. Assign 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 policy that addresses information security for all personnel

Table 1. PCI-DSS Requirements.

Each requirement contains further sub-requirements that the merchant will need to comply with based on collection, storage, transmission and processing of card holder data within the merchant's organisation. The nature of the merchant's business processes and infrastructure will define which requirements are necessary for compliance.

Actual compliance is achieved either by the completion of an Annual Self Assessment Questionnaire (SAQ), or Annual onsite review by Qualified Security Assessor - QSA (PCI DSS Assessment), in conjunction with a Quarterly Network Scan performed by Approved Scanning Vendor – ASV.

Whether the merchant requires an annual review or completes the self assessment questionnaire will be defined by the level the merchant falls into.

Merchant Levels

All merchants will fall into one of the four merchant levels based on Visa transaction volume over a 12-month period, as described in table 2. 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, members must consider the aggregate volume of transactions stored, processed or transmitted by the corporate entity to determine the validation level as described in table 3. If data are not aggregated, such that the corporate entity does not store, process or transmit cardholder data on behalf of multiple DBAs, members will continue to consider the DBA’s individual transaction volume to determine the validation level. As specified by Visa.










Any merchant- regardless of acceptance channel- processing over 6,000,000 Visa transactions per year.

Merchants processing over 2.5 million American Express Card transactions annually or any merchant that

Merchants are currently not categorized into levels based on transaction volume. Discover takes a "risk based approach" for validating compliance.

Merchants processing over 1 million JCB transactions annually, or

Merchants processing over 6 million MasterCard transactions annually, identified b another payment card brand as

American Express

compromised merchants

Level 1, or merchants that

1 Any merchant that Visa, at its sole discretion, determines should meet the Level 1 merchant requirements to minimize risk to the Visa system.

otherwise deems a Level 1

have experienced an account data compromise


Any merchant- regardless of acceptance channel- 2 processing 1,000,000 to 6,000,000 Visa transactions per year.

Merchants providing 50,000 to 2.5 million American Express transactions annually or any merchant that American Express otherwise deems Level 2


Merchants processing less than 1 million JCB transactions annually

Merchants processing 1 million to 6 million MasterCard transactions annually


Any merchant processing 20,000 to

Merchants processing less than 50,000


Merchants processing 20,000 to 1 million MasterCard e-commerce transactions annually

3 1,000,000 Visa e- commerce transactions per year.

American Express transactions annually


Any merchant processing fewer than 20,000 Visa e- commerce transactions per year,



All other MasterCard Merchants

4 and all other merchants-regardless of acceptance channel-processing up to 1,000,000 Visa transactions per year.

Table 2. Merchant Levels.









Annual onsite review by QSA (PCI 1 DSS Assessment) and Quarterly Network Scan by ASV

Quarterly Network Scan by ASV AND one of the following:


Annual onsite review by QSA- PCI DSS Assessment

Annual onsite review by QSA (PCI DSS Assessment) and Quarterly Network Scan by ASV


2 Quarterly Network Scan by ASV

Annual Self Assessment Questionnaire

Annual Self Assessment Questionnaire and Quarterly Network Scan by ASV


Quarterly Network Scan by ASV AND one


3 Quarterly Network Scan by ASV

of the following:


Annual Self Assessment Questionnaire and Quarterly Network Scan by ASV


Annual onsite review by QSA- PCI DSS Assessment


4 Quarterly Network Scan by ASV

Annual Self Assessment


Annual Self Assessment Questionnaire and Quarterly Network Scan by ASV

Table 3. Merchant Levels and compliance validation requirement.

PCI-DSS in the real World

PCI-DSS on the surface appears to be a relatively straight forward set of requirements to understand, but when considered in the unique context of the merchant’s organisation:

PCI-DSS is a standard that will bring change to the merchant’s organisation.

PCI-DSS is a standard that will require a merchant to understand and question their own business processes.

PCI-DSS is a standard that will require a varying degree of resource, expertise, time and investment by the merchant.

PCI-DSS is a standard that will require review of and changes to software, configuration or hardware within the IT Infrastructure.

PCI-DSS is a standard that will require the creation of enforceable polices within the organisation, regarding card holder data.

PCI-DSS is a standard that needs to be maintained by the organisation.

Ultimately the implementation of PCI-DSS involves review and change, the scale of which depends on the size, complexity and business of the merchant’s organisation. For some organisations, change is embraced, for others change is dreaded, but let’s be positive and sum up PCI-DSS as:

PCI-DSS is a standard that brings great opportunity to merchants to improve, streamline and change their business for the good of the organisation and the customers they serve, while potentially saving money and reducing the threat of credit card fraud.

Implementing PCI-DSS within the Merchant’s Organisation

Imagine you are working in a highly successful retail organisation employing around 5000 staff, processing several million card transactions a year through your stores. With a very successful online commerce presence again processing millions of transactions globally. Your company, like all others, is operating within the current difficult economic climate and then PCI-DSS rears its head.

You’ve done well so far and largely ignored it, but today it has landed on your desk and you are charged with leading your employer’s organisation to compliance. Where do you start?

A good starting point is understanding clearly the overall objective of PCI-DSS. PCI-DSS is not about getting a certificate that says your organisation is compliant and getting the card companies off your back. PCI-DSS is about protecting your customer’s credit card data.

From my perspective, I would take this definition as the starting point -

“A standard designed with the aim of protecting the customer’s credit card data when they are received, used, transmitted or stored within the merchant’s organisation.”

Protecting the customer’s credit card data – clearly defines the objective.

Received, Used, Transmitted and Stored are the four words that when put into the context of credit card payments, will go forward to define the scale and complexity of achieving compliance within the organisation. From these four words, the initial questions that should be asked are along the lines of:

Received – How is the card holder data collected as part of the payment process? Where is card holder data collected – online, face to face, over the phone? What systems does your organisation use to take the card holder data?

Used – How is the card holder data used within your organisation? Is it just for processing payment or is it being used for other purposes, such as identifying a customer account? Why is it being used?

Transmitted - Is the card holder data transmitted around your organisation? How is it being transmitted? What is being used to transmit the card holder data? Is the card holder data encrypted? What methods are being used (such as email, internal post, courier?). Why is it being transmitted?

Stored – How is the card holder data being stored within your organisation? Where is it being stored? What format is it being stored in (digital, paper). Why is it being stored?

Answering these sorts of questions starts to build up a picture of how card holder data enters your business, how it is collected, why it is required, where it flows and ultimately ends up. Quantify, validate, assess and consider the answers you gather, cross reference against standard operating procedures and existing policy where necessary. This is a relatively simple starting approach, but starting simply is the best approach.

Build on the picture, identify what devices are used to collect the cardholder data, how it moves through your organisation’s infrastructure, who has access to it, when and why. Which systems are using the card holder data should be identified, as well as any places card holder data could be inadvertently stored or transmitted.

Remember card holder data is card holder data regardless of where it is held, collected, transmitted and stored. PCI-DSS applies to the merchant’s organisation and as part of the analysis exercise, a certain amount of lateral thinking maybe needed.

For example:

A major UK university was recording for training purposes certain calls, and inadvertently was recording customers disclosing the card details as part of a purchase. While the telephone recording system wasn’t part of the payment process, just by recording the card holder data, it came into the? scope of the PCI-DSS process. In this case, the recording of calls was stopped and all backups of such calls purged, removing the problem from scope.

It is common for many UK universities to offer public access computers to their students. Whereas best practice in the University environment does secure the computers, it is still

down to the individual to decide to use the computer and take the potential risks. Many Universities also offer external hosted web payment solutions from PCI-DSS compliant suppliers. Should the staff direct the student to make a payment through the public access computers, the public access computers and network infrastructure become part of the payment process and applicable to PCI-DSS. This would apply equally to merchants who introduce web based quick solutions into their stores.

Currently the advice given across the sector is for staff not to direct the student to University provided computers to make payments, however, if the student makes the decision to use the University provided facilities, the risk is theirs.

Many merchant organisations provide purchasing cards/ corporate credit cards to their employees. Under PCI-DSS card holder data is card holder data regardless of whose card it is. It is not uncommon for the PAN to be used in administration systems to link the card statement back to the employee who has been using it. Statements with card holder data maybe collected and stored, transcribed and emailed around an organisation as well as ending up in the accounting system (plus backups of the account system, email system and file storage). Everything relating to these cards would be within the scope of PCI-DSS, regardless that they are the responsibility of the merchant organisation.

CCTV systems designed to protect the locations where card data are processed may inadvertently be recording card holder data as it is being transcribed. Suddenly the CCTV system becomes a repository for storing card holder data and would be within the scope of PCI-DSS.

Reducing the scope

PCI-DSS isn’t about becoming compliant; PCI-DSS is about reducing the risk to the card holder and to the merchant’s organisation. The more places card holder data are present, the more places the merchant must secure and thus the costs and complexity of protecting the data increase.

Card holder data can only be compromised if they are present within the merchant’s organisation.

Ask WHY !

Why do we collect this card holder data?

Why do we store this card holder data?

Why do we take card payments this way?

Why do we NEED this card holder data?

If there is no justification for the card holder data to be collected and stored, then remove it.

For the card holder data that is essential to the business, then do we need to store it within the merchants organisation, can the collection and processing be outsourced to a PCI-DSS compliant third party and reduce the risk and cost to the merchant?

Final thoughts

At first look, the PCI-DSS requirements appear to be very heavily focused towards IT, to the point that it can give the misconception that card holder data protection is all about the IT. Remember, IT is just the tool; it is the business processes and the people following them, using the IT that ultimately protects the card holder data, the customer and the merchant.

Think: People + Process + Technology = Card Holder Data Security.

The need for the merchants to report compliance either through an audit or self assessment questionnaire is an annual requirement. Ensuring that the merchant continues to maintain compliance is an ongoing process that happens every minute of every day where card holder data is processed.


1. /


Matt Ball

Matt is Business Analyst currently from the University of Leicester & project manages the IT Services aspect of PCI-DSS, as the University continues to work towards achieving compliance.

A founder member of the joint Higher Education/Further Education PCI-DSS Special Interest Group, Matt has been actively leading on the development of HE/FE PCI-DSS framework to support institutions as they work towards compliance.

Prior to joining the University, Matt has worked in the private, education & academic sectors on diverse range of projects which have included e-commerce, data warehousing, e-learning, finance and manufacturing solutions.