The Payment Card Industry Data Security Standard (PCI-DSS) is published by the PCI Security Standards Council — a consortium founded in 2006 by Visa, Mastercard, American Express, Discover, and JCB. It is not a law. It is a contractual standard: if a merchant wants to accept payment cards from these brands, the merchant's bank (acquirer) requires the merchant to comply, and the merchant agrees by contract. The teeth are in the contract terms, not in any statute.
The current version is PCI-DSS v4.0, published March 2022, with a transition period that ended March 31, 2024 (when v3.2.1 was retired) and full v4.0 enforcement of all "future-dated" requirements beginning March 31, 2025. The standard runs to about 360 pages. The 12 high-level requirements that students typically memorize sit on top of hundreds of detailed sub-requirements with prescribed validation approaches.
Who's covered
PCI-DSS applies to any entity that stores, processes, or transmits cardholder data — or that can affect the security of cardholder data. That's a much broader set than "businesses that take cards." It includes the obvious payment processors and merchants, but also extends to service providers (hosting providers handling card data, managed security service providers running an in-scope environment), shopping cart software vendors, call centers that take phone payments, and anyone whose system can influence the security of the cardholder data environment (CDE).
The four merchant levels
Merchants are tiered by annual transaction volume per brand. Higher tiers have heavier validation requirements.
| Level | Annual transactions | Validation |
|---|---|---|
| Level 1 | >6M / yr (or any merchant that has had a breach) | Annual on-site assessment by a Qualified Security Assessor (QSA) producing a Report on Compliance (ROC); quarterly external network scans by an Approved Scanning Vendor (ASV); Attestation of Compliance (AOC) |
| Level 2 | 1M – 6M / yr | Annual Self-Assessment Questionnaire (SAQ) or ROC (varies by brand); quarterly ASV scans; AOC |
| Level 3 | 20K – 1M e-commerce / yr | Annual SAQ; quarterly ASV scans; AOC |
| Level 4 | <20K e-commerce, or <1M total / yr | Annual SAQ; ASV scans (acquirer's discretion); AOC. Lightest paperwork; same technical requirements. |
The technical requirements are the same at every level. The only difference is how compliance is validated — Level 1 sends in outside auditors, Level 4 lets the merchant self-attest. The merchant level is set by each card brand; merchants that hit Level 1 with one brand often must comply at Level 1 across all brands by the brand with the strictest rules.
The 12 requirements
Organized into six control objectives. Every cybersecurity student should recognize these on sight — they appear on Security+, CISSP, CASP+, and every PCI-DSS interview ever conducted.
Install and maintain network security controls
Firewalls, segmentation, secure configurations between the CDE and untrusted networks. Documented network and data-flow diagrams.
Apply secure configurations to all system components
No vendor defaults (passwords, SNMP strings, sample apps). Hardening standards. One primary function per server.
Protect stored account data
Minimize storage; render PAN unreadable wherever stored (hashing, truncation, tokenization, or strong encryption). Never store sensitive authentication data after authorization (CVV, full track data, PIN).
Protect cardholder data with strong cryptography during transmission
TLS 1.2+ over open or public networks. No SSL, no early TLS, no weak ciphers.
Protect all systems and networks from malicious software
Anti-malware on commonly affected systems, regularly updated. v4.0 added requirements for malware detection on systems not "commonly affected" too.
Develop and maintain secure systems and software
SDLC. Critical patches applied within one month. Code review or static analysis for in-house web apps. WAF for public-facing web apps. Address OWASP-class issues.
Restrict access by business need to know
Least privilege. Role-based access. Default deny.
Identify users and authenticate access
Unique user IDs (no shared accounts). MFA for all access into the CDE (universal in v4.0). Strong password requirements; modern password rules accept length-based rather than complexity-based.
Restrict physical access to cardholder data
Facility controls. Visitor logs. Media handling and disposal. POS device inspection for tampering.
Log and monitor all access to system components and cardholder data
Centralized log collection. Daily review. Retain at least one year (three months immediately available). Integrity-protect logs.
Test security of systems and networks regularly
Quarterly internal vulnerability scans. Quarterly external ASV scans. Annual penetration test (internal + external). Annual segmentation testing for merchants using segmentation to reduce scope.
Support information security with organizational policies and programs
Comprehensive written security policy, reviewed annually. Risk assessments. Workforce security awareness. Incident response plan. Service provider management (the "list of third parties" requirement).
SAQ vs ROC
Most merchants validate compliance by submitting a Self-Assessment Questionnaire — a yes/no/N/A checklist matched to whatever subset of the 12 requirements applies to their processing model. There are nine SAQ types; picking the right one matters.
| SAQ | Applies to | Approx. # of questions |
|---|---|---|
| A | Card-not-present (e-commerce, mail/phone) merchants who outsource all card processing to a PCI-DSS-compliant third party. No electronic storage, processing, or transmission of cardholder data on the merchant's systems. | ~30 |
| A-EP | E-commerce merchants who partially outsource (e.g., direct-post to a third-party payment page). Some impact on cardholder data security. | ~190 |
| B | Imprint machines or dial-out terminal merchants. No electronic cardholder data storage. | ~40 |
| B-IP | Standalone IP-connected payment terminals (validated PTS terminals). | ~85 |
| C-VT | Web-based virtual payment terminal — merchant uses isolated computer with browser to a hosted payment page. | ~80 |
| C | Payment app systems connected to internet, no electronic storage of cardholder data. | ~160 |
| P2PE | Hardware-based, point-to-point-encrypted (P2PE) payment terminals, with no other electronic processing. | ~35 |
| SPoC | Software-based PIN entry on a commercial off-the-shelf device (smartphone), validated solution. | ~50 |
| D | "Everything else" — service providers and any merchant whose situation doesn't fit a narrower SAQ. Covers all 12 requirements. | ~330 |
A Report on Compliance (ROC) is the full-fat version — mandatory for Level 1 merchants and many service providers. It's produced by a Qualified Security Assessor (QSA) after an on-site assessment that can take weeks. A ROC examines evidence for every applicable sub-requirement and documents findings.
Scope reduction is the whole game
PCI-DSS applies to the Cardholder Data Environment (CDE) — any system that stores, processes, or transmits cardholder data, plus any system that's connected to those (could affect their security). The smaller the CDE, the cheaper compliance gets. Architecting for scope reduction is the dominant strategic move in payment systems.
- Use a hosted payment page or iframe. If the cardholder types their PAN into a page served by your payment processor (not your servers), and the data goes directly to the processor, your servers never touch cardholder data. You drop to SAQ A. This is the single biggest scope-reduction lever.
- Tokenize. Replace the PAN with a token after authorization. The token is useless to attackers; only the processor's vault can reverse it. The merchant's downstream systems (analytics, fulfillment, customer service) handle tokens, not cards.
- Point-to-point encryption (P2PE). Encrypt card data at the read head of a PCI-listed payment terminal, with the decryption key controlled by the payment processor. Merchant systems pass through encrypted blobs they can't read.
- Network segmentation. If you can't avoid touching cardholder data, isolate it. The CDE becomes a small, well-defined enclave; everything outside it — the corporate WiFi, the call-center desktops, the office printers — is out of scope. Failed segmentation tests are how Level 1 merchants discover that "out of scope" was a comfortable assumption that didn't survive contact with reality.
Enforcement and the cost of failure
PCI-DSS noncompliance penalties don't come from the PCI SSC — the council itself has no enforcement power. Penalties come from the card brands, levied through the merchant's acquiring bank, who deduct them from the merchant's account. Typical consequences:
- Monthly fines from $5,000 to $100,000 per brand for noncompliance, scaling with merchant size and how long the noncompliance persists.
- Forensic investigation costs. Following any suspected breach, a PCI Forensic Investigator (PFI) is engaged at the merchant's expense. Fees commonly run $50,000 to $500,000+ for the investigation alone.
- Reissuance and fraud loss. Card brands charge the merchant for the cost of reissuing cards to affected customers ($3 – $10 per card) plus fraud losses. For a breach of millions of cards, this dominates the total cost.
- Increased processing fees. Acquirers commonly move noncompliant merchants to higher rate plans.
- Loss of ability to accept cards. The terminal-case penalty. If the brands suspend a merchant's payment processing rights, the business effectively stops — very few businesses can operate cash-only at modern volumes.
- Public reputation cost from breach disclosure (also driven by state breach-notification laws, not by PCI itself).
In practice, the structural cost of compliance — QSA fees, ASV scans, pen tests, segmentation maintenance, training, the security team itself — runs anywhere from tens of thousands of dollars annually for a small e-commerce merchant on SAQ A to many millions for a Level 1 merchant or large service provider on a ROC.
PCI-DSS is the most prescriptive of the major compliance regimes — HIPAA tells you to manage risk; PCI-DSS tells you to install a firewall, log specific events, scan quarterly, and update patches within a month. That makes it easier to audit and harder to game, but also more brittle: the standard takes years to evolve and sometimes lags real-world threats.
The strategic move for any merchant: get cardholder data out of your systems. Hosted pages, tokenization, P2PE terminals. The cheapest CDE is no CDE. The second-cheapest is a tiny, segmented one with comprehensive monitoring. The most expensive is "we touch cards everywhere and we're hoping the audit doesn't notice" — which describes a startling number of organizations until their breach forces them to confront it.
Sources
- PCI Security Standards Council. (2022). Payment Card Industry Data Security Standard v4.0. https://www.pcisecuritystandards.org/document_library/
- PCI Security Standards Council. (2024). PCI DSS Quick Reference Guide. https://www.pcisecuritystandards.org/document_library/?category=pcidss
- PCI Security Standards Council. (2024). Self-Assessment Questionnaires (SAQ). https://www.pcisecuritystandards.org/document_library/?category=saqs
- Verizon. (2024). 2024 Payment Security Report. https://www.verizon.com/business/resources/reports/payment-security-report/
- U.S. Senate Committee on Commerce, Science, and Transportation. (2014). A "Kill Chain" Analysis of the 2013 Target Data Breach. Committee Print.