PCI Data Security Standard (Archived Report)

PDF version of this report
You must have Adobe Acrobat reader to view, save, or print PDF files. The reader
is available for free

PCI Data Security Standard

by Paul Ulasien

Docid: 00011448

Publication Date: 1404

Report Type: STANDARD


According to the annual report on US General Purpose Credit Cards, consumer
and commercial credit, debit, and prepaid cards issued in the United States combined to
generate $4.077 trillion in spending at merchants in 2013, up 7.9 percent from 2012.
The Payment Card Industry has long recognized the importance of protecting personal information and personal
data, and continues to evolve standards and applications designed to meet new
threats and challenges. PCI Data Security Standards address the concerns of consumers
and merchants to maintain the authenticity and integrity of payment card
information with guidelines that protect the vital interests of
their customers.

Report Contents:

Executive Summary

[return to top of this report]

When consumers offer their bank card at the point of sale, over the Internet, on the phone, or through
the mail, they want assurance their account information is safe.

Unlike the medical industry where regulations to
ensure the privacy of medical
information are common place, the nature of e-Commerce
as a ubiquitous and free market phenomena supports an incentive for the entire
e-Commerce and payment card industry to remain unfettered by
government-imposed oversight.

As a result, the Payment Card Industry Security Standards Council (PCI
founded by American Express, Discover Financial Services, JCB (formerly know
the Japan Credit Bureau), MasterCard Worldwide, and Visa International, was
formed with all five payment brands sharing equally in the council’s
Each entity has equal input to the PCI SSC while also maintaining
independent control for compliance and validation of standards to their respective
providers and merchants.

PCI Data
Security Standards (DSS) v.3.0, outline the current guidelines for the
deployment of PCI data over the
Wireless LAN (WLAN).
The PCI SSC incorporated into PCI DSS the
for Intrusion Detection Systems/Wireless Intrusion Prevention System
(IDS/WIPS) to automate wireless scanning for
large organizations. Wireless guidelines clearly define how wireless
applies to PCI DSS v2.0 compliance. In addition, PCI
DSS v3.0 provides additional clarification, guidance, and information of
evolving standards not included in the previous v2.0 standard.

Exponential growth and adoption of mobile and cloud computing applications
is creating
areas of security risks for merchants and the payment card industry. PCI SSC
began addressing this with the release of PCI Mobile Payment Acceptance Security
Guidelines v 1.0 in February 2013. While not yet fully mandated by PCI SSC, the
guidelines and best practices published in the v 1.0 documents are produced to
educate and create awareness of the challenges faced by the payment industry.  However, the best of security practices and procedures can never replace
"buyer beware" mentality. Using caution and common sense in
providing personal
and financial information can mitigate the occurrences of fraud and

In addition, a Cloud Special Interest Group has been formed by PCI SSC to
address emerging security issues related to cloud computing. There are a number
of factors to be considered when migrating to cloud services, and organizations
need to clearly understand their needs before they can determine if and how they
will be met by a particular solution or provider. Evaluations of risks and benefits may change as
technology becomes more established and its implications become better
understood .


[return to top of this report]

The PCI SSC is an

Table 1.
PCI Security Standard Framework

PCI DSS Framework

Build and
Maintain a Secure Network

(requirements 1 and 2)

Cardholder Data

(requirements 3 and 4)

Maintain a
Vulnerability Management Program
(requirements 5 and 6)

Strong Access Control Measures

(requirements 7, 8 and 9)

Monitor and Test Networks

(requirements 10 and 11)

Maintain an
Information Security Policy

(requirement 12)

PCI Security Standard Framework

The latest version of the PCI DSS is Version 3.0 released in November 2013 and is active from January 1, 2014 to
December 31, 2016. In general, PCI DSS v3.0 provides
additional clarification, guidance, and information of evolving standards not
included in v2.0. Table 2 provides a summary of the changes from PCI DSS v2.0 to
PCI DSS v3.0.

Table 2. Summary of the Changes from PCI DSS v2.0 to PCI DSS v3.0

Table 2. Summary of the Changes from PCI DSS v2.0 to PCI DSS v3.0

Section PCI DSS v2.0

Section PCI DSS v3.0


Clarified that SAD must not be
stored after authorization
even if there is no PAN in the
between PCI
DSS and PA
between PCI
DSS and PA –
Clarified that all applications
that store, process, or transmit
cardholder data are in scope for
an entity’s PCI DSS assessment,
even if PA – DSS validated.
Clarified PCI DSS applicability
to payment application vendors.
Scope of
Assessment for
Compliance with
Scope of PCI
Added examples of system
components, and added guidance
about how to accurately
determine the scope of the
assessment. Clarified the intent
of segmentation. Clarified
responsibilities of both the
third party and their customers
for scoping and coverage of PCI
DSS requirements, and clarified
the evidence that third parties
are expected to provide for
their customers to be able to
verify the scope of the third
party’s PCI DSS assessment.
Additional Guidance
PCI DSS into
Business – as –
Usual Processes
New section to provide “business
as usual” guidance for
implementing security into
business – as –
usual (BAU) activities to
maintain on – going PCI DSS
compliance. Note that this
section includes recommendations
and guidance only, not new PCI
DSS requirements.
Additional Guidance
Added new heading to separate
PCI DSS scoping section from 
sampling section


Sampling of
For Assessors:
Sampling of
Enhanced sampling guidance for
Additional Guidance
Instructions and
Content for
Report on
Instructions and
Content for
Report on
Former content relocated to
separate documents – PCI DSS 
ROC Template and PCI DSS ROC

Reporting Instructions


Compliance  –
Completion Steps
Updated section to focus on
assessment process rather than


and Security
and Security
At the start of this section,
added language to define the
column headings in this section,
removed references to “In
Place,” “Not In Place” and
“Target Date/Comments” columns.


Continued in v3.0, there are no less that 64
descriptors containing 200 sub-descriptors. The PCI DSS framework, at a
helps to categorize the process of PCI DSS compliance so that even the
of merchant or payment processors can have an intelligible and understandable
compliance guideline. The PCI DSS framework and descriptor general
are as follows:

Build and Maintain a Secure Network

Requirement 2: Do not use vendor-supplied defaults for
system passwords and
other security parameters

  • Hackers often use vendor
    default passwords and other vendor default settings to compromise systems.
    These passwords and settings are well known in hacker communities and
    determined via public information.

Protect Cardholder Data

Minimizing risk due to
interception of protected data is the intent of requirement 3. Encryption
is a
critical component of cardholder data protection. With encryption
cryptography, data is rendered unreadable and unusable unless the proper
decrypting key is known. All methods of protecting stored data should be
considered as potential risk mitigation opportunities. Examples include,
storing cardholder data unless absolutely necessary, truncating cardholder
data if full PAN is not needed, and not sending PAN in unencrypted

Requirement 5: Use and regularly update anti-virus

  • Many vulnerabilities and malicious viruses enter the
    via e-mail activities, file transfers and other employee activities.
    Anti-virus software must be used on all systems commonly affected by
    to protect systems from malicious software.

Many system
vulnerabilities are fixed by vendor-provided security patches. All systems
must have the most recently released and appropriate software patches to
protect against exploitation by employees, external hackers, and viruses.
in-house developed applications, numerous vulnerabilities can be avoided
using standard system development processes and secure coding

Implement Strong Access Control Measures

Requirement 8: Assign a unique ID to each person with
computer access

  • Assigning a unique
    (ID) to each person with access ensures that actions taken on critical data
    systems are performed by, and can be traced to, known and authorized

Requirement 10: Track and monitor all access to network
resources and cardholder data

  • The presence of logs in all environments allows thorough
    tracking, analysis and audits in the event that something does go wrong.
    Determining the cause of a compromise is very difficult without system
    activity logs.

Requirement 12: Maintain a policy that addresses

  • Security policy establishes a strong baseline for
    organizations and informs employees what is expected of them. All
    should be aware of the sensitivity of data and their responsibilities for
    protecting it as well as changes to and updates applying to all policy

In addition to the twelve requirements in the PCI DSS, the PCI Security
also include:

  • PIN Entry Device (PED) Security Requirements- PCI PED applies to
    manufacturers who specify and implement device characteristics and
    for personal identification number (PIN) entry terminals used for payment
    financial transactions. Merchants should use only PIN entry devices that
    tested and approved by the PCI SSC. As of April 2014, 751 PEDs from
    vendors have been
    authorized by the PCI SSC are listed at:

    PCI Approved PIN Entry Devices
  • Payment Application Data Security Standard (PA-DSS) – The PA-DSS is
    software developers and integrators of payment applications that store,
    process or transmit cardholder data as part of authorization or settlement
    when these applications are sold, distributed or licensed to third
    Most card brands encourage merchants and third party agents to use payment
    applications that are validated independently by a PA-QSA company and
    for listing by the PCI SSC. As of April 2014, a validated list of 884 payment
    applications for new deployments and 2108 payment applications for existing
    deployments from over 400 vendors are listed at:

    PA-DSS Validated Payment Applications
  • Point-to-point Encryption (P2PE) v1.1:
    Introduced at the end of 2011 as P2PE v1.0, P2PE was updated to v1.1 and
    published in April 2012. P2PE is an optional program to provide a
    comprehensive set of security requirements for P2PE solution providers to
    validate their hardware-based solutions, and may help reduce the PCI DSS
    scope of merchants using such solutions. P2PE is a cross-functional program
    that results in validated solutions incorporating the PTS Standards,
    PCI DSS, and the PCI PIN Security Standard.

Merchant Compliance

Merchants who store, process, or transmit cardholder data are required
through their acquirers (e.g. banks or other collecting/processing/scanning
institutions) to validate compliance with the PCI DSS.  Acquirers are
responsible for ensuring that all of their merchants comply with the PCI DSS
requirements.  However, there are differing levels of collection
depending of the size and type of merchant which can impact the merchant’s
ability to comply with the PCI DSS. Knowing this, the PCI SSC, has
established a
methodology of merchant levels through which merchants can identify their
of activity and an associated level of compliance validation and compliance

All merchants will fall into one of the four merchant levels based on
card transaction volume over a 12-month period. Transaction volume is based
the aggregate number of  payment card transactions (credit, debit and
prepaid) from the merchant. Merchant levels designated and identified as
one of four different levels. Table 3 depicts the PCI DSS Merchant Levels.

Table 3. PCI DSS Merchant


Table 3. PCI DSS Merchant

Merchant Level

Level Definition


  • Any merchant,
    "regardless of acceptance channel, processing over
    6,000,000 Visa transactions per year.
  • Any merchant that has suffered a hack or an
    attack that resulted
    in an account data compromise.

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

  • Any merchant identified by any other payment
    card brand.


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


  • Any merchant processing 20,000 to
    1,000,000 Visa e-commerce
    transactions per year.


  • Any merchant processing fewer than 20,000
    Visa e-commerce
    transactions per year, and all other merchants-regardless of
    channel-processing up to 1,000,000 Visa transactions per

In addition to adhering to the PCI DSS, compliance validation is
required for
Level 1, Level 2, and Level 3 merchants, and may be required for Level 4
merchants. It is the expectation of the card issuer, for all acquirers and
merchant levels 1, 2, 3, existing and new, to be compliant within the set
dates as established by the PCI CCS and that level 4 merchants follow within
due date of guidelines of their representative acquirer. Table 4 lists
DSS Compliance Requirements.

Table 4.
DSS Compliance Requirements

Table 4.
DSS Compliance Requirements


Validation Action

Validated By


  • Annual
    On-site PCI Data Security Assessment and
  • Quarterly
    Network Scan
  • Qualified
    Security Assessor or Internal Audit if signed by Officer of the
  • Approved
    Scanning Vendor


  • Annual PCI
    Self-Assessment Questionnaire and

  • Quarterly
    Network Scan
  • Merchant
  • Approved Scanning Vendor


  • Annual PCI
    Self-Assessment Questionnaire and

  • Quarterly
    Network Scan

  • Merchant

  • Approved
    Scanning Vendor


  • Annual PCI
    Self-Assessment Questionnaire and

  • Quarterly
    Network Scan

  • Merchant

  • Approved
    Scanning Vendor

In December 2013, Visa released statistics on merchant compliance with the
Payment Card Industry (PCI) Data Security Standard (DSS). Visa reported that as
of the end of 2013, 97 percent of large merchants (more than 6 million transactions)
were PCI DSS-compliant (unchanged from December 2012) and 83 percent of midsize merchants (1 – 6 million
transactions) were PCI DSS-compliant
with 90 percent at the end of 2011). These two merchant categories continue to
approximately 63 percent of Visa’s total transaction volume. In addition 100
percent of both
Level 1 and 2 Visa merchants were validated as to not storing prohibited data in
their systems.

Visa has also
the PCI Compliance Acceleration Program to provide financial incentives and
establish enforcement provisions for acquirers to ensure their merchants
validate PCI DSS compliance. To keep up pressure for meeting compliance and validation due dates, card
are levying  fines to and through acquirers to force the respective
merchants into compliances. Payment card companies are steadily increasing
on banks that process transactions for noncompliant merchants. Visa will
acquirers between $5,000 and $25,000 a month for each Level 1 and 2 merchant
has not validated. Acquirers failing to provide confirmation that their
Level 1
and 2 merchants are not storing full track data, CVV2, or PIN data face
fines up
to $10,000 a month per merchant, subject to escalation.

Call Center Compliance Issues

PCI DSS standards define requirements for the back end storage of
information, however,  the
PCI SSC does not have the same level of definition for front end data,
whether through Web sites,
Interactive Voice Response (IVR) systems or call center agents. In a
center, customers read their credit card information,
CVV codes, and
expiration dates to call center agents. There are few controls which prevent
agent from
skimming (credit card fraud) this information with a recording device or
computer or physical note pad. Home-based telephone agents pose an
level of challenges, requiring the company to secure the channel from the
home-based agent through the call center hub to the retailer applications.

To address some of these concerns, on January 22, 2010 the
PCI SSC issued a revised FAQ about call center recordings. It is a
of PCI DSS requirement 3.2 to store any sensitive authentication data,
card validation codes and values, after authorization even if encrypted. It
therefore prohibited to use any form of digital audio recording (using
such as wav, mp3 etc) for storing CAV2, CVC2, CVV2 or CID codes after
authorization if that data can be queried; recognizing that multiple tools
that potentially could query a variety of digital recordings.

PCI DSS Wireless/Mobile/Cloud Guidelines

The current wireless guidelines for PCI DSS
recommend the use of Wireless Intrusion
Prevention System (WIPS) to automate wireless scanning for large
Wireless guidelines clearly define how wireless security applies to PCI DSS

PCI DSS wireless requirements can be broken down into the
following two primary categories.

  1. Generally applicable wireless requirements: These are
    requirements that all organizations should have in place to protect their
    networks from attacks via rogue or unknown wireless access points (APs)

  2. Requirements applicable for in-scope wireless networks: These are
    requirements that all organizations that transmit payment card information
    over wireless technology should have in place to protect those systems.

The DSS Wireless guidelines apply to the
deployment of
Wireless LAN (WLAN) in cardholder data environments (CDE). A CDE is defined
as a
network environment that possesses or transmits credit card data. WLANs are
highly susceptible to eavesdropping and intrusion. The DSS Wireless
provide recommendation to configurations and policies that include the

Secure Deployment

  • Change default passwords and SSIDs on
    wireless devices.
  • Enable WiFi Protected Access (WPA) or WPA2
    security.  Set up APs in WPA or
    WPA2 mode with 802.1X authentication and AES encryption. Use of Wired
    Equivalent Privacy (WEP) in CDE is
    not allowed after June 30, 2010.
  • Restrict physical access to known wireless
  • Archive wireless access centrally using a
    WIPS for 1 year.
    Review wireless access logs daily.
  • Develop usage policies to list all
    wireless devices
    regularly. Develop usage policies for the use of wireless devices.

Minimum Scanning Requirements for Wireless

  • Scan all sites with CDEs whether or not
    they have known
    WLAN Access Points (AP) in the CDE. Sampling of sites is not allowed. A
    is recommended for large organizations since it is not possible to
    scan or conduct a walk-around wireless security audit[11] of all sites on
    quarterly basis
  • Enable automatic WIPS alerts to instantly
    notify personnel
    of rogue devices and unauthorized wireless connections into the CDE.

  • Prepare an incident response plan to
    monitor and respond to
    alerts from the WIPS. Enable automatic containment mechanism on WIPS to
    rogues and unauthorized wireless connections.

Intrusion Detection Systems/Wireless Intrusion
Prevention System (WIPS) Implementations

  • Use a centrally controlled wireless IDS/WIPS to monitor for
    unauthorized access and detect rogues and misconfigured wireless
  • Enable historical logging of wireless access that can provide
    granular wireless device information and store event logs and statistics
    at least 90 days.
  • Enable WIPS features that automatically disable rogue wireless
    devices connecting to the CDE as well as accidental or malicious
    of wireless clients.
  • Ensure the WIPS signature set is regularly updated as new
    threats are discovered.
  • Coordinate logging events with other networking devices within
    the organization.
  • Add processes and policies that will regularly read and act on
    the data provided by the WIPS.
  • Maintain a current topology of all physical locations of access

Mobile Payment Acceptance Security Guidelines

  • Preventing unauthorized physical device and
    logical device access

    • Installing malware protection
    • Vulnerability scanning of
      mobile devices for secure state verification
    • Disable unnecessary device
    • Response policies and
      procedures for loss, theft, or disposal of
      decommissioned devices
  • Secure payment acceptance solutions
    • Ensure the secure use of the
      payment-acceptance solution
    • Using online acceptance
      solutions versus offline solutions
    • Secure authentication to
      prevent unauthorized use
    • Provide the ability for
      cardholders to confirm that a merchant is a
      legitimate customer of their solution
    • Issuance of secure receipts

Competing Standards

[return to top of this report]

PCI DSS is considered
a universal standard within the payment card issuer industry. Issuers such
as Visa, MasterCard, American Express
and Discover Card each monitor acquirer and merchant compliance with
programs of applicability that addresses any nuances of their respective
acquirers and merchants. Additionally, each issuer defines its own set of
and any penalties for non-compliances.

Discover Card

PCI DSS requirements are similar to the requirements established by the
Discover Information Security and Compliance
(DISC) program. The DISC program is designed specifically for Discover Card
service providers and merchants to support the mandatory requirements set
forth by PCI DSS by safeguarding cardholder information and limiting data
compromises. Quality management security services provided through DISC help
merchants and service providers prevent information system security events
and attacks leading to identity theft and payment card fraud.

Merchant Risk Council

While not a competing entity to PCI SSC, The Merchant Risk Council is a
non-profit organization of e-Commerce service providers and merchant to
a community of interest for making the Internet a preferred place to shop

Future Directions

[return to top of this report]

PCI compliance is
working. According to the Ponemon Institute a full 64% of
organizations that are compliant with PCI DSS had no breaches involving
card data over the past two years, compared to only 38 percent of non-compliant
organizations. In the light of the successes for PCI SSC and PCI DSS, in
order for the PCI SSC and other organization such as the MRC to remain
independent, it will be imperative for each organizations and associated
to press forward with wider compliance and validation. The sovereignty of
providers and merchants outside the span of control from regulatory
oversight is
tantamount to the health of the Internet and e-Commerce. This will take the
concept of self-rule and self-regulation to a level not before seen in an
unregulated market. By the implementation of fines and restrictions of
access to
card resources, the industry will be able to keeps its affairs out of the
of federal, state and local controls.

Fines and penalties for non-compliance are beginning to
take hold. If a member knows or suspects a security breach with a merchant
service provider, the member must take immediate action to investigate the
incident and limit the exposure of cardholder data. As an example, if a Visa
member fails to immediately notify Visa Fraud Control of the suspected or
confirmed loss or theft of any Visa transaction information, the member will
subject to a penalty of $100,000 per incident. Members are subject to fines,
to $500,000 per incident, for any merchant or service provider that is
compromised and not compliant at the time of the incident.

Focus on Mobile

In February 2013, PCI Mobile Payment Acceptance Security
Guidelines v 1.0 was published to address the unique and emerging uses of
payment system hardware and applications. Though not currently mandated by
SSC, the guidelines and best practices published in v 1.0 documents are
to help educate and create awareness of challenges faced by the payment
industry. This document focuses on guidance for merchants that plan to
payments with a mobile device.

Where merchants‘ mobile device hardware and software
implementation cannot currently meet the guidelines documented v 1.0, those
merchants may choose to implement a PCI-validated, Point-to-Point Encryption
(PCI P2PE) solution. Implementing such a solution would include the addition
a PCI-approved Point of Interaction (POI) device. With the use of a
solution, account data is encrypted by the POI, and the mobile device would
simply act as the conduit through which the encrypted payment transaction is

A modicum of caution and common sense can also
payment card security for Business to Consumer (B2C) and Business to
Business to
Business (B2B) transactions. Giving credit card and personal information to
un-trusted sources is never recommended. For online transactions only use
that implement standard security protocols Hypertext Transfer Protocol
(HTTPS) with the Secure Sockets Layer (SSL) v2 and v3 and Transport Layer
Security (TLS) protocol to provide encrypted communication and secure
identification of a network
Also checking the credentials of the transacting organization through
accreditation agencies such as the Better Business Bureau is a recommend

Cloud Computing

Cloud computing is a form of distributed computing with evolving
The evolving technical aspects of cloud computing from a PCI DSS
requires evaluating risks and benefits paradigms as the technology becomes
established and its implications and applicability to PCI DSS security
better understood. From a foundational perspective, cloud security is a
responsibility between the cloud service provider (CSP) and its clients. If
payment card data is stored, processed or transmitted in a cloud
PCI DSS will apply to that environment, and will typically involve
validation of
both the CSP’s infrastructure and the client’s usage of that environment.

The allocation of responsibility between client and provider for managing
security controls does not exempt a client from the responsibly of ensuring
their cardholder data is properly secured according to applicable PCI DSS
requirements. Given the current state of cloud technology, it is important
note that all cloud services are not created equal. Emerging policies and
procedures should be agreed between client and cloud provider for all
requirements, and responsibilities for operation, management and reporting
should be clearly defined and understood for each requirement.

[return to top of this report]

About the Author

[return to top of this report]

Paul Ulasien is President and Senior Partner for
Business Training
He is a seasoned IT/Networking professional with more than 25 years of
experience in telecommunications, consulting, IT management, and teaching –
an undergraduate and graduate professor in Business, IT, and Networking
technologies. He writes frequently for Faulkner Information Services
is the author of
The Corporate Rat Race: The Rats Are Winning
and The Power of a Grace
Mr. Ulasien resides in
Marana, AZ, USA.

[return to top of this report]