Payment Card Industry Data Security Standard — a contractual security standard set by the major card brands governing how cardholder data is stored, processed, and transmitted.
PCI-DSS is not a law. It is a contractual security standard created and maintained by the PCI Security Standards Council — a body founded by Visa, Mastercard, American Express, Discover, and JCB. Compliance is a condition of the agreement a merchant or service provider signs with its acquiring bank, not a legal obligation imposed by government. That distinction matters: there is no regulator to file a complaint with, and no statute defining a "violation." Enforcement runs through the card brands and the merchant's own payment processing contract.
The current version is PCI-DSS v4.0.1, released June 11, 2024. It is a limited revision of v4.0 (published March 2022) — zero new requirements, zero deleted requirements, just corrections and clarifications. v3.2.1 was formally retired and is no longer a valid assessment baseline. As of March 31, 2025, all 51 requirements that were "future-dated" (in effect as best practices only) under v4.0 became mandatory. Every requirement in v4.0.1 is now in force.
The standard applies to any entity — merchant, service provider, or processor — that stores, processes, or transmits cardholder data, or that could impact the security of the cardholder data environment (CDE), regardless of size or transaction volume.
PCI-DSS draws a hard line between two categories of account data, and the handling rules differ sharply between them.
| Category | Includes | Storage rule |
|---|---|---|
| Cardholder Data (CHD) | Primary Account Number (PAN), cardholder name, expiration date, service code | May be stored if business-justified and rendered unreadable — truncation, tokenization, strong cryptography, or hashing |
| Sensitive Authentication Data (SAD) | Full magnetic-stripe/chip track data, CAV2/CVC2/CVV2/CID, PINs and PIN blocks | Must never be stored after authorization — even if encrypted, even by issuers with a legitimate business need, unless specific exceptions apply |
The PAN is the data element that triggers scope. A system that never touches the PAN is generally out of scope for PCI-DSS, even if it touches other transaction metadata.
PCI-DSS organizes its 12 requirements under six control objectives:
| Goal | Req. | Requirement |
|---|---|---|
| 1. Build and Maintain a Secure Network and Systems | 1 | Install and Maintain Network Security Controls |
| 1. Build and Maintain a Secure Network and Systems | 2 | Apply Secure Configurations to All System Components |
| 2. Protect Account Data | 3 | Protect Stored Account Data |
| 2. Protect Account Data | 4 | Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks |
| 3. Maintain a Vulnerability Management Program | 5 | Protect All Systems and Networks from Malicious Software |
| 3. Maintain a Vulnerability Management Program | 6 | Develop and Maintain Secure Systems and Software |
| 4. Implement Strong Access Control Measures | 7 | Restrict Access to System Components and Cardholder Data by Business Need to Know |
| 4. Implement Strong Access Control Measures | 8 | Identify Users and Authenticate Access to System Components |
| 4. Implement Strong Access Control Measures | 9 | Restrict Physical Access to Cardholder Data |
| 5. Regularly Monitor and Test Networks | 10 | Log and Monitor All Access to System Components and Cardholder Data |
| 5. Regularly Monitor and Test Networks | 11 | Test Security of Systems and Networks Regularly |
| 6. Maintain an Information Security Policy | 12 | Support Information Security with Organizational Policies and Programs |
51 of the 64 requirements introduced in v4.0 were published in March 2022 as "future-dated" — treated as best practice, not mandatory, to give organizations time to implement. That grace period ended March 31, 2025. Every future-dated requirement, including mandatory MFA for all access into the CDE and expanded authenticated internal vulnerability scanning, is now fully enforceable in any current assessment.
v4.0 introduced a second path to meeting a requirement. Most organizations still follow the Defined Approach — implementing the control exactly as PCI-DSS specifies it. The Customized Approach lets an entity design its own control to meet the stated Customized Approach Objective instead, provided it performs and documents a targeted risk analysis, and a QSA independently validates that the control meets the objective. This is different from a compensating control — it is a designed alternative, not a workaround for a constraint.
A compensating control is only valid when a documented legitimate technical or business constraint genuinely prevents meeting a requirement as stated — it is not a shortcut for convenience. It must meet the intent and rigor of the original requirement, provide a similar level of defense, go above and beyond other PCI-DSS requirements, and be commensurate with the additional risk created by not meeting the requirement literally. It is documented on a Compensating Controls Worksheet and reviewed at every assessment — it does not carry forward automatically.
The Cardholder Data Environment (CDE) is the set of people, processes, and technology that store, process, or transmit account data, plus any connected system that could impact the security of the CDE. Scope is not fixed by what an organization intends to include — it is defined by where account data actually flows and by what has network access to systems that touch it.
Network segmentation — isolating the CDE from the rest of the network — is not a PCI-DSS requirement in itself, but it is the primary lever for reducing what falls in scope. Without effective segmentation, the entire flat network is in scope. Segmentation must be validated, not assumed: penetration testing must confirm segmentation controls are still effective, at least every 12 months and after any change to segmentation controls, with service providers required to test twice a year.
Card brands assign merchants to one of four levels based primarily on annual transaction volume. Level assignment drives how compliance must be validated — criteria vary slightly by brand, but the structure below (Visa's) is the industry reference point.
| Level | Volume | Validation |
|---|---|---|
| Level 1 | Over 6 million transactions annually, across any channel — or any merchant that has suffered a data breach, or is designated Level 1 by a brand | Annual on-site Report on Compliance (ROC) by a QSA, plus quarterly ASV scans |
| Level 2 | 1–6 million transactions annually | Annual SAQ (QSA-led ROC required by some brands), plus quarterly ASV scans |
| Level 3 | 20,000–1 million e-commerce transactions annually | Annual SAQ, plus quarterly ASV scans |
| Level 4 | Under 20,000 e-commerce transactions annually, or up to 1 million total transactions | Annual SAQ per acquirer discretion, plus quarterly ASV scans where applicable |
Merchants and eligible service providers below Level 1 validate compliance using the SAQ variant that matches how they handle account data — using the wrong SAQ type is one of the most common validation errors.
| SAQ | Applies to |
|---|---|
| A | Card-not-present merchants that fully outsource payment processing, with no electronic storage, processing, or transmission of CHD on their own systems |
| A-EP | E-commerce merchants that outsource payment processing, but whose own website can impact the security of the payment transaction (e.g., it controls the payment page) |
| B | Merchants using only imprint machines or standalone, dial-out terminals — no electronic cardholder data storage |
| B-IP | Merchants using only standalone, IP-connected PTS point-of-interaction terminals — no electronic data storage |
| C | Merchants with payment application systems connected to the internet, with no electronic cardholder data storage |
| C-VT | Merchants that manually key a single transaction at a time into an internet-based virtual terminal — no cardholder data stored on a computer system |
| P2PE | Merchants processing account data solely through a validated point-to-point encryption (P2PE) solution, with no access to clear-text account data |
| D (Merchant) | All other merchants not meeting the criteria of any other SAQ type |
| D (Service Provider) | All service providers eligible to complete an SAQ rather than a full ROC |
Qualified Security Assessor — an individual certified by the PCI SSC to conduct formal on-site assessments and produce a Report on Compliance for Level 1 merchants and large service providers.
Internal Security Assessor — an internal employee trained and certified by the PCI SSC to lead their own organization's SAQ-based self-assessment.
Approved Scanning Vendor — certified to run the quarterly external vulnerability scans required of any entity with internet-facing systems in the CDE.
Report on Compliance — the detailed assessment document a QSA (or ISA) produces, evaluating every applicable requirement in depth. Required for Level 1.
Self-Assessment Questionnaire — a self-validation tool for merchants and service providers below Level 1, chosen by data-handling profile, not size alone.
Attestation of Compliance — the formal declaration summarizing ROC or SAQ results, signed and submitted to the acquiring bank or card brand.
There is no statutory fine schedule. Card brands set and levy penalties through the merchant's acquiring bank, as a matter of contract, not law.
Scaled by merchant level, transaction volume, and how long non-compliance persists:
PCI SSC does not levy fines. The card brands (Visa, Mastercard, American Express, Discover, JCB) assess penalties through the merchant's acquiring bank. The acquiring bank typically passes the cost through to the merchant per its processing agreement — which is why the CSA-equivalent contract in card processing is the merchant agreement with the acquirer, not a relationship with PCI SSC directly.