What Is PCI DSS?
The Payment Card Industry Data Security Standard (PCI DSS) is a set of security requirements designed to protect cardholder data. It was created by the PCI Security Standards Council (PCI SSC), founded in 2006 by American Express, Discover, JCB, Mastercard, and Visa. Any organization that stores, processes, or transmits cardholder data — or that can impact the security of that data — must comply.
Unlike SOC 2 or ISO 27001, PCI DSS is not something you opt into for competitive advantage. It is a contractual obligation baked into your merchant agreement with your acquiring bank and, indirectly, into the card brand rules that bank operates under. If you accept Visa or Mastercard payments, you have already agreed to comply. The only questions are how big your scope is and how you validate.
The current version of the standard is PCI DSS v4.0.1, a limited revision of v4.0 published in June 2024. Version 3.2.1 was retired on March 31, 2024, and the last of the "future-dated" v4.0 requirements became mandatory on March 31, 2025. As of today, the full v4.x requirement set is in force — there is no grace period left to plan around.
Why PCI DSS Exists
Before PCI DSS, each card brand ran its own security program: Visa had CISP, Mastercard had SDP, American Express had DSOP, and so on. A merchant accepting all major brands faced overlapping, inconsistent requirements. The brands unified these programs into a single standard managed by the PCI SSC, so one assessment could satisfy all of them.
The underlying problem the standard addresses has not changed: payment card data is a liquid, instantly monetizable asset. A stolen database of card numbers can be sold and used for fraud within hours. Attackers target merchants and service providers because that is where card data concentrates — e-commerce checkout pages, point-of-sale systems, call center recordings, payment processors. PCI DSS exists to raise the baseline so a breach at any single merchant is harder, and less damaging when it happens.
What Data PCI DSS Protects
The standard distinguishes two categories of account data, and the distinction drives real requirements:
Cardholder data (CHD) includes the primary account number (PAN), cardholder name, expiration date, and service code. CHD may be stored if there is a business need, but it must be protected — the PAN in particular must be rendered unreadable (via strong encryption, truncation, tokenization, or keyed hashing) wherever it is stored, and masked when displayed.
Sensitive authentication data (SAD) includes full track data from the magnetic stripe or chip, the card verification code (CAV2/CVC2/CVV2/CID), and PINs or PIN blocks. SAD must never be stored after authorization, even encrypted. Under v4.0, if you are an issuer or store SAD before authorization completes, that pre-authorization SAD must itself be encrypted with strong cryptography. This is one of the most common breach findings: applications and logs quietly retaining CVV values that should never have been written to disk.
A useful rule for founders: if the PAN is present anywhere in your systems — databases, logs, backups, spreadsheets, call recordings, email — that location is in scope. If you can eliminate storage entirely (for example, by using a tokenizing payment provider), your compliance burden shrinks dramatically.
Who Must Comply
Every entity that stores, processes, or transmits cardholder data must comply, along with entities that could affect the security of the cardholder data environment (CDE). That includes:
- Merchants — anyone accepting card payments, from a single-location coffee shop to a global e-commerce platform.
- Service providers — payment gateways, hosting providers, managed security providers, SaaS platforms that touch card data on behalf of others, and even providers that merely could impact CHD security (a managed firewall provider, for instance).
- Acquirers, issuers, and processors — the financial institutions and processors in the payment chain.
A common startup misconception: "We use Stripe, so PCI doesn't apply to us." Using a payment provider dramatically reduces your obligations, but it does not eliminate them. You still must validate — typically with a short Self-Assessment Questionnaire — and you remain responsible for the parts of the payment flow you control, such as the web page that hosts the payment form. Under v4.0, even fully outsourced e-commerce merchants have concrete requirements around payment page script management.
Merchant Levels and Validation
Card brands classify merchants into levels based on annual transaction volume per brand. The levels determine how you validate compliance, not whether you must comply — every level must meet the applicable requirements.
| Level | Typical Threshold (Visa/Mastercard) | Validation Method | Who Validates |
|---|---|---|---|
| Level 1 | Over 6 million transactions annually, or any merchant post-breach at brand discretion | Annual Report on Compliance (ROC) | QSA (or qualified ISA) on-site assessment |
| Level 2 | 1 to 6 million transactions annually | Annual SAQ (Mastercard requires ISA/QSA involvement) | Self-assessment |
| Level 3 | 20,000 to 1 million e-commerce transactions annually | Annual SAQ | Self-assessment |
| Level 4 | Under 20,000 e-commerce, or up to 1 million total transactions | Annual SAQ (acquirer discretion) | Self-assessment |
All levels also typically require quarterly external vulnerability scans by an Approved Scanning Vendor (ASV) where applicable, and all levels submit an Attestation of Compliance (AOC) to their acquirer.
Service providers have their own two-level scheme: Level 1 service providers (generally those storing, processing, or transmitting more than 300,000 transactions annually, or those on card brand registries) require a QSA-led ROC; Level 2 service providers may complete SAQ D for Service Providers. In practice, most B2B customers of a service provider will demand a Level 1 AOC regardless — a ROC is a sales asset.
Three acronyms you will see constantly:
- QSA (Qualified Security Assessor) — an individual or firm certified by the PCI SSC to perform assessments.
- ROC (Report on Compliance) — the detailed assessment report a QSA produces for Level 1 entities.
- AOC (Attestation of Compliance) — the summary document declaring your compliance status, signed by you (and your QSA if applicable). This is the document customers and acquirers actually ask for.
Scope: The Concept That Drives Everything
PCI DSS applies to the cardholder data environment — the people, processes, and technology that store, process, or transmit CHD or SAD — plus any connected systems and any systems that could impact the CDE's security. Your compliance cost is roughly proportional to the size of that environment.
The two most powerful scope-reduction strategies:
- Outsource the payment flow. Hosted payment pages, redirects, and iframes from PCI-validated providers keep card data off your systems entirely, qualifying you for shorter SAQs.
- Segment your network. Isolate the CDE so the rest of your infrastructure falls out of scope. We cover this in depth in the network segmentation lesson later in this series.
Scope determination happens before controls. Organizations that skip scoping and jump straight to "implementing the 12 requirements" invariably either over-spend (securing systems that never needed to be in scope) or under-comply (missing a call center, a backup server, or a marketing database that quietly holds PANs).
Consequences of Non-Compliance
Non-compliance costs show up in several distinct ways:
- Card brand fines, passed through your acquirer, historically ranging from roughly $5,000 to $100,000 per month depending on level and duration of non-compliance.
- Increased transaction fees or forced migration to higher-cost processing tiers.
- Termination of card processing — the acquirer can simply stop processing your payments, which for most businesses is existential.
- Breach liability: if you are breached while non-compliant, expect forensic investigation costs (a PFI investigation), card reissuance costs charged back to you (often $3 to $10 per card), fraud loss liability, and mandatory escalation to Level 1 validation going forward.
- Legal and reputational exposure: state breach notification laws, FTC scrutiny, customer churn, and — for B2B companies — lost deals when you cannot produce an AOC during vendor security review.
It is worth being precise about what PCI DSS is not: it is not a law. There is no government regulator (though some US states like Nevada and Minnesota reference it in statute). Enforcement flows through contracts — brand to acquirer to merchant. That makes it no less binding in practice, because the party enforcing it controls your ability to get paid.
PCI DSS Compared to Other Frameworks
| Attribute | PCI DSS | SOC 2 | ISO 27001 |
|---|---|---|---|
| Nature | Contractual industry mandate | Voluntary attestation | Voluntary certification |
| Scope | Cardholder data environment | Systems in the service commitment | Defined ISMS scope |
| Prescriptiveness | Highly prescriptive (specific technical controls) | Flexible criteria | Risk-based, flexible |
| Assessor | QSA / self-assessment | CPA firm | Accredited certification body |
| Output | ROC/SAQ plus AOC | SOC 2 report | ISO certificate |
| Cadence | Annual validation, quarterly scans | Annual (Type II period) | 3-year cycle with surveillance audits |
If you already run a SOC 2 or ISO 27001 program, a meaningful portion of the work overlaps — access control, logging, vulnerability management, policies. But PCI DSS is far more prescriptive: it tells you exactly what to do (12-character passwords, specific scan cadences, specific retention rules) rather than asking you to design controls that meet criteria.
Getting Started Checklist
- Confirm with your acquiring bank which merchant level applies and what validation they expect
- Map every payment channel: e-commerce, in-person, mail/telephone order, recurring billing, refunds
- Diagram cardholder data flows end to end — where PAN enters, moves, and (ideally never) rests
- Inventory every system, vendor, and person that touches card data or could affect its security
- Identify and eliminate unnecessary card data storage (logs, exports, recordings, legacy databases)
- Determine whether outsourcing to a hosted payment provider can shrink your scope
- Identify your likely SAQ type (covered in lesson 3) or ROC obligation
- Collect AOCs from your payment-related third parties and record shared responsibilities
- Schedule quarterly ASV scans if you have external-facing in-scope systems
- Assign an owner for PCI compliance — someone accountable for the annual cycle
Frequently Asked Questions
Is PCI DSS a legal requirement?
No — it is a contractual requirement enforced through your merchant agreement and the card brand rules. A few US states reference it in law, and regulators may treat non-compliance as evidence of negligence after a breach, but the primary enforcement mechanism is your acquirer's ability to fine you or stop processing your payments.
We only take payments through Stripe/Square/PayPal. Do we still need to comply?
Yes, but your obligations are small. Fully outsourced merchants typically qualify for SAQ A, the shortest questionnaire. You still need to validate annually, manage the security of the page that serves your payment form, and keep card data from leaking into your systems through side channels like customer support emails.
What is the difference between compliance and validation?
Compliance means meeting the applicable requirements continuously. Validation is the periodic act of proving it — via SAQ, ROC, and AOC. You can be validated but drift out of compliance mid-year; the standard (and your liability exposure) expects continuous compliance, which is why v4.0 pushed hard toward treating security as business-as-usual.
How much does PCI DSS compliance cost?
For a fully outsourced small merchant: a few hours of staff time per year plus possibly a small acquirer fee. For a merchant needing SAQ A-EP or SAQ D: expect ASV scanning, penetration testing, and tooling costs in the low tens of thousands annually. A Level 1 ROC typically runs $50,000 to $200,000+ per year all-in, depending heavily on scope.
Does PCI DSS apply to debit cards and prepaid cards?
Yes. It applies to any payment card carrying the logo of a PCI SSC founding brand — credit, debit, and prepaid alike.
What happens if we get breached?
Expect a mandatory forensic investigation by a PCI Forensic Investigator (PFI), potential fines and card reissuance cost recovery, escalation to Level 1 validation regardless of your transaction volume, and heightened acquirer scrutiny for years. Breach response is far more expensive than compliance.
In the next lesson, we will cover the 12 PCI DSS requirements.
Building a PCI program usually means picking scanning vendors, compliance automation tools, and possibly a QSA. AuditXYZ helps you compare compliance automation platforms and auditors side by side, so you can match tooling and assessors to your actual scope and budget.