This resource provides answers and resources to frequently asked questions regarding the Payment Card Industry Data Security Standard (PCI DSS). As you read the PCI DSS FAQ, you'll learn more about what the standard is, where it came from, what it requires, who it affects and what the role of IT is in achieving and maintaining compliance.
- What is the Payment Card Industry Data Security Standard?
- What are some PCI DSS requirements?
- Who is affected by PCI DSS?
- What is the role of IT in PCI DSS compliance?
- What are the penalties for noncompliance with PCI DSS?
PCI DSS is a global standard designed to help merchants protect customer account data -- namely credit card numbers -- from fraud. The standard spells out policies and procedures for improving the security of account data, including management, software design and network architecture. The PCI DSS standard was released in December 2004.
PCI DSS was developed by five financial companies: MasterCard Worldwide, Visa Inc., American Express Co., Discover Financial Services and JCB International Co. The group created the PCI Security Standards Council to ensure that merchants deploy at least minimum security requirements. The standard has evolved since its inception and will continue to do so to account for emerging security risks.
More compliance FAQs?
Get caught up on regulations and more with our IT compliance FAQs.
The PCI DSS standard has attracted its share of criticism since its release in 2004. Critics have been quick to point out that PCI compliance does not ensure security in a network environment or prevent data breaches. They warn that meeting the minimal standard could give organizations a false sense of security. One glaring example of this mind-set is the Heartland Payment Systems data breach, disclosed in January. Heartland was PCI DSS-compliant, and yet it experienced one of the largest breaches of credit card data in U.S. history. As security expert Eric Ogren observed, the Heartland breach highlights PCI limitations.
PCI DSS's advocates, including security expert Bruce Schneier, argue that without PCI DSS and other standards, fewer companies would take IT security as seriously as they should. Many maintain that complying with the standard is primarily a matter of good information practices States are incorporating the standard into regulations, like Nevada toughening its data protection law with cryptography and PCI requirements.
If an organization has reasonable security measures in place, it is already well on its way to PCI DSS compliance. And, in fact, IT pros say don't blame PCI DSS for TJX Cos. Inc.'s troubles. For organizations that are required to comply, IT plays the central role.
PCI DSS Q&A: Answering your questions
PCI DSS expert Ed Moyle of CTG addresses frequently asked questions of SearchSecurity.com readers.
PCI DSS: The structure of a standard
In this video, security expert Diana Kelley discusses the different levels of merchants in PCI DSS, how well merchants understand those levels and whether the government may eventually have to mandate controls over the card industry.
PCI DSS contains six general principles that deal with securing network components that support -- or come in contact with -- cardholder data transactions. Each principle includes at least one requirement, for a total of 12 requirements as of July. Many of the requirements are fundamental to maintaining a secure network in any industry. These include changing passwords from the defaults provided by vendors and regularly updating antivirus software. Other requirements are more specific to the payment industry, like putting restrictions on physical access to cardholder data.
The comprehensive requirements for PCI DSS, as outlined by the PCI Security Standards Council, are below. SearchSecurity.com has recorded a series of instructional videos, "PCI DSS and the 12 Requirements," featuring security experts Diana Kelley and Ed Moyle, co-founders of the consultancy Security Curve. In the videos, linked below, Kelley and Moyle review common questions regarding assessments and address compensating controls that may be used if a merchant cannot meet a requirement.
- Build and maintain a secure network.
- Protect cardholder data.
- Protect stored cardholder data. Video: PCI compliance requirement 3: Protect data
- Encrypt transmission of cardholder data across open, public networks. Video: PCI compliance requirement 4: Encrypt transmissions
- Maintain a vulnerability management program.
- Use and regularly update antivirus software. Video: PCI compliance requirement 5: Antivirus
- Develop and maintain secure systems and applications. Video: PCI compliance requirement 6: Systems and applications
- Implement strong access control measures.
- Restrict access to cardholder data by business need-to-know. Video: PCI compliance requirement 7: Restrict access
- Assign a unique ID to each person with computer access. Video: PCI compliance requirement 8: Unique IDs
- Restrict physical access to cardholder data. Video: PCI compliance requirement 9: Physical access
- Regularly monitor and test networks.
- Maintain an information security policy.
- Maintain a policy that addresses information security. Video: PCI compliance requirement 12: Policy
The PCI Security Standards Council offers more detailed guidelines on the aim of each requirement in a document entitled "Navigating PCI DSS: Understanding the Intent of the Requirements." For instance, the guidance for assigning a unique ID to each user with access explains that this requirement makes individuals accountable for their actions, enabling each action to be matched to a given user.
What does being PCI DSS compliant really mean?
There is a big difference between being PCI DSS-compliant and being "certified" as PCI DSS compliant, says e-commerce expert Evan Schuman. Because audit results can sometimes be subjective, the results could mean that some retailers may not really be compliant, even though someone says they are, he says.
Quarterly network scans and annual validation process
The credit card industry categorizes merchants according to the volume of credit card transactions processed annually. To validate PCI DSS compliance, merchants that process 20,000 or more Visa, MasterCard or Discover transactions must have their networks scanned for vulnerabilities each quarter. For American Express, this validation mandate applies to merchants processing 50,000 or more transactions annually.
Merchants also must validate PCI DSS compliance through an annual assessment. To meet PCI DSS validation requirements, an independent Qualified Security Assessor (QSA) must examine a merchant's preparation. For smaller operations, self-certification suffices. Credit card companies run their own validation and enforcement programs, including setting deadlines and administering penalties. Details vary from company to company, and mandates have been a bit of a moving target. The PCI DSS Compliance Blog compiled a chart of PCI compliance deadlines based on the compliance Web pages of each of the card companies.
Visa PCI compliance requires that only merchants that process more than 6 million transactions annually must bring in an independent QSA to complete the annual report. For smaller operations, Visa maintains that such a requirement could unnecessarily increase costs without necessarily improving security. By contrast, MasterCard increased PCI compliance requirements, making all merchants with more than 1 million annual transactions hire a QSA for an on-site evaluation rather than self-certifying.
PCI Council issues priority tool for compliance
The PCI Security Standards Council has issued a tool designed to walk companies through the compliance process by setting six milestones that companies must meet before being signed off as compliant by a security assessor.
Any organization that processes, stores or transmits credit card numbers is subject to PCI DSS requirements. Credit card numbers are known in the payment industry as "primary account numbers" (PANs). This applies to organizations that store PANs in paper form as well as electronic form.
As the PCI DSS Council explains, if an organization stores only truncated PANs and does not process or transmit full PANs, it is not subject to PCI DSS. In this context, a truncated PAN means a maximum of the first six and last four digits. There is, however, an exception for Requirement 12.8, which, the council's guidance document explains, has to do with merchants sharing cardholder data with service providers.
PCI DSS: Best practices for compliance
In this video from SearchSecurity.com, Kelley discusses the greatest challenges to PCI compliance, as well as how to deal with application security for compliance, encryption and compensating controls.
Information technology is naturally at the heart of compliance with this data security standard. It would be an organization's IT professionals who deploy, monitor, test and maintain the network components that support transactions involving cardholder data. Those components can be almost anything attached to the network, including servers, switches, routers, firewalls and other applications.
The PCI Security Standards Council advises that the parts of the network that are involved with cardholder data be isolated, which makes it possible to rein in the network environment subject to the standard. Otherwise, an organization's entire network can be subject to PCI DSS and, consequently, to the annual assessment. For example, not all PCs in an organization probably need to be able to access cardholder data, and if the network is adequately segmented, the PCI DSS might not apply.
PCI DSS compliance isn't just IT's responsibility, however, and should include anyone involved in processing payment cards. The myths of PCI DSS compliance reasonably describe achieving compliance as an ongoing process, with annual assessments and reporting. Experts advise that the IT department work in conjunction with an organization's business teams, as the risks of noncompliance involve both an organization's finances and reputation.
Is all the PCI DSS compliance whining and complaining justified?
In this column from security expert Kevin Beaver, he argues that PCI DSS compliance -- and information security in general -- are simply part of the cost of doing business in today's world.
Scale aside, cloud computing compliance still worries IT managers
How does PCI DSS matter to organizations moving into the cloud? Will PCI be applied to cloud computing by the FCC?
Just as each of the credit card companies has established its own compliance validation mandates, each company administers its own penalties for noncompliance. Neither the PCI Security Standards Council nor the card companies has published a comprehensive roster of potential penalties.
In recent years, however, Visa publicized the size of the fines that would be imposed for noncompliance by large and midsized merchants -- $25,000 and $5,000, respectively. Penalizing entities is accomplished by a credit card company fining the noncompliant merchant bank, and the merchant bank subsequently charging the merchant. Visa reportedly issued $4.6 million in fines in 2006, compared with $3.4 million in 2005. The cost of noncompliance transcends periodic fines, however, and can become steep if a merchant experiences a data breach. Ultimately, a card company can choose to stop processing transactions for a noncompliant merchant.
The case of discount retailer TJX illustrates the hefty price of noncompliance in light of a data breach. TJX disclosed a breach in early 2007, which resulted in more than 100 million cards potentially being exposed to fraud. The company settled a lawsuit brought by Visa for approximately $41 million and a separate suit brought by MasterCard for $24 million. Prior to settling those cases, TJX estimated that it had already incurred $256 million in costs related to the breach, including investigations, legal expenses and dealing with the computer system's vulnerabilities.
Zero liability limits legal recourse for PCI data breach violations
In this podcast, Schuman discusses the " zero-liability domino effect" that protects retailers in the case of a data breach.
Let us know what you think about the FAQ; email firstname.lastname@example.org.