Payment Card Industry Data Security Standard

Short description: Set of security requirements for card processors

The Payment Card Industry Data Security Standard (PCI DSS) is a global data security standard that regulates how entities store, process, and transmit cardholder data (CHD) and/or sensitive authentication data (SAD). PCI DSS includes guidelines regarding components of organizations' technical and operational system that are related to such data.[1] Cardholder Data refers to information including Primary Account Numbers (PAN), cardholder names, expiration dates, and service codes. Sensitive authentication data refers to information including "full track data (magnetic-stripe data or equivalent on a chip)," card verification codes, and PINs/PIN blocks.[2] This standard is administered by the Payment Card Industry Security Standards Council, and its use is enforced by the major payment card brands. PCI DSS was created to improve and streamline the security controls organizations use when handling cardholder data and reduce credit card fraud. These organizations, including merchants and service providers, must prove compliance to the PCI DSS through an assessment and validation process. The payment card brands issue fines and other penalties when merchants or service providers fail to prove compliance. Validation of compliance is performed annually or quarterly with a method suited to the organization's volume of transactions:[3]

* Self-assessment questionnaire (SAQ)
* Firm-specific Internal Security Assessor (ISA)
* External Qualified Security Assessor (QSA)

## Contents

* 1 History
* 2 Requirements and control objectives
* 3 Updates and supplemental information
* 4 Merchant levels
* 5 Service provider levels
* 6 Compliance
* 6.1 Compliance validation
* 6.1.1 Report on Compliance
* 6.1.2 Self-Assessment Questionnaire
* 6.1.3 Security Assessors
* 6.1.3.1 Qualified Security Assessor
* 6.1.3.2 Internal Security Assessor
* 7 Compliance versus validation of compliance
* 8 Legal status
* 8.1 Legislation in the United States
* 9 Controversy and criticism
* 10 See also
* 11 References
* 12 External links

## History

Before the PCI DSS was launched, payment card information security was handled by the five major payment card brands: Visa, Mastercard, American Express, Discover, and JCB.[4][5] They each had different independent security programs:[6]

* Visa's Cardholder Information Security Program[7][6]
* Mastercard's Site Data Protection[6]
* American Express's Data Security Operating Policy[6]
* Discover's Information Security and Compliance[6]
* JCB's Data Security Program[6]

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 handle payment cards and related account information. As payment card fraud rose in the late 1990s and early 2000s,[8] the major payment card brands felt a growing need to streamline and unify these information security standards.[9] Each program had its own methods and guidance regarding compliance validation, assessments, and requirements.[6] To address interoperability problems among the existing standards, the combined effort by these payment card brands resulted in the release of version 1.0 of PCI DSS in December 2004.[9] The main payment card brands then founded the Payment Card Industry Security Standards Council (PCI SSC)[10] and aligned their policies to create the PCI DSS.[11] PCI DSS has since been implemented and followed by numerous organizations around the world.[6]

MasterCard, American Express, Visa, JCB International and Discover Financial Services established the PCI SSC in September 2006 as a global administrative and governing entity that mandates the evolution and development of the PCI DSS.[12] Independent private organizations can also participate in PCI development as part of the PCI Security Standards Council Participating Organization Program. To join that program, organizations must register as a PCI SSC Participating Organization (PO). Each participating organization joins a SIG (Special Interest Group) and contributes to activities mandated by the group.

The PCI DSS is a living document that is regularly updated by the PCI Security Standards Council. The PCI SSC releases major version updates, such as version 4.0, approximately every few years. Minor updates, such as version 4.0.1, are released more frequently and typically add small changes or clarifications.[13] When updates are released, organizations have a transition period during which they must become familiar with the new changes and begin ensuring compliance with the current version.[13] During the transition period, organizations are only required to be compliant with either the current version or the previous version.[14] The following versions of the PCI DSS have been made available:[15]

Version | Date | Description

|
|

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  | provided clarifications about the relationship between PCI DSS and PA-DSS (The Payment Application Data Security Standard), several additional guidelines regarding Requirement and Testing Procedure[16]
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  | retired since March 31, 2024
4.0  | March 2022  | retired since December 31, 2024,[17] the biggest update and revision since v1.0[5]: updated firewall terminology, expansion of Requirement 8 to implement multi-factor authentication (MFA), increased flexibility to demonstrate security, and targeted risk analyses to establish risk exposure operation and management[18]
4.0.1  | June 2024  | Currently, the only active version.[19][15] The deadline for compliance with this version was March 31, 2025.[20]

minor revisions: correct typographical and other minor errors, update and clarify guidance, remove Definitions in guidance and refer to the Glossary instead, add references to the Glossary for newly defined glossary terms and for existing glossary terms that did not previously have references [21]

## Requirements and control objectives

The PCI DSS has twelve requirements for compliance, organized into six related groups known as control objectives:[1]

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 PCI DSS version has divided these six requirement groups differently, but the twelve requirements have not changed since the inception of the standard. Each requirement and sub-requirement is divided into three sections:

1. PCI DSS requirements: Define the requirement. The PCI DSS endorsement is made when the requirement is implemented.
2. Testing: The processes and methodologies carried out by the assessor for the confirmation of proper implementation.
3. Guidance: Explains the purpose of the requirement and the corresponding content, which can assist in its proper definition.

In version 4.0.1 of the PCI DSS, the twelve requirements are:[2]

1. Install and maintain network security controls.
2. Apply secure configurations to all system components.
3. Protect stored account data.
4. Protect cardholder data with strong cryptography during transmission over open, public networks.
5. Protect all systems and networks from malicious software.
6. Develop and maintain secure systems and software.
7. Restrict access to system components and cardholder data by business need to know.
8. Identify users and authenticate access to system components.
9. Restrict physical access to cardholder data.
10. Log and monitor all access to system components and cardholder data.
11. Test security of systems and networks regularly.
12. Support information security with organizational policies and programs.

## Updates and supplemental information

The PCI SSC (Payment Card Industry Security Standards Council) has released supplemental information to clarify requirements, which includes:

* 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
* PCI DSS Wireless Guidelines[22]
* 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 Resource Hub[23]
* PCI DSS Summary of Changes: v4.0 to v4.0.1[21]

## Merchant levels

Merchants that store, process, and transmit cardholder data are subject to PCI DSS standards, and thus, must be deemed PCI-compliant. The PCI DSS framework classifies these entities into merchant levels that determine the type of reporting a business must complete to achieve compliance.[6] A business' merchant level is determined by its dataset size which refers to the number of transactions a business makes annually.[24] An acquirer or payment brand may manually place an organization into a reporting level at its discretion.[25] Not all payment card brands use all four merchant levels, and each level's transaction volume can vary among payment card brands.[4] For instance, Visa only has three merchant levels.[26] The four typically accepted merchant levels are:[4][6]

* Level 1 – Over six million transactions annually
* Level 2 – Between one and six million transactions annually
* Level 3 – Between 20,000 and one million transactions annually, and all e-commerce merchants
* Level 4 – Less than 20,000 transactions annually

Each card issuer maintains a table of compliance levels and a table for service providers.[27][28]

## Service provider levels

According to the PCI DSS, third-party service providers that store, process, or transmit cardholder data, or have access to customers’ account data are subject to PCI DSS standards.[2] Service providers can include payment software vendors, software as a service (SaaS), data centers, and other such entities.[2] Service providers are required to prove PCI DSS compliance through the assessment process. The type of reporting process a service provider must complete are dependent on the type of service provider.[10] Service providers are classified into levels which determine the reporting required for compliance.[29] The two service provider levels are:[29]

* Level 1:
* All Third-Party Processors (TPPs)
* All Staged Digital Wallet Operators (SDWOs)
* All Digital Activity Service Providers (DASPs)
* All Business Payment Service Providers (BPSPs)
* All Token Service Providers (TSPs)
* All 3-D Secure Service Providers (3-DSSPs)
* All Installment Service Providers (ISPs)
* All Merchant Payment Gateways (MPGs)
* All AML/Sanctions Service Providers, Data Storage Entities (DSEs) and Payment Facilitators (PFs) with more than 300,000 total combined Mastercard and Maestro transactions annually

* Level 2:
* All AML/Sanctions Service Providers, DSEs6 and PFs with 300,000 or less total combined Mastercard and Maestro transactions annually
* All Terminal Servicers (TSs)

## Compliance

The payment card brands regularly require both merchants and service providers to demonstrate PCI DSS compliance.[26] PCI DSS compliance involves implementing security controls that follow all requirements of the PCI DSS and passing the PCI DSS assessment process to achieve compliance validation.[4] The major credit card brands enforce PCI DSS compliance[4] by issuing fines for merchants who do not obtain compliance validation.[30] Merchants and service providers sign business-to-business contracts with payment processors and payment card brands, which outline such fines and fees.[5] In the event of a merchant's compliance violation, payment card brands issue fines to the acquiring bank who then fines or otherwise penalizes the non-compliant merchant.[31] Obtaining PCI DSS compliance and navigating the assessment process can be complicated, which is why many businesses often struggle with this. According to Verizon's 2018 Payment Security Report, 47.5% of organizations were not PCI DSS compliant during interim compliance validation. The number of organizations achieving compliance had been steadily increasing through the early 2010s, but this increase may likely have dropped in recent years.[32]

### Compliance validation

Compliance validation involves the evaluation and confirmation that the security controls and procedures have been implemented according to the PCI DSS. Validation occurs through an annual assessment, either by an external entity, or by self-assessment.[33] The assessment process includes the following steps:[2]

1. Confirm the scope of the PCI DSS assessment.
2. Perform the PCI DSS assessment of the environment.
3. Complete the applicable report for the assessment according to PCI DSS guidance and instructions.
4. Complete the Attestation of Compliance for Service Providers or Merchants, as applicable, in its entirety.
5. Submit the applicable PCI SSC documentation and the Attestation of Compliance, along with any other requested documentation to the requesting organization (those that manage compliance programs such as payment brands and acquirers (for merchants), or other requesters (for service providers)).

#### Report on Compliance

A Report on Compliance (ROC) is conducted by a PCI Qualified Security Assessor (QSA) and is intended to provide independent validation of an entity's compliance with the PCI DSS standard. A completed ROC results in two documents: a ROC Reporting Template populated with detailed explanation of the testing completed, and an Attestation of Compliance (AOC) documenting that a ROC has been completed and the overall conclusion of the ROC.

#### Self-Assessment Questionnaire

The PCI DSS Self-Assessment Questionnaire (SAQ) is a validation tool intended for small to medium sized merchants and service providers to assess their own PCI DSS compliance status. There are multiple types of SAQ, each with a different length depending on the entity type and payment model used. Each SAQ question has a yes-or-no answer, and any "no" response requires the entity to indicate its future implementation. As with ROCs, an attestation of compliance (AOC) based on the SAQ is also completed.

#### Security Assessors

The PCI Security Standards Council maintains a program to certify companies and individuals to perform assessment activities.

##### Qualified Security Assessor

A Qualified Security Assessor (QSA) is an individual certified by the PCI Security Standards Council to validate another entity's PCI DSS compliance. QSAs must be employed and sponsored by a QSA Company, which also must be certified by the PCI Security Standards Council.[34][35]

##### Internal Security Assessor

An Internal Security Assessor (ISA) is an individual who has earned a certificate from the PCI Security Standards Council for their sponsoring organization, and can conduct PCI self-assessments for their organization. The ISA program was designed to help Level 2 merchants meet Mastercard compliance validation requirements.[36] ISA certification empowers an individual to conduct an appraisal of his or her association and propose security solutions and controls for PCI DSS compliance. ISAs are in charge of cooperation and participation with QSAs.[33]

## Compliance versus validation of compliance

Although the PCI DSS must be implemented by all entities which process, store or transmit cardholder data and/or sensitive authentication data or could impact the security of such information,[2] formal validation of PCI DSS compliance is not mandatory for all entities. Visa and Mastercard require merchants and service providers to be validated according to the PCI DSS; Visa also offers a Technology Innovation Program (TIP), an alternative program which allows qualified merchants to discontinue the annual PCI DSS validation assessment. Merchants are eligible if they take alternative precautions against fraud, such as the use of EMV or point-to-point encryption.

Issuing banks are not required to undergo PCI DSS validation, although they must secure sensitive data in a PCI DSS-compliant manner. Acquiring banks must comply with PCI DSS and have their compliance validated with an audit. In a security breach, any compromised entity which was not PCI DSS-compliant at the time of the breach may be subject to additional penalties (such as fines) from card brands or acquiring banks.

## Legal status

No governing body/agency requires or enforces PCI DSS compliance, but if any PCI DSS requirements conflict with country, state, or local law, the law will apply.[2] The European Union’s (EU) General Data Protection Regulation (GDPR) is a legislative standard governing personal data. GDPR has similar security control standards as PCI DSS in regards to cardholder data because cardholder data is considered a form of personal data under GDPR.[37] Hence, for many European organizations, a PCI DSS breach often constitutes a GDPR breach as well, which can result in fines from both major payment card brands and the European Union.[31][37] These GDPR fines can be up to "€20 million or 4% of annual global turnover" (whichever is greatest).[31]

### Legislation in the United States

While compliance with PCI DSS is not required by federal law in the United States,[38] the laws of some US states refer to PCI DSS directly or make equivalent provisions. In 2007, Minnesota enacted a law prohibiting the retention of some types of payment-card data more than 48 hours after authorization of a transaction.[39][40] Nevada incorporated the standard into state law two years later, requiring compliance by 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.[41][42] In 2010, Washington also incorporated the standard into state law. Unlike Nevada's law, entities are not required to be PCI DSS-compliant; however, compliant entities are shielded from liability in the event of a data breach.[43][42] Legal scholars Edward Morse and Vasant Raval have said that by enshrining PCI DSS compliance in legislation, card networks reallocated the cost of fraud from card issuers to merchants.[42]

## Controversy and criticism

The major payment card brands impose fines for non-compliance. Some business owners, small business owners especially,[44] criticize the PCI DSS system because the payment card brands impose fines on businesses even if no fraud occurs. Stephen and Theodora "Cissy" McComb, owners of a small restaurant called Cisero's Ristorante and Nightclub in Park City, Utah, were fined for a breach for which two forensics firms could not find evidence. They claim the PCI DSS system exists primarily for major card brands to extract profit from these merchant companies rather than ensure cardholder data security.[45]

Michael Jones, who was CIO of Michaels at the time, testified before a US Congressional subcommittee about the PCI DSS:[46]

> [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.

Proponents of the PCI DSS maintain that the PCI DSS may compel businesses to pay more attention to IT security, even if minimum standards are not enough to eradicate security problems. Bruce Schneier spoke in favor of the standard:

> 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.[47]

PCI Council general manager Bob Russo responded to objections by 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.[48]

Former Visa chief enterprise risk officer Ellen Richey said in 2018, "No compromised entity has yet been found to be in compliance with PCI DSS at the time of a breach".[49] However, a 2008 breach of Heartland Payment Systems (validated as PCI DSS-compliant) resulted in the compromising of more than one hundred million card numbers.[50] Around that time, Hannaford Brothers and TJX Companies (also validated as PCI DSS-compliant) were similarly breached as a result of the allegedly-coordinated efforts of Albert Gonzalez and two unnamed Russian hackers.[51][50] In December 2013, more than forty million Target customer accounts were compromised in a data breach.[52][50] Target’s Executive Vice President and Chief Financial Officer at the time John Mulligan confirmed that Target was certified PCI compliant months before the breach in September 2013.[53] News of incidents was widespread and called into question the adequacy of the PCI DSS.

Assessments examine the compliance of merchants and service providers with the PCI DSS at a specific point in time, frequently using sampling to allow compliance to be demonstrated with representative systems and processes. It is the responsibility of the merchant and service provider to achieve, demonstrate, and maintain compliance throughout the annual validation-and-assessment cycle across all systems and processes. A breakdown in merchant and service-provider compliance with the written standard may have been responsible for the breaches; Hannaford Brothers received its PCI DSS compliance validation one day after it had been made aware of a two-month-long compromise of its internal systems.

Compliance validation is required only for level 1 to 3 merchants and may be optional for Level 4, depending on the card brand and acquirer. According to Visa's compliance validation details for merchants, level-4 merchant compliance-validation requirements ("Merchants processing less than 20,000 Visa e-commerce transactions annually and all other merchants processing up to 1 million Visa transactions annually") are set by the acquirer. Over 80 percent of payment-card compromises between 2005 and 2007 affected level-4 merchants, who handled 32 percent of all such transactions.[54]

## See also

* Card scheme
* Penetration test
* Vulnerability management
* Wireless LAN
* Wireless security

## References

1. ↑ 1.0 1.1 "PCI DSS Quick Reference Guide" (PDF). https://www.pcisecuritystandards.org/documents/PCI_DSS-QRG-v3_2_1.pdf?agreement=true.
2. ↑ 2.0 2.1 2.2 2.3 2.4 2.5 2.6 "Payment Card Industry Data Security Standard: Requirements and Testing Procedures Version 4.0.1. June 2024". PCI Security Standards Council, LLC. https://docs-prv.pcisecuritystandards.org/PCI DSS/Standard/PCI-DSS-v4_0_1.pdf.
3. ↑ "Payment Card Industry (PCI) Data Security Standard Requirements and Security Assessment Procedures Version 3.2.1 May 2018". PCI Security Standards Council, LLC. https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf.
4. ↑ 4.0 4.1 4.2 4.3 4.4 "PCI Compliance Guide: Protect Payment Data & Prevent Fraud" (in en). https://www.jpmorgan.com/insights/payments/security-trust/pci-compliance-guide-protect-payment-data-and-prevent-fraud.
5. ↑ 5.0 5.1 5.2 "The History of PCI Security Compliance and Standards" (in en). https://www.verizon.com/business/resources/articles/the-history-of-pci-compliance/.
6. ↑ 6.00 6.01 6.02 6.03 6.04 6.05 6.06 6.07 6.08 6.09 Chippagiri, Srinivas; Ramesh, Apoorva (2025). "PCI DSS: A Critical Analysis of Implementation, Effectiveness, and Legislative Impact in Payment Card Security". International Journal of Scientific Research in Computer Science, Engineering and Information Technology 11 (1): 1258–1266. doi:10.32628/CSEIT251112115. https://philpapers.org/rec/CHIPDA-4.
7. ↑ Blackwell, Clive (November 2008). "The management of online credit card data using the Payment Card Industry Data Security Standard". 2008 Third International Conference on Digital Information Management. pp. 838–843. doi:10.1109/ICDIM.2008.4746843. ISBN 978-1-4244-2916-5.
8. ↑ "Credit card fraud | Prevention & Detection Strategies | Britannica" (in en). https://www.britannica.com/topic/credit-card-fraud.
9. ↑ 9.0 9.1 "The History of PCI Compliance: How It Started and Where We're Headed | MRC" (in en). https://merchantriskcouncil.org/learning/resource-center/member-news/blog/2023/history-of-PCI-compliance.
10. ↑ 10.0 10.1 Laredo, Vanesa Gil (2008-04-01). "PCI DSS compliance: a matter of strategy". Card Technology Today 20 (4): 9. doi:10.1016/S0965-2590(08)70094-X. ISSN 0965-2590. https://www.sciencedirect.com/science/article/pii/S096525900870094X.
11. ↑ 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.
12. ↑ "About Us" (in en-US). https://www.pcisecuritystandards.org/about_us/.
13. ↑ 13.0 13.1 Goodspeed, Lindsay. "Updated PCI DSS v4.0 Timeline" (in en-us). https://blog.pcisecuritystandards.org/updated-pci-dss-v4.0-timeline.
14. ↑ "PCI DSS Version 4.0 Implementation Timeline" (in en). 2022-11-09. https://www.bdo.com/insights/digital/pci-dss-version-4-0-implementation-timeline.
15. ↑ 15.0 15.1 "Document Library". PCI Security Standards Council. https://www.pcisecuritystandards.org/document_library.
16. ↑ "Payment Card Industry Data Security Standard: Summary of Changes from PCI DSS Version 1.2.1 to 2.0. October 2010" (PDF). PCI Security Standards Council, LLC. Retrieved October 25, 2025.
17. ↑ Malone, Alicia. "Just Published: PCI DSS v4.0.1" (in en-us). https://blog.pcisecuritystandards.org/just-published-pci-dss-v4-0-1.
18. ↑ "Securing the Future of Payments: PCI SSC Publishes PCI Data Security Standard v4.0". PCI Security Standards Council. March 31, 2022. https://www.pcisecuritystandards.org/about_us/press_releases/pr_03312022.
19. ↑ "Frequently Asked Question" (in en-US). https://www.pcisecuritystandards.org/faq/articles/frequently_asked_question/.
20. ↑ "PCI DSS Future-Dated Controls: 7 Critical Changes that Will Shape Your Security Strategy" (in en-US). February 7, 2025. https://www.barradvisory.com/resource/pci-dss-future-dated-controls/.
21. ↑ 21.0 21.1 "Payment Card Industry Data Security Standard: Summary of Changes from PCI DSS Version 4.0 to 4.0.1. August 2024". PCI Security Standards Council, LLC. https://docs-prv.pcisecuritystandards.org/PCI DSS/Standard/PCI-DSS-v4-0-to-v4-0-1-Summary-of-Changes-r1.pdf.
22. ↑ "Information Supplement: PCI DSS Wireless Guidelines". August 26, 2011. https://www.pcisecuritystandards.org/pdfs/PCI_DSS_v2_Wireless_Guidelines.pdf.
23. ↑ "PCI DSS v4.0 Resource Hub". https://blog.pcisecuritystandards.org/pci-dss-v4-0-resource-hub.
24. ↑ "PCI DSS Merchant Levels: A Beginner's Guide To Compliance" (in en-US). 2024-10-20. https://nationalprocessing.com/blog/a-beginners-guide-to-pci-dss-merchant-levels/.
25. ↑ "Official PCI Security Standards Council Site - Verify PCI Compliance, Download Data Security and Credit Card Security Standards". https://www.pcisecuritystandards.org/.
26. ↑ 26.0 26.1 "Account Information Security (AIS) Program and PCI" (in en). https://corporate.visa.com/en/resources/security-compliance.html.
27. ↑ "Visa in Europe". https://www.visaeurope.com/receiving-payments/security/merchants.
28. ↑ "Things Merchants Need to Know | Process Payment Data & Secured Transactions | Mastercard". https://www.mastercard.us/en-us/merchants/safety-security/security-recommendations/merchants-need-to-know.html.
29. ↑ 29.0 29.1 "Mastercard Site Data Protection (SDP) Program & PCI" (in en-US). https://www.mastercard.com/us/en/business/cybersecurity-fraud-prevention/site-data-protection-pci.html.
30. ↑ "PCI Compliance Requirements | Business & Financial Services". https://bfs.ucsb.edu/cash-handling-banking/pci-compliance-requirements.
31. ↑ 31.0 31.1 31.2 "PCI DSS | What It Is and How to Comply | IT Governance UK". https://itgovernance.co.uk/pci-dss.
32. ↑ "2018 Payment Security Report" (in en). https://enterprise.verizon.com/resources/reports/payment-security/2018/.
33. ↑ 33.0 33.1 PCI Security Standards Council. "Payment Card Industry (PCI) Data Security Standard Requirements and Security Assessment Procedures Version 3.2". PCI Security Standards Council, LLC. https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2.pdf.
34. ↑ "Qualified Security Assessors". PCI Security Standards Council. https://listings.pcisecuritystandards.org/assessors_and_solutions/qualified_security_assessors.
35. ↑ "Qualification Requirements for Qualified Security Assessors (QSA)". PCI Security Standards Council. https://docs-prv.pcisecuritystandards.org/Programs and Certification/Qualified Security Assessor (QSA)/QSA_Qualification_Requirements_v4.0.pdf.
36. ↑ "Avoid Paying For PCI Certification You Don't Need". May 12, 2010. https://www.fierceretail.com/operations/avoid-paying-for-pci-certification-you-don-t-need.
37. ↑ 37.0 37.1 Elluri, Lavanya; Nagar, Ankur; Joshi, Karuna Pande (December 2018). "An Integrated Knowledge Graph to Automate GDPR and PCI DSS Compliance". 2018 IEEE International Conference on Big Data (Big Data). pp. 1266–1271. doi:10.1109/BigData.2018.8622236. ISBN 978-1-5386-5036-3.
38. ↑ "The PCI DSS (Payment Card Industry Data Security Standard) | IT Governance USA". https://itgovernanceusa.com/pci_dss.
39. ↑ 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
40. ↑ "MINN. STAT. § 325E.64". https://www.revisor.mn.gov/statutes/cite/325E.64.
41. ↑ "NEV. REV. STAT. § 603A.215". https://www.leg.state.nv.us/NRS/NRS-603A.html.
42. ↑ 42.0 42.1 42.2 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
43. ↑ "2010 Wash. Sess. Laws 1055, § 3.". http://leg.wa.gov/CodeReviser/documents/sessionlaw/2010pam1.pdf.
44. ↑ Boese IV, Robert F. (2020). "PCI DSS Compliance Challenges for Small Businesses". Utica College ProQuest Dissertations & Theses. ProQuest 2378961709. https://www.proquest.com/docview/2378961709.
45. ↑ Zetter, Kim. "Rare Legal Fight Takes On Credit Card Company Security Standards and Fines" (in en-US). Wired. ISSN 1059-1028. https://www.wired.com/2012/01/pci-lawsuit/. Retrieved 2025-11-29.
46. ↑ US Congress (March 31, 2009). "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" (in en-US). https://www.hsdl.org/c/abstract/?docid=27800.
47. ↑ "Bruce Schneier Reflects on a Decade of Security Trends". Schneier on Security. January 15, 2008. https://www.schneier.com/news/archives/2008/01/bruce_schneier_refle.html.
48. ↑ "Can PCI Compliance be Harmful to Your Security Initiative?". https://www.brighttalk.com/webcast/288/37985/can-pci-compliance-be-harmful-to-your-security-initiative.
49. ↑ Vijayan, Jaikumar (March 19, 2009). "Post-breach criticism of PCI security standard misplaced, Visa exec says". Computerworld. https://www.computerworld.com/article/2531828/security0/post-breach-criticism-of-pci-security-standard-misplaced--visa-exec-says.html.
50. ↑ 50.0 50.1 50.2 Williams, Branden R.; Chuvakin, Anton A.; Milroy, Derek (2015). PCI compliance: understand and implement effective PCI data security standard compliance (4th edition (Online-Ausg.) ed.). Waltham, Massachusetts: Syngress. ISBN 978-0-12-801579-7.
51. ↑ 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. Archived from the original on April 18, 2021. Retrieved October 8, 2020.
52. ↑ Press, Associated (2013-12-19). "Target says data breach possibly affected millions of credit cards" (in en-GB). The Guardian. ISSN 0261-3077. https://www.theguardian.com/business/2013/dec/19/target-breach-credit-card-accounts.
53. ↑ Majority Staff Report for Chairman Rockefeller. (2014). A “Kill Chain” Analysis of the 2013 Target Data Breach. US Senate Committee on Commerce, Science, and Transportation.
54. ↑ "Validation of Compliance | Information Security" (in en). https://caribbean.visa.com/run-your-business/small-business-tools/information-security/compliance-validation.html.

## External links

* Official PCI Security Standards Council Site

* v
* t
* e

Payment Card Industry Security Standards Council

* PCI Data Security Standard (PCI DSS)
* PCI Payment Application Data Security Standard (PCI PA-DSS)
* PCI Point to Point Encryption (PCI P2PE)
* PCI PIN Transaction Security (PCI PTS)

0.00

(0 votes)

Original source: https://en.wikipedia.org/wiki/Payment Card Industry Data Security Standard. Read more

|

Retrieved from "https://handwiki.org/wiki/index.php?title=Payment_Card_Industry_Data_Security_Standard&oldid=4572102"
*[v]: View this template
*[t]: Discuss this template
*[e]: Edit this template