Contact Us: +44 (0) 845 070 1750 

Search
Information
Online Shop

PCI DSS COMPLIANCE

LOOKING FOR PCI DSS COMPLIANCE?

Find everything you need right here!

 

Introduction to the PCI DSS (Payment Card Industry Data Security Standard)

The PCI DSS must be met by all organizations (merchants and service providers) that transmit, process or store payment card data. The PCI DSS (sometimes referred to as a compliance standard) is not a law. It is a contractual obligation applied and enforced - by means of fines or other restrictions - directly by the payment providers themselves.

 

The currently applicable version of PCI DSS, since 01 October 2008, is version 1.2 (here's the download). It is published and controlled by the independent PCI Security Standards Council ('SSC') on behalf of its five founding members. The SSC also defines qualifications for Qualified Security Assessors (QSAs) and Approved Scanning Vendors (ASVs); and it trains, tests and certifies QSAs and ASVs.

 

For information, implementation assistance and guidance, buy the PCI DSS v1.2 Compliance Toolkit:


PCI DSS compliance requirements

The Standard basically requires merchants and member service providers (MSPs) who store, process or transmit cardholder data to:

  • Build and maintain a secure IT network
  • Protect cardholder data
  • Maintain a vulnerability management program
  • Implement strong access control measures
  • Regularly monitor and test networks
  • Maintain an information security policy

Merchant PCI DSS compliance criteria and PCI levels

Compliance requirements are dependent on a merchant's activity level. There are four levels, based on the annual number of credit/debit card transactions. While Payment Brands determine the compliance levels for their own brands, acquirers are usually responsible for determining the compliance validation requirement levels of their merchants. The compliance levels are based on the following table and usually refer to the number of transactions of each payment brand in a year. Whether or not transaction volume applies only to e-commerce transactions or to payments processed through all channels is decided seperately by each payment brand but, in general, all transactions are included.

 

Level 1 Criteria
Merchants with over 6 million transactions a year, or merchants whose data has previously been compromised
Level 1 Validation Requirements
Annual Onsite Security Audit (reviewed by a QSA or Internal Audit if signed by officer of merchant company and pre-approved by acquirer) and quarterly network security scan

Level 2 Criteria
Merchants with 1,000,000 to 6 million transactions a year
Level 2 Validation Requirements
Annual Self Assessment Questionnaire
Quarterly Scan by an Approved Scanning Vendor (ASV)

Level 3 Criteria
Merchants with 20,000 to 1,000,000 transactions a year
Level 3 Validation Requirements
Quarterly Scan by an Approved Scanning Vendor (ASV)
Annual Self Assessment Questionnaire

Level 4 Criteria
Merchants with less than 20,000 transactions
Level 4 Validation Requirements
Annual Self Assessment Questionnaire

Quarterly Scan by an Approved Scanning Vendor (may be recommended or required, depending on acquirer compliance criteria)

Service Provider PCI DSS Compliance Criteria

A Service Provider is an organisation that is involved in processing, storage, transmission and switching of transaction data and/or cardholder information, but is not merchant or a card brand member. Hosting providers and others providing services to merchants would also fall into this category.

 

Service Provider compliance requirements are defined by the Payment Brands. Visa and MasterCard categorize service providers according to transaction volume and/or type of service provider.


Level 1 Criteria
Visa - All VisaNet processors and all payment gateways
MasterCard – All Third Party Processors’ (TPP’s). All Data Storage Entities (DSE’s) that store, transmit, or process greater than 1,000,000 total combined MasterCard and Maestro transactions annually. All compromised TPPs and DSE’s

Level 1 Validation Requirements
Visa and MasterCard– Annual onsite review by a QSA. Quarterly network scan by an ASV


Level 2 Criteria
Visa - Service Providers (agents) not in Level 1 that store, process, or transmit more than 1 million accounts/transactions annually
MasterCard – All DSE’s that store, transmit, or process less than 1 million total combined MasterCard and Maestro transactions annually

 

Level 2 Validation Requirements
Visa – Annual onsite review by a QSA. Quarterly network scan by an ASV.
MasterCard – Annual self-assessment questionnaire. Quarterly network scan.

 

Level 3 Criteria
Visa - Service Providers (agents) not in Level 1 that store, process, or transmit less than 1 million accounts/transactions annually
Level 3 Validation Requirements
Visa – Annual self-assessment questionnaire. Quarterly network scan

Payment Brand PCI Compliance Programmes

While the PCI DSS is a common standard, each payment brand has its own compliance programme. Note that there may be regional variations for VISA (eg USA and Canada), while Mastercard has a single global standard, and that acquiring banks - not the payment brands - are usually responsible for enforcement. All detailed compliance enquiries should therefore be directed to one's acquiring bank. Here are the PCI DSS Compliance programs for each of the five founding members of the PCI DSS Council:

 

Amex DSOP

 

Discover Card DISC

 

JCB Card PCI DSS

 

MasterCard SDP

 

VISA US CISP

VISA EUROPE AIS

VISA CANADA AIS

VISA ASIA AIS

Scope of PCI DSS 

The PCI DSS applies to any type of media on which card data may be held - this includes hard disk drives, floppy disks, magnetic tape and back up media, but also embraces printed/handwritten credit & debit card receipts where the full card number is printed. These receipts are often held by merchants as a paper record of the transaction and may be used for voucher recovery purposes, or as evidence of the transaction if the acquirer issues a request for information (RFI). The card number must be held in full and therefore the receipts must be stored securely.

 

Retailers must also all other areas where card details may be stored, processed or transmitted. For example, many EPOS systems take a copy of the card details (either swiped separately, or extracted from EFT receipt data) and store them unencrypted within their own databases for reconciliation and reporting purposes.

Achieving compliance with PCI DSS

The PCI DSS compliance procedure can take anything from a day to many weeks, depending on what is uncovered by the vulnerability assessment scan and the self-assessment questionnaire. Organizations that currently have a good level of information security are likely to be compliant a lot more quickly than those that don't.

 

QSAs (here is a current list) carry out inspections of PCI DSS implementations and determine a recommendation of compliance to the various payment brands. Each individual payment brand will separately determine whether to accept the recommendation of compliance and whether a detailed review of the report of compliance and compensating controls is warranted.

 

The starting point for all organizations that need to comply is to download the Payment Card Industry Self-Assessment Questionnaire (see below) and to contact a PCI Approved Scanning Vendor (ASV).

 

The initial starting point should be your own copy of the manual on PCI Compliance: PCI Compliance: Understand and Implement Effective PCI Data Security Standard Compliance - it is a good investment!

PCI DSS and ISO/IEC 27001

While the PCI Standard was not written to map specifically to ISO27001, ISO17799, CobiT or any other existing framework, it sits clearly within the ISO 17799 (now ISO27002) framework and organizations that have implemented an ISO 17799 ISMS should be able, with minor additional work, to also demonstrate their conformance with the PCI standard. A document that maps the individual clauses of the PCI DSS v1.2 to the individual clauses of ISO/IEC 27001 Annex A/ISO 17799:2005 is available to subscribers within the KnowledgeBank. Subscribers can also access additional guidance on using ISO27001 as a PCI DSS management framework. Nine Steps to Success describes how ISO27001 can be implemented to provide an overarching best practice information security management framework that will encompass the requirements of PCI DSS.

Enforcement of PCI DSS (FAQs below from the PCI DSS website)

What are the consequences to my business if I do not comply with the PCI DSS?
"The PCI Security Standards Council encourages all businesses that store payment account data to comply with the PCI DSS to help lower their brand and financial risks associated with account payment data compromises. The PCI Security Standards Council does not manage compliance programs and does not impose any consequences for non-compliance. Individual payment brands, however, may have their own compliance initiatives, including financial or operational consequences to certain businesses that are not compliant."

How long does a merchant have to become compliant with PCI DSS version 1.2?
"The individual payment brands have each established their own requirements and timelines for various entities, including merchants, to become compliant."

Can an entity be fined if it is compliant with the original PCI DSS but not version 1.2?
"All compliance programs including but not limited to fines are managed individually and distinctly by the payment brands".

Are there any plans to make compliance easier for small to medium sized merchants?
"All merchants must comply with the same standard to be considered compliant with PCI DSS version 1.2. Approaches for validation of compliance differ based upon merchant size and are determined based upon levels set individually by the payment brands. The PCI Security Standards Council will support future work efforts intended to build technical guidance and other tools into the self-assessment questionnaire."

 

This all means that each payment provider will take whatever action it thinks it can make stick, commercially, to enforce the PCI DSS. There are no standardised penalties across all the payment brands, and the PCI council has no plans to create any. Each brand will require seperate evidence of compliance and, given that the original dates for compliance have now all passed, is likely to set different dates for different levels and different entities to demonstrate compliance. The acquiring bank is usually the best channel through which to discuss compliance deadlines and penalties, which are all imposed by means of the payment brand/acquiring banks contract with the merchant.

PCI DSS Resources

Manual & Guide: PCI Compliance: Understand and Implement Effective PCI Data Security Standard Compliance

 

Glossary - this document defines terms used in PCI DSS v 1.2 and the other resources available to ASVs and QSAs.


The PCI Self-Assessment Questionnaire (SAQ)

The PCI Data Security Standard Self-Assessment Questionnaire is a validation tool intended to assist merchants and service providers in self-evaluating their compliance with the Payment Card Industry Data Security Standard (PCI DSS). All merchants and their service providers are required to comply with the PCI Data Security Standard in its entirety. In February 2008, the PCI Security Standards Council introduced the new Self-Assessment Questionnaire (and Attestation of Compliance), consisting of five validation categories:

 

SAQ Validation Type

    Description
Download SAQ
1

Card-not-present (e-commerce or mail/telephone-order) merchants, all cardholder data functions outsourced. This would never apply to face-to-face merchants.

A

2

Imprint-only merchants with no electronic cardholder data storage

B

3

Stand-alone terminal merchants, no electronic cardholder data storage

B

4

Merchants with POS systems connected to the Internet, no electronic cardholder data storage

C

5

All other merchants (not included in Types 1-4 above) and all service providers defined by a payment brand as eligible to complete an SAQ.

D

 

 

 

The Security Audit Procedures document is designed for use by assessors conducting onsite reviews for merchants and service providers required to validate compliance with PCI DSS requirements. The requirements and audit procedures presented in this document are based on the PCI DSS.

PCI DSS Security Audit Procedures (pdf)
PCI DSS Security Audit Procedures (locked Word)

 

PCI Security Scanning Procedures. The purpose and scope of the PCI DSS Security Scan for merchants and service providers subject to scans to help validate compliance with the PCI DSS. ASVs also use this document to assist merchants and service providers in determining the scope of the PCI Security Scan.

PCI DSS Security Scanning Procedures

 


PCI DSS Validation Requirements for Qualified Security Assessors (QSAs) v 1.2
To be recognized as a QSA by PCI SSC, QSAs must meet or exceed the requirements described in this document and execute the QSA Agreement with PCI SSC attached to this document as Appendix A.
PCI Qualified Security Assessor (QSA) Agreement
Sample QSA Feedback Form

 

PCI DSS Validation Requirements for Approved Scanning Vendors (ASVs)v 1.2
Recognition as an ASV by PCI SSC requires the ASV, its employees, and its scanning solution to meet or exceed the described requirements and execute the “PCI ASV Compliance Test Agreement” attached as Appendix A with PCI SSC. The companies that qualify are then identified on PCI SSC’s ASV list on PCI SSC’s web site in accordance with the Agreement.
PCI ASV Compliance Test Agreement
Sample ASV Feedback Form

 

PCI DSS Technical and Operational Requirements for Approved Scanning Vendors (ASVs) v 1.2
This document provides guidance and requirements applicable to ASVs in the framework of the PCI DSS and associated payment brand data protection programs. Security scanning companies interested in providing scan services as part of the PCI program must comply with the requirents in this document and must successfully complete the PCI Security Scanning Vendor Testing and Approval Process.

 

PCI DSS Approved Scanning Vendors

This list is updated on a regular basis. Any ASV that carries out a scan must be on the list at the point that the scan is carried out.

Verified by Visa (Payer Authentication Service/3D-Secure)

Verified by Visa (VbV) is a security protocol introduced in 2005 by Visa, for Internet-based (ie not for mail order or or telephone purchases) transactions only. VbV provides additional security for both the shopper and the merchant by enabling the cardholder to input a password to validate their transaction. While a cardholder may proceed with a transaction even if they have not entered a password, the mere availability of VbV shifts the chargeback liability from the merchant to the card issuer. Mastercard have a similar scheme, called SecureCode which applies to MasterCards and to Maestro Cards.

 

For full details of Visa VbV, go to: http://www.visaeurope.com/personal/onlineshopping/verifiedbyvisa/main.jsp

For full details of MasterCard SecureCode, go to http://www.mastercard.com/us/merchant/security/what_can_do/SecureCode/index.html

 

Featured Product
FREE CO2 calculator
Our clients
Subscribe to our newsletter
Read what our staff have to say about our products
Top 5 Sellers
Latest News
Alan Calder's Blog
184 © 2003 - 2008 IT Governance Ltd. | Website by Xanthos