Payment Card Industry Data Security Standard

From Wikipedia, the free encyclopedia
(Redirected from PCI Compliance)

The Payment Card Industry Data Security Standard (PCI DSS) is an information security standard used to handle credit cards from major card brands. The standard is administered by the Payment Card Industry Security Standards Council and its use is mandated by the card brands. The standard was created to better control cardholder data and reduce credit card fraud.

Validation of compliance is performed annually or quarterly,[1][better source needed] by a method suited to the volume of transactions handled:[2]


Originally, the major card brands started five different security programs:

The intentions of each were roughly similar: 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. To address interoperability problems among the existing standards, the combined effort made by the principal credit card organizations resulted in the release of version 1.0 of PCI DSS in December 2004.[citation needed] PCI DSS has been implemented and followed across the globe.

The Payment Card Industry Security Standards Council (PCI SSC) was then formed, and these companies aligned their individual policies to create the PCI DSS.[3] MasterCard, American Express, Visa, JCB International and Discover Financial Services established the PCI SSC in September 2006 as an administration/governing entity which mandates the evolution and development of the PCI DSS.[4] Independent/private organizations can participate in PCI development after proper registration. Each participating organization joins a particular SIG (Special Interest Group) and contributes to the activities which are mandated by the SIG. The following versions of the PCI DSS have been made available:[5]

Version Date Notes
1.0 December 15, 2004
1.1 September 2006 clarification and minor revisions
1.2 October 2008 enhanced clarity, improved flexibility, and addressed evolving risks and threats
1.2.1 July 2009 minor corrections designed to create more clarity and consistency among the standards and supporting documents
2.0 October 2010
3.0 November 2013 active from January 1, 2014 to June 30, 2015
3.1 April 2015 retired since October 31, 2016
3.2 April 2016 retired since December 31, 2018
3.2.1 May 2018
4.0 March 2022 Updated firewall terminology, expansion of Requirement 8 to implement multi-factor authentication (MFA), increased flexibility to demonstrate security, and targeted risk analyses to establish how they operate and manage risk exposure.[6]


The PCI Data Security Standard specifies twelve requirements for compliance, organized into six logically related groups called "control objectives". The six groups are:[7]

  1. Build and Maintain a Secure Network and Systems
  2. Protect Cardholder Data
  3. Maintain a Vulnerability Management Program
  4. Implement Strong Access Control Measures
  5. Regularly Monitor and Test Networks
  6. Maintain an Information Security Policy

Each version of PCI DSS has divided these six requirements into a number of sub-requirements differently, but the twelve high-level requirements have not changed since the inception of the standard. Each requirement/sub-requirement is additionally elaborated into three sections.

  1. PCI DSS Requirements: Define the main description of the requirements. The endorsement of PCI DSS is done on the proper implementation of the requirements.
  2. Testing Processes: The processes and methodologies carried out by the assessor for the confirmation of proper implementation.
  3. Guidance: Explains the core purpose of the requirement and the corresponding content which can assist in the proper definition of the requirement.

Under version 3.2.1 of the PCI DSS, the twelve requirements are described as follows:

  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.
  3. Protect stored cardholder data.
  4. Encrypt transmission of cardholder data over open, public networks.
  5. Protect all systems against malware and update anti-virus software or programs.
  6. Develop and maintain secure systems and applications.
  7. Restrict access to cardholder data by business need to know.
  8. Identify and authenticate access to system components.
  9. Restrict physical access to cardholder data.
  10. Track and monitor all access to network resources and cardholder data.
  11. Regularly test security systems and processes.
  12. Maintain an information security policy that addresses information security for all personnel.

Updates and supplemental information[edit]

The PCI SSC (Payment Card Industry Security Standards Council) has released several supplemental pieces of information to clarify various requirements. These documents include the following:

  • Information Supplement: Requirement 11.3 Penetration Testing
  • Information Supplement: Requirement 6.6 Code Reviews and Application Firewalls Clarified
  • Navigating the PCI DSS - Understanding the Intent of the Requirements
  • "Information Supplement: PCI DSS Wireless Guidelines" (PDF). August 26, 2011.
  • PCI DSS Applicability in an EMV Environment
  • Prioritized Approach for PCI DSS
  • Prioritized Approach Tool
  • PCI DSS Quick Reference Guide
  • PCI DSS Virtualization Guidelines
  • PCI DSS Tokenization Guidelines
  • PCI DSS 2.0 Risk Assessment Guidelines
  • The lifecycle for Changes to the PCI DSS and PA-DSS
  • Guidance for PCI DSS Scoping and Segmentation
  • PCI DSS v4.0 now available

Reporting levels[edit]

All companies who are subject to PCI DSS standards must be PCI compliant. However, how they prove and report their compliance is based on how many transactions they process per year and how they process those transactions. The acquirer or payment brands may also choose to manually place an organization into a reporting level at their discretion.[8]

At a high level, the merchant levels are as follows:

  • Level 1 – Over 6 million transactions annually
  • Level 2 – Between 1 and 6 million transactions annually
  • Level 3 – Between 20,000 and 1 million transactions annually (or any e-commerce merchant)
  • Level 4 – Less than 20,000 transactions annually

Each card issuer maintains their own table of compliance levels as well as a separate table for service providers.[9][10]

Validation of compliance[edit]

Compliance validation involves the evaluation and confirmation that the security controls & procedures have been properly implemented as per the policies recommended by PCI DSS. In short, the PCI DSS, security validation/testing procedures are mutually a compliance validation tool. A PCI DSS assessment has the following entities.[11]

Qualified Security Assessor (QSA)[edit]

A Qualified Security Assessor is an individual bearing a certificate that has been provided by the PCI Security Standards Council. This certified person can audit merchants for Payment Card Industry Data Security Standard (PCI DSS) compliance. QSAs are the independent groups/entities which have been certified by PCI SSC for compliance confirmation in organization procedures. The confirmation just assigns that a QSA has tended to all the separate prerequisites which are mandatory to do PCI DSS appraisals.

Internal Security Assessor (ISA)[edit]

An Internal Security Assessor is an individual who has earned a certificate from the PCI Security Standards Company for their sponsoring organization. This certified person has the ability to perform PCI self-assessments for their organization. This ISA program was designed to help Level 2 merchants meet the new Mastercard compliance validation requirements.[12] ISA certification empowers a worker to do an inward appraisal of his/her association and propose security solutions/ controls for the PCI DSS compliance. As the ISAs are upheld by the organization for the PCI SSC affirmation, they are in charge of cooperation and participation with QSAs.[11]

Report on Compliance (ROC)[edit]

A Report on Compliance is a form that has to be filled by all level 1 merchants Visa merchants undergoing a PCI DSS (Payment Card Industry Data Security Standard) audit. The ROC form is used to verify that the merchant being audited is compliant with the PCI DSS standard. ROC confirms that policies, strategies, approaches & workflows are appropriately implemented/developed by the organization for the protection of cardholders against scams/frauds card-based business transactions. A template “ROC Reporting Template” available on the PCI SSC site contains detailed guidelines about the ROC.[11]

Self-Assessment Questionnaire (SAQ)[edit]

The PCI DSS self-assessment questionnaires (SAQs) are validation tools intended to assist merchants and service providers to report the results of their PCI DSS self-assessment. There are eight different types of SAQs, each with a different level of complexity. The most basic is the SAQ-A, consisting of just 22 questions; the most complex is the SAQ-D, consisting of 329 questions.

The Self-Assessment Questionnaire is intended to be completed annually and submitted to the entity's acquiring bank. In addition to the SAQ, the Attestation of Compliance (AOC) is completed based upon the results of the SAQ. Each SAQ question must be replied with yes or no alternative. In the event that a question has the response "no", the entity must highlight its future implementation aspects.

Compliance versus validation of compliance[edit]

Although the PCI DSS must be implemented by all entities that process, store or transmit cardholder data, formal validation of PCI DSS compliance is not mandatory for all entities. Currently, both Visa and MasterCard require merchants and service providers to be validated according to the PCI DSS. Visa also offers an alternative program called the Technology Innovation Program (TIP) that allows qualified merchants to discontinue the annual PCI DSS validation assessment. These merchants are eligible if they are taking alternative precautions against counterfeit fraud such as the use of EMV or Point to Point Encryption.[13]

Issuing banks are not required to go through PCI DSS validation although they still have to secure the sensitive data in a PCI DSS compliant manner. Acquiring banks are required to comply with PCI DSS as well as to have their compliance validated by means of an audit.

In the event of a security breach, any compromised entity which was not PCI DSS compliant at the time of breach may be subject to additional penalties from card brands or acquiring banks, such as fines.


Compliance with PCI DSS is not required by federal law in the United States. However, the laws of some U.S. states either refer to PCI DSS directly or make equivalent provisions. The legal scholars Edward Morse and Vasant Raval have argued that, by enshrining PCI DSS compliance in legislation, the card networks have reallocated the externalized cost of fraud from the card issuers to merchants.[14]

In 2007, Minnesota enacted a law prohibiting the retention of some types of payment card data subsequent to 48 hours after authorization of the transaction.[15][16]

In 2009, Nevada incorporated the standard into state law, requiring compliance of merchants doing business in that state with the current PCI DSS, and shielding compliant entities from liability. The Nevada law also allows merchants to avoid liability by other approved security standards.[17][14]

In 2010, Washington also incorporated the standard into state law. Unlike Nevada's law, entities are not required to be compliant to PCI DSS, but compliant entities are shielded from liability in the event of a data breach.[18][14]

Risk management to protect cardholder data[edit]

Under PCI DSS's requirement 3, merchants and financial institutions are required to protect cardholder data with strong cryptography. Non-compliant solutions will not pass the audit.[2] A typical risk management program can be structured in 3 steps:

  1. Identify all known risks and record/describe them in a risk register. For example, hardware security modules (HSM) that are used in the cryptographic key management process could potentially introduce their own risks if compromised, whether physically or logically. HSMs create a root of trust within the system. However, while it is unlikely, if the HSM is compromised, this could compromise the entire system.
  2. Develop a risk management program is to analyze all identified risks. Included in this analysis should be a mix of qualitative and quantitative techniques to determine what risk treatment methods should be used to reduce the possibility of risks. For example, an organization might analyze the risk of using a cloud HSM versus a physical device that they use on site.
  3. Treat the risks in response to the risk analysis that was previously performed. For example, employing different treatments to protect client information stored in a cloud HSM versus ensuring security both physically and logically for an onsite HSM, which could include implementing controls or obtaining insurance to maintain an acceptable level of risk.

Continuous monitoring and review are part of the process of reducing PCI DSS cryptography risks. This includes maintenance schedules and predefined escalation and recovery routines when security weaknesses are discovered.

Controversies and criticisms[edit]

Visa and Mastercard impose fines for non-compliance.

Stephen and Theodora "Cissy" McComb, owners of Cisero's Ristorante and Nightclub in Park City, Utah, were allegedly fined for a breach for which two forensics firms could not find evidence as having occurred:

The McCombs assert that the PCI system is less a system for securing customer card data than a system for raking in profits for the card companies via fines and penalties. Visa and MasterCard impose fines on merchants even when there is no fraud loss at all, simply because the fines are "profitable to them," the McCombs say.[19]

Michael Jones, CIO of Michaels' Stores, testified before a U.S. Congress subcommittee regarding the PCI DSS:

[The PCI DSS requirements] are very expensive to implement, confusing to comply with, and ultimately subjective, both in their interpretation and in their enforcement. It is often stated that there are only twelve 'Requirements' for PCI compliance. In fact there are over 220 sub-requirements; some of which can place an incredible burden on a retailer and many of which are subject to interpretation.[20]

Others have suggested that PCI DSS is a step toward making all businesses pay more attention to IT security, even if minimum standards are not enough to completely eradicate security problems. For example, Bruce Schneier has spoken in favour of PCI DSS:

Regulation—SOX, HIPAA, GLBA, the credit-card industry's PCI, the various disclosure laws, the European Data Protection Act, whatever—has been the best stick the industry has found to beat companies over the head with. And it works. Regulation forces companies to take security more seriously, and sells more products and services.[21]

PCI Council General Manager Bob Russo responded to the objections of the National Retail Federation:

[PCI is a structured] blend...[of] specificity and high-level concepts [that allows] stakeholders the opportunity and flexibility to work with Qualified Security Assessors (QSAs) to determine appropriate security controls within their environment that meet the intent of the PCI standards.[22]

Compliance and compromises[edit]

According to Visa Chief Enterprise Risk Officer Ellen Richey (2018):

no compromised entity has yet been found to be in compliance with PCI DSS at the time of a breach.[23]

In 2008, a breach of Heartland Payment Systems, an organization validated as compliant with PCI DSS, resulted in the compromising of one hundred million card numbers. Around this same time Hannaford Brothers and TJX Companies, also validated as PCI DSS compliant, were similarly breached as a result of the alleged coordinated efforts of Albert "Segvec" Gonzalez and two unnamed Russian hackers.[24]

Assessments examine the compliance of merchants and services providers with the PCI DSS at a specific point in time and frequently utilize a sampling methodology to allow compliance to be demonstrated through representative systems and processes. It is the responsibility of the merchant and service provider to achieve, demonstrate, and maintain their compliance at all times both throughout the annual validation/assessment cycle and across all systems and processes in their entirety. Although it could be that a breakdown in merchant and service provider compliance with the written standard was to blame for the breaches, Hannaford Brothers had received its PCI DSS compliance validation one day after it had been made aware of a two-month-long compromise of its internal systems. The failure of this to be identified by the assessor suggests that incompetent verification of compliance undermines the security of the standard.[citation needed]

Other criticism lies in that compliance validation is required only for Level 1–3 merchants and may be optional for Level 4 depending on the card brand and acquirer. Visa's compliance validation details for merchants state that level 4 merchants compliance validation requirements are set by the acquirer, Visa level 4 merchants are "Merchants processing less than 20,000 Visa e-commerce transactions annually and all other merchants processing up to 1 million Visa transactions annually". At the same time, over 80% of payment card compromises between 2005 and 2007 affected Level 4 merchants; they handle 32% of transactions.[25]

See also[edit]


  1. ^ "What You Need to Know About PCI DSS Compliance: UK Costs & Checklist". Retrieved December 18, 2018.[dead link]
  2. ^ a b "Payment Card Industry (PCI) Data Security Standard Requirements and Security Assessment Procedures Version 3.2.1 May 2018" (PDF). PCI Security Standards Council, LLC.
  3. ^ Liu, Jing; Xiao, Yang; Chen, Hui; Ozdemir, Suat; Dodle, Srinivas; Singh, Vikas (2010). "A Survey of Payment Card Industry Data Security Standard". IEEE Communications Surveys & Tutorials. 12 (3): 287–303. doi:10.1109/SURV.2010.031810.00083. S2CID 18117838.
  4. ^ "About Us". PCI Security Standards Council. Retrieved December 15, 2022.
  5. ^ "Document Library". PCI Security Standards Council. Retrieved November 12, 2020.
  6. ^ "Securing the Future of Payments: PCI SSC Publishes PCI Data Security Standard v4.0". PCI Security Standards Council. March 31, 2022.
  7. ^ "PCI DSS Quick Reference Guide" (PDF). Retrieved November 12, 2020.
  8. ^ "Official PCI Security Standards Council Site - Verify PCI Compliance, Download Data Security and Credit Card Security Standards".
  9. ^ "Visa in Europe".
  10. ^ "Things Merchants Need to Know | Process Payment Data & Secured Transactions | Mastercard".
  11. ^ a b c PCI Security Standards Council. "Payment Card Industry (PCI) Data Security Standard Requirements and Security Assessment Procedures Version 3.2" (PDF). PCI Security Standards Council, LLC. Retrieved September 4, 2018.
  12. ^ "Avoid Paying For PCI Certification You Don't Need". FierceRetail. May 12, 2010. Retrieved March 26, 2018.
  13. ^ A guide to PCI compliance A guide to PCI compliance
  14. ^ a b c Edward A. Morse; Vasant Raval, Private Ordering in Light of the Law: Achieving Consumer Protection through Payment Card Security Measures DePaul Business & Commercial Law Journal 10, no. 2 (Winter 2012): 213-266
  15. ^ James T. Graves, Minnesota's PCI Law: A Small Step on the Path to a Statutory Duty of Data Security Due Care' William Mitchell Law Review 34, no. 3 (2008): 1115-1146
  16. ^ MINN. STAT. § 325E.64
  17. ^ NEV. REV. STAT. § 603A.215
  18. ^ 2010 Wash. Sess. Laws 1055, § 3.
  19. ^ Zetter, Kim (January 11, 2012). "Rare Legal Fight Takes on Credit Card Company Security Standards and Fines". Wired. Retrieved March 30, 2019.
  20. ^ "Do the Payment Card Industry Data Standards Reduce Cybercrime? A Hearing before the Subcommittee on Emerging Threats, Cybersecurity, and Science and Technology of the Committee on Homeland Security, House of Representatives, One Hundred Eleventh Congress, First Session, March 31, 2009". GPO. March 31, 2009. Retrieved March 30, 2019. {{cite journal}}: Cite journal requires |journal= (help)
  21. ^ "Bruce Schneier Reflects on a Decade of Security Trends". Schneier on Security. January 15, 2008. Retrieved March 8, 2019.
  22. ^ "Can PCI Compliance be Harmful to Your Security Initiative?". Retrieved October 9, 2020.
  23. ^ Vijayan, Jaikumar (March 19, 2009). "Post-breach criticism of PCI security standard misplaced, Visa exec says". Computerworld. Retrieved September 4, 2018.
  24. ^ Salim, Hamid M. (2014). Cyber safety: systems thinking and systems theory approach to managing cyber security risks (Thesis thesis). Massachusetts Institute of Technology. hdl:1721.1/90804.
  25. ^ "Heartland Payment Systems Enters into its Third Settlement Agreement Arising from 2008 Data Breach". Privacy Law Blog. May 24, 2010. Retrieved October 10, 2020.

External links[edit]